Месячный Архив: Май 2013

performance programming

Погрешность вычислений с числами с плавающей запятой

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

В этом маленьком тесте изменение результата от изменения флагов обнаружить не удалось, но всё равно обилие результатов удивляет — 5 различных, с 13 совпадающими знаками из 15-17 возможных для double.

Исходник и компилятор Результат Время выполнения, с
Assembler 1.53436944477410652787 3.81
gcc long 1.53436944477462278158 4.4
gcc double 1.53436944477389380914 4.4
icc long 1.53436944477397574360 6.88
icc double 1.53436944477334602510 1.50

*результаты по одному измерению, по этому совсем серьёзно воспринимать их не стоит. Время указано для процессора FX-8120
p.s. ну и обнаружилось, что написание кода на ассемблере пока ещё не абсолютно потеряло смысл — получился до 15% быстрее, чем на C.

performance programming

CUDA мы катимся?

Сразу извиняюсь за название — взято с потолка.
Неудержался и нафигачил вычислительную задачу, которую уже упоминал в прошлых топиках на CUDA. Ничего хитрого не делал — просто расставил директивы __device__.
В итоге получилось даже медленнее чем на CPU раз в 5 :’-(
Сей ужас можно увидеть здесь.

performance programming

Хватит использовать устаревший софт!

Каким бы тёплым и ламповым старый софт не был, но рано или поздно от него приходится отказываться, и сейчас я покажу это на примере компиляторов.
Допустим у нас есть приложение, которое выполняет некоторые вычисления.
Попробуем скомпилировать его различными версиями gcc и icc. И измерим время выполнения. Опции компиляции следующие:

Версия компилятора Время выполнения,c Во сколько раз медленнее лидера
gcc-4.1 70.0 3.68
gcc-4.3 45.3 2.38
gcc-4.4 45.9 2.42
gcc-4.5 34.9 1.84
gcc-4.6 34.7 1.83
gcc-4.7 34.9 1.84
icc-13.1.1 19.0 1.0

Читать далее »