Создание std:: thread замедляет основную программу на 50%

Ответ 1

std::rand() - это C rand(), который под glibc вызывает __random(). __random() вызывает __libc_lock_lock() и __libc_lock_unlock(), и я не думаю, что это растягивает воображение, что если мы углубимся в этот код, мы найдем что блокировки по существу являются no-op, пока не будет создан поток.

Ответ 2

Я думаю, что вы столкнулись с основной проблемой: по крайней мере, в типичной многозадачной операционной системе существует диапазон от (скажем) от нескольких миллисекунд до секунды или около того, в пределах которого трудно получить значимые временные измерения.

Для чрезвычайно коротких последовательностей вы можете использовать счетчик часов (например, RDTSC на x86) и запускать его несколько раз. Если во время прогона происходит переключение задачи, оно будет очень сильно торчать, поскольку выполнение выполняется в много раз дольше, чем остальные.

Это указывает на реальную проблему: как только вы дойдете до последовательности (например, вашей), которая занимает достаточно много времени, и почти наверняка произойдет, что по крайней мере один переключатель задачи будет работать во время его запуска, тогда вы столкнетесь с проблемой: время, потерянное для переключения задачи, может значительно сократить время. В частности, если переключатель задач происходит во время одного прогона, но не во время другого, он может сделать второй, значительно быстрее, чем первый.

В конце концов вы попадаете на задачи, которые занимают достаточно много времени, и все они включают в себя несколько переключателей задач, поэтому разница между количеством переключателей задач в значительной степени теряется в шуме.

Примечание: теоретически clock должен измерять только время процессора, а не время настенных часов. В действительности практически невозможно полностью исключить все время переключения задачи.

Ваш тест демонстрирует (или может продемонстрировать, в любом случае) еще одну довольно основную проблему: ваш dorand() что-то вычисляет, но не (например) не распечатывает результат. Достаточно интеллектуальный компилятор может (легко) уметь вывести, что он практически не имеет эффекта и в основном полностью исключает его.

Даже если вы распечатываете результаты из dorand, вы не заселили генератор случайных чисел, поэтому для каждого результата нужно было получить одинаковые результаты. Опять же, достаточно интеллектуальный компилятор мог понять это и вычислить правильный результат во время компиляции и просто распечатать три правильных результата. Чтобы предотвратить то, что мы могли (как одна возможность) заселять случайное число по-разному на каждом прогоне - обычным способом является получение текущего времени и передача этого значения в srand.

Чтобы устранить (или, по крайней мере, уменьшить) эти проблемы, мы могли бы переписать код примерно так:

#include <ctime>
#include <thread>
#include <iostream>

long long int dorands(){
  long long int a =0;
  for(int i=0; i<100000000; i++){
    a +=rand();
  }
  return a;
}

int foo(){return 0;}

int main(){
    srand(time(NULL));
  clock_t begin = clock();
  long long int e = dorands();
  clock_t end = clock();
  std::cout << "ignore: " << e << ", trial 1 time: " << end-begin << std::endl;;

  begin = clock();
  e = dorands();
  end = clock();
  std::cout << "ignore: " << e << ", trial 2 time: " << end - begin << std::endl;;

  std::thread t1(foo);
  t1.join();

  begin = clock();
  e = dorands();
  end = clock();
  std::cout << "ignore: " << e << ", trial 3 time: " << end - begin << std::endl;;

  begin = clock();
  e = dorands();
  end = clock();
  std::cout << "ignore: " << e << ", trial 4 time: " << end - begin << std::endl;;


  return 1;
}

Здесь я распечатал значение, возвращаемое из dorand, поэтому компилятор не может просто пропустить выполнение вызовов до rand полностью. Я также увеличил число внутри dorand, поэтому каждое испытание выполняется как минимум на секунду (на моем компьютере они все равно).

Запустив его, я получаю такие результаты:

ignore: 1638407535924, trial 1 time: 1519
ignore: 1638386748597, trial 2 time: 1455
ignore: 1638433228933, trial 3 time: 1433
ignore: 1638288863328, trial 4 time: 1491

В этом конкретном прогоне первые испытания медленнее (в среднем), чем вторые испытания, но есть достаточно вариаций и перекрытий, что мы, вероятно, довольно безопасно угадываем, что это просто шум - если есть какая-то реальная разница в средней скорости, это слишком мало для нас, чтобы измерить.