Операции в больших циклах

[alexzk]

Да, формально тут фигово параллелится, т.к. у вас последущие вероятности зависят от предыдущего нейтрона. Но, если, скажем, у нас есть 8 нейтронов со слегка разными скоростями, и не важно, какой влупить 1м, а какой 2м, то можно параллелить.
Кроме прочего, стоило было бы ввести нормализирующий множитель, приводящий вероятность в целый uint64_t. Тогда, будет максимальная производительность процессора (он быстрее с целыми) + для параллельности есть маханизм "одновременной" работы с целыми (std::atomic<uint64_t>), без потерь на синронизацию.

[GreenWizard]

чисто программно там особо нечего оптимизировать, слишком мелкая задача (я думал у вас там прям моделирование, с кучей взаимодействий, расчётов и т.д.)
Стоит почитать вообще про "моделирование случайных процессов", там должны быть более грамотные алгоритмы. Как по мне, не имеет ценности один цикл моделирования и нужна статистика по сотням экспериментов, а это уже требует грамотного мат. аппарата и специализированных методов, иначе время расчётов будет нереальным.
Кроме того, очень вероятно получить совсем "левые" результаты т. к. программа работает с малыми величинами, которые компьютер любит округлять. Это особенно актуально для s_ge* и всего что зависит от них.

Моё мнение: НЕ пытайтесь ускорить текущий код, а изучите материалы по МСП и попробуйте составить др. модель.

[Haric_110]

Сообщение от alexzk

Кроме прочего, стоило было бы ввести нормализирующий множитель, приводящий вероятность в целый uint64_t. Тогда, будет максимальная производительность процессора (он быстрее с целыми) + для параллельности есть маханизм "одновременной" работы с целыми (std::atomic<uint64_t>), без потерь на синронизацию.

Благодарю, действительно, я умножил вероятности на 1е+15 (15 знаков после запятой содержит мантисса double) и генерировал целые uLL числа, в результате чего скорость возрасла примерно в 2 раза!

Сообщение от GreenWizard

чисто программно там особо нечего оптимизировать, слишком мелкая задача (я думал у вас там прям моделирование, с кучей взаимодействий, расчётов и т.д.)
Стоит почитать вообще про "моделирование случайных процессов", там должны быть более грамотные алгоритмы. Как по мне, не имеет ценности один цикл моделирования и нужна статистика по сотням экспериментов, а это уже требует грамотного мат. аппарата и специализированных методов, иначе время расчётов будет нереальным.
Кроме того, очень вероятно получить совсем "левые" результаты т. к. программа работает с малыми величинами, которые компьютер любит округлять. Это особенно актуально для s_ge* и всего что зависит от них.

Моё мнение: НЕ пытайтесь ускорить текущий код, а изучите материалы по МСП и попробуйте составить др. модель.

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

Что касается результатов, я проверял вероятности, они правильные.

Ну, а насчёт ускорения кода... я согласен отчасти, но это попытка, думаю, она имеет право на существование Тем более, что эта "игрушка" даёт приблизительно правильный результат (тип проводимости правильный и значение степени компенсации близкое к экспериментальным данным). Кроме того, я же назвал тему "Операции в больших циклах", это важно учитывать в любом случае

[alexzk]

Ну вот...теперь, если допустить, скажем не последовательность каждых из 8 событий (думаю это физ. верно), то получится ускорение в 70% * 8 * 2 раз = 11.2 (70%, т.к. такой прирост в среднем дает +1 процессор).

[Haric_110]

Допустимо, конечно. Допустить можно непоследовательность очень большого числа событий, тем более, если не учитывать упругие взаимодействия... (Вообще, модель можно сильно упростить без потери качества, это не моя идея — по одному нейтрону проверять)
Наверное, только при условии, что программа будет выполняться на 8-ми ядерном процессоре типа Intel Xenon можно параллелить на 8 потоков? В моих-то лабораторных условиях лишь 4-х ядерный AMD A10) Но, если чисто теоретически прикидывать... наверное, это зависит от того, на чём выполняться будет.
Мне надо ещё разобраться с многопоточностью... Как делить память... Ведь одни и те же переменные менять надо всем процессорам. Я ещё совсем нубик и чайник во всём этом

[alexzk]

Сообщение от Haric_110

Допустимо, конечно. Допустить можно непоследовательность очень большого числа событий, тем более, если не учитывать упругие взаимодействия... (Вообще, модель можно сильно упростить без потери качества, это не моя идея — по одному нейтрону проверять)
Наверное, только при условии, что программа будет выполняться на 8-ми ядерном процессоре типа Intel Xenon можно параллелить на 8 потоков? В моих-то лабораторных условиях лишь 4-х ядерный AMD A10) Но, если чисто теоретически прикидывать... наверное, это зависит от того, на чём выполняться будет.
Мне надо ещё разобраться с многопоточностью... Как делить память... Ведь одни и те же переменные менять надо всем процессорам. Я ещё совсем нубик и чайник во всём этом

...поэтому я и сказал умножить Для целых чисел есть механизм не блокированого одновременного изменения (std::atomic<uint64_t>)

А потоков навешать можно около 2х от ядер/процессоров в системе, я думаю. Точнее нада поэксперементировать, что-то в интервале "число-ядер" - "число-ядер" * 2 будет (если включен HyperThreading, то скорее 1х выйдет - там "удвоение" аппаратное, т.е. сам гипер считаем, как "ядро" и ничего у себя не удваиваем).

А еще быстрее, наверно, будет на каждое ядро повесить 1/N расчетов независимо (с локальными переменными), а потом по окочании всех N просуммировать N результатов.