Олег Воробьёв wrote:
Алексей Чуклимов wrote:
порядок следования ключей влияет на результат.
Однако…
Выходит, от перемены мест слагаемых сумма, всё же, меняется?
Судя по результатам тестов, меняется на невзаимосвязанных ключах, но не на всех. Мне пока не понятно почему так происходит. Например, подключая недостающие ключи к -O2, не достигается результат, получаемый с использованием аналога -O3. Возможно есть незадокументированные опции или сильно влияет порядок их описания. До анализа исходных текстов gcc пока не добирался. Вся информация черпалась из документации или получена на основе тестирования.
P.S.
Началось все с того, что недавно упростив строку ключей и протестировав ее перед запуском на nbench, я получил странный результат: NUMERIC SORT выдал на номинальной оптимизации 728.8 супротив известных мне максимальных 600. Ключи компиляции были следующими: CFLAGS=“-O1 -march=atom -mtune=atom -mmmx -msse -msse2 -msse3 -mssse3 -mfpmath=sse -fno-gcse -fomit-frame-pointer -g0”. У Core2 T5600, к примеру, NUMERIC SORT около 815 при оптимизации -O3 -march=native и 630+ при -O2 -march. Это меня заинтересовало и я продолжил подбор вариантов, так как часто удается вытянуть производительность и по другим параметрам, почти сохранив достигнутый результат. Тем более, что не так давно перешел на версию gcc-4.5.3-r2. В общем решил попробовать.
Параметры CFLAGS=“-O1 -march=atom -mtune=atom -mmmx -msse -msse2 -msse3 -mssse3 -mfpmath=sse -fmerge-all-constants -fomit-frame-pointer -finline-limit=2048 -fipa-sra -finline-small-functions -finline-functions -funswitch-loops -ftree-vectorize --param max-unroll-times=4 --param max-unrolled-insns=72 --param max-average-unrolled-insns=216 -funroll-all-loops -fpeephole2 -fschedule-insns -fschedule-insns2 -foptimize-register-move -fregmove -foptimize-sibling-calls -freorder-functions -fno-gcse -pipe -g0” принесли еще более впечатляющий результат:
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 800.16 : 20.52 : 6.74
STRING SORT : 126.64 : 56.59 : 8.76
BITFIELD : 1.7621e+08 : 30.23 : 6.31
FP EMULATION : 99.6 : 47.79 : 11.03
FOURIER : 7893.3 : 8.98 : 5.04
ASSIGNMENT : 15.857 : 60.34 : 15.65
IDEA : 2345 : 35.87 : 10.65
HUFFMAN : 873.71 : 24.23 : 7.74
NEURAL NET : 10.119 : 16.26 : 6.84
LU DECOMPOSITION : 516.64 : 26.76 : 19.33
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 36.598
FLOATING-POINT INDEX: 15.748
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU : Dual GenuineIntel Intel(R) Atom(TM) CPU N270 @ 1.60GHz 1596MHz
L2 Cache : 512 KB
OS : Linux 3.1.10-gentoo-r1
C compiler : i686-pc-linux-gnu-gcc
libc :
MEMORY INDEX : 9.530
INTEGER INDEX : 8.846
FLOATING-POINT INDEX: 8.734
Максимально же при переборе ключей наблюдал на NUMERIC SORT и выше результаты до 835 включительно на атоме, но более сильно заваливались другие тесты. На данный момент уже есть комбинация ключей с достаточно приемлемым результатом, но пока еще она примерно на равных со старой версией. Нужно некоторое время, чтобы довести ее до ума.
Привожу как есть последний протестированный вариант (не окончательная версия):
CFLAGS=“-O3 -freorder-blocks -freorder-functions -fno-rerun-cse-after-loop -fno-sched-interblock -foptimize-sibling-calls -fno-delete-null-pointer-checks -fno-strict-overflow -fno-strict-aliasing -fno-tree-vrp -fno-tree-pre -fno-tree-switch-conversion -fsched-spec -fregmove -findirect-inlining -fno-crossjumping -fno-thread-jumps -falign-functions -falign-jumps -falign-loops -falign-labels -fno-tree-vectorize -fno-gcse-lm -fno-unswitch-loops -fno-predictive-commoning -fno-gcse-after-reload -fno-ipa-cp-clone -fno-cse-follow-jumps -fno-cse-skip-blocks -fexpensive-optimizations -march=native -mtune=native -fomit-frame-pointer -pipe --param l1-cache-line-size=64 --param l1-cache-size=32 --param l2-cache-size=256 -mmmx -msse -msse2 -msse3 -mssse3 -mfpmath=sse -msahf -mcx16 -fmerge-all-constants -fno-gcse --param max-unroll-times=4 --param max-unrolled-insns=72 --param max-average-unrolled-insns=216 -funroll-all-loops -g0”
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 736.8 : 18.90 : 6.21
STRING SORT : 118.59 : 52.99 : 8.20
BITFIELD : 2.8516e+08 : 48.91 : 10.22
FP EMULATION : 108.56 : 52.09 : 12.02
FOURIER : 7894.9 : 8.98 : 5.04
ASSIGNMENT : 16.527 : 62.89 : 16.31
IDEA : 2089.1 : 31.95 : 9.49
HUFFMAN : 891.09 : 24.71 : 7.89
NEURAL NET : 11.085 : 17.81 : 7.49
LU DECOMPOSITION : 533.28 : 27.63 : 19.95
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 38.557
FLOATING-POINT INDEX: 16.407
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU : Dual GenuineIntel Intel(R) Atom(TM) CPU N270 @ 1.60GHz 800MHz
L2 Cache : 512 KB
OS : Linux 3.1.10-gentoo-r1
C compiler : i686-pc-linux-gnu-gcc
libc :
MEMORY INDEX : 11.098
INTEGER INDEX : 8.644
FLOATING-POINT INDEX: 9.100
На данный момент выявлен основной ключ-весы -ftree-pre. Применение -ftree-pre заваливает одни тесты и вытягивает другие, его отмена -fno-tree-pre меняет производительность частей кода практически зеркально противоположным образом.
Использовать тестируемые конкретно в этом сообщении ключи не рекомендую. Лучше немного подождать более добротного варианта.