Концептуальная многопоточность с семафорами и псевдослучайными числами

Question

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

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

Поскольку каждый поток вряд ли будет иметь другие операции (просто если операторы для проверки и приращения x) будут выполнять многопоточность, это даже даст мне более быстрые результаты, или зависимость от одного генератора случайных чисел будет означать, что он будет по существу таким же, какодна нить?

Answer 1

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

Answer 2

необходимо для обеспечения одновременного доступа двух потоков и генерации случайных чисел

Это означает, что на самом деле будет запущен только один рабочий поток, поэтому вы не используете преимущества многопоточности.Или я упустил момент, когда вы упомянули о распределении некоторой работы по многопоточным потокам?

Если вы каким-то образом улучшаете общий дизайн доступа к ГСЧ из нескольких потоков - рассмотрите возможность использования техники ReaderWriterLock вместо Semaphore.

Answer 3

Теоретически вы должны увидеть увеличение производительности, по крайней мере до тех пор, пока количество потоков не станет равным количеству используемых ядер. Однако в действительности вы будете добавлять код (и, следовательно, время выполнения) для обработки многопоточной инфраструктуры, и если большая часть времени каждого потока будет потрачена на ожидание медленного ГСЧ, вы можете увидеть снижение производительности.

С другой стороны, вы сможете улучшить производительность с некоторым умом. Например, у вас может быть одна задача, предназначенная для генерации случайных чисел, и если вы ищете только значения от 1 до 6, вы можете сгенерировать более одного значения из каждого результата из RNG. Вы можете поместить эти значения в очередь и позволить другим задачам читать из очереди. Конечно, вы должны быть осторожны, чтобы ваши оптимизации не изменили распределение ГСЧ.

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