Чем, на чём и под чем быстрее считать

[apximhd]

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

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

Для тестирования использовалась машина с процессором Intel Core i5-3230M 2.6 ГГц, 12 Гбайт оперативной памяти, двумя «чистыми» операционными системами: Linux XUbuntu 16.10 и Windows 10; под последней в свою очередь были установлены ещё две виртуальные машины: VMWare Workstation 12 Player и Oracle VM VirtualBox 5.1.12 — и там, и там была развернута XUbuntu 16.10, которой отводились 4 логических процессора и 4 Гбайт памяти.

Для запуска программы использовался пайтоновский скрипт, запускающий сразу несколько конфигураций (обычно 4 или 8 — в зависимости от числа логических процессоров на используемой машине).

Поскольку общее количество конфигураций, которые необходимо посчитать, составляет несколько десятков тысяч, вопрос оптимизации работы программ по скорости стоит достаточно остро: даже выигрыш в 5% в конечном итоге приводит к экономии недели вычислительного времени.

Поэтому я протестировал несколько компиляторов, запущенными под разным окружением.
Для запуска под Linux использовались компиляторы gcc и gfortran версии 5.3.0.
Для запуска под Windows — компиляторы MinGW gcc и gfortran версии 5.3.0 и компилятор С/С++ из Visual Studio 2016 версии 19.00.24213.1

При компиляции использовались следующие ключи:
gcc, gfortran: -O3 -ffast-math -funsafe-math-optimizations
Microsoft C/C++: /O2 /Ot /fp:fast

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

Linux XUbuntu 16.10
gcc                                                         1250 s. 100%
gfortran                                                    1299 s. 104%

Microsoft Windows 10
gcc,      Ubuntu Linux under Oracle VM VirtualBox 5.1.12    1340 s. 100%
gfortran, Ubuntu Linux under Oracle VM VirtualBox 5.1.12    1441 s. 108%
Microsoft C/C++, Microsoft Windows 10                       1459 s. 109%
gcc,      MinGW, Microsoft Windows 10                       1520 s. 113%
gfortran, MinGW, Microsoft Windows 10                       1651 s. 123%
gfortran, Ubuntu Linux under VMWare Workstation 12 Player   1684 s. 126%
gcc,      Ubuntu Linux under VMWare Workstation 12 Player   1785 s. 133%

Почему в последнем случае (под VMWare Workstation 12 Player) фортрановская программа работает быстрее, чем скомпилированная gcc, хотя во всех остальных случаях программа на Си быстрее — загадка великая.
Что-то гремлины из VMWare непонятное у себя накодили. На чистой линукс-машине gcc-программа работает на 4% быстрее gfortran-программы.

Comments

[vitus_wagner]

Еще интересно попробоват убунту без виртуализации, например загрузившись с liveCD.

А еще можно GCC поновее взять. Потому что вообще-то уже 7.1 вышла.

[al-pas.livejournal.com]

Добавил в начало таблицы тест под «чистой» убунтой на той же машине.

[vitus_wagner]

Еще есть такое ругательное слово clang. На некоторых бенчмарках, близких к поставленной задаче, там якобы ускорение процентов на 30 по сравнению с gcc 5.2.

Поскольку в дистрибутиве ubuntu clang есть, причем относительно недавней версии 3.8, можно и его еще попробовать.

[al-pas.livejournal.com]

Попробовал — под чистым линуксом в точности тот же результат, что и gcc. Видимо, у меня за годы код уже настолько оптимизирован, что компилятор его улучшить не в состоянии.

[psilogic.livejournal.com]

Мне visual studio 2015 подсказывает такие ключи оптимизации, которые могут имет отношение к скорости:
/O2 /Ob2 /Oi /Ot /Oy /GL /GS- /LTCG /fp:fast
а также, учитывая, что Вам надо оптимизировать на конкретной машине и можно пожертвовать портируемостью, то стоит поиграться с опцией /arch:...

Упоминание "питоновского скрипта" навело на мысль о том, что если он достаточно часто вызывает вторичные программы, то загрузка и запуски программ может убивать довольно много времени, а если просто пускает 4 программы, которые работают минут по 15 - тогда, конечно, это неважно

[al-pas.livejournal.com]

Основной прирост дают ключи /O2 и /fp:fast. Остальные в моём случае меняют производительность скомпилированной программы на доли процента. Для других алгоритмов это, возможно, будет не так.

Да, каждая нитка выполняется не менее 10 минут, пайтоновский скрипт попросту запускает их отдельными Popen (4 или 8 — в зависимости от того, сколько логических процессоров он обнаруживает) и собирает их stdout'ы в один файл и, как только один из логических процессоров освобождается, запускает следующий Popen.

[psilogic.livejournal.com]

Нам в сходной ситуации (требовалось оптимизировать математику функции шифрования), помнится, пришлось переходить на ассемблер и использовать расширенные наборы команд (SSE / AVX) Но при этом творилась "магия" - небольшое (и на первый взгляд эквивалентное) изменение алгоритма могло улучшить скорость вдвое, а потом другое изменение - ухудшить обратно вдвое.
З.Ы.
И, что касается магии, то иногда помогает смешение целочисленной и floating point-арифметики, т.к. компилятор тогда распараллеливает команды между процессором и сопроцессором.

[caztd.livejournal.com]

Попробуйте сравнить чистый CPU-time (по-крайней мере для Линукса).
По идее gcc должен генерировать одинаковый код для одного процессора.
Разница при виртуализации -- это разный thread scheduling и симуляция IO.
NTFS -- не самая лучшая система, поэтому gcc под VB,
где виртуальный диск очень хорош (какой кстати и какая file system?)
обгоняет родной gcc mingw, который использует NTFS.

Ну а gcc под линухом по любому самый быстрый -- так и должно быть ;)

[al-pas.livejournal.com]

Файловая система в моём случае роли не играет — у меня ввод/вывод чтение/запись происходят только в начале и в конце и занимают суммарно меньше секунды, всё остальное время программа крутится в оперативной памяти, только в конце выводя пару килобайт данных в stdout.

[caztd.livejournal.com]

Возможно. Но прежде чем анализировать скомпилированный код я все же бы посмотрел как минимум на cpu user / cpu kernel time. Если конечно действительно важно выяснить причину расхождений.

[t-mike.livejournal.com]

ещё варианты:
- добовить оптимизацию под процессор -march=native -mtune=native
- попробовать icc

[al-pas.livejournal.com]

Интел отказала мне в предоставлении компилятора для опенсорсных целей. Обоснование: они не обнаружили никаких подтверждений, что по указанному мной URL (www.astro.utu.fi) кто-либо занимается указанной мной задачей (3-Body problem).

[p-a-s-h-a.livejournal.com]

Ну, так Шаттлворт зря что ли в космос летал? :)