stasikos
10.08.2011 11:10
Gentoo Linux
— CFLAGS, CXXFLAGS и стоит ли так увлекаться их изменением?
Собственно, топик навеян одним спором с человеком, который упомянул что march=native это очень круто :)
Что предлагалось в оригинале?
1. Берем вот такой однострочник:
1 | touch /tmp/null.c; gcc -c -march=native -v /tmp/null.c 2>&1 | grep march | egrep -o -- '\s-m\S+|--param \S+' |
2. Запускаем его и смотрим то что выделил egrep (на Core2Duo T7250 например):
1 | -march=core2 -mcx16 -msahf --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=core2 |
Вах, круто - "тут оно оптимизирует даже под кеш!".
Теперь выбираем жертву бенчмарка - я выбрал FireFox 5 и его попугаи в PeaceKeeper. Жертва не очень сильная, потому что возможность его собирать с кастомными флагами по-умолчанию несколько урезана.
Берем отправную точку - дефолтные флаги, которые предлагаются в любом хендбуке:
1 |
Для FireFox включаем такое вот:
1 |
Это значит что он выбросит -O2 из флагов компилятора и будет использовать все остальное.
Собираем, запускаем бенчмарк браузера. Несколько раз. Лучше 3-5. И проверяем, что у нас выключен ondemand или другое средство для уменьшения частоты процессора и т.д.
В общем, я получил столько вот попугаев в среднем: 3762, с очень небольшим отклонением между тестами.
Теперь посмотрим, чего наделал мейнтейнер ебилда FireFox5 с оптимизацией, включаяя USE-флаг custom-optimization - это, как оказалось, просто добавляет к флагам -O2. Пересобираем, повторяем бенчмарки
Новое число попугаев: 4346.
Ок. Что же будет, если воспользоваться выводом, который нам предлагают взять, т.е. изменить CFLAGS на это:
-О2 -march=core2 -pipe -fomit-frame-pointer -mcx16 -msahf --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=core2?
Пересоберем, запустим, протестим и получим новых попугаев: 2983
Что-то стало заметно хуже, пришлось запускать тест раз 10, но результат упорно уперся в явно худшие цифры. Начинаем думать логически. FireFox в системе не один, может не стоит оптимизировать его под весь размер кеша? Меняем l2-cache-size=1024, получаем 2986 попугаев. Ситуация не меняется, так что я начинаю выкидывать флаги один за одним.
-msahf и -mcx16 по-одиночке отобрали около 100 попугаев у FireFox
--param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=2048 отобрали все остальную тысячу.
В итоге я пришел к такому вот CFLAGS:
1 |
и в конце концов пересобрав с ним весь мир, получил еще почти 100 попугаев сверх старых: 4432 (это как намек на "а влияет ли остальная система как-то значительно?).
Можно было бы еще поковыряться с более другой версией gcc (использовался gcc (Gentoo 4.4.5 p1.0, pie-0.4.5) 4.4.5), включить там graphite optimizations, но выходные кончились и я забил.
Что я точно сделал правильно - я сказал "Я не верю!" любителю все компилировать из сорцов, и, мне кажется, совсем не зря. Оказалось, что он наоборот замедляет свою систему.
P.S. Очевидно, любая другая программа, собранная с теми же флагами будет давать совершенно другой результат - она будет ускоряться, как это делает, например, nbench. Так что в конце концов может оказаться что CFLAGS должен индивидуально подбираться для приложений, а не system-wide. И тут же возникает вопрос - а может бинарные пакеты, собранные и оптимизированные майнтейнером в результате череды бенчмарков, они таки лучше?
P.P.S: firefox-bin на той же системе получил 3893 попугаев
Похожие
Поделиться
mironov_orig
10.08.2011 11:47
#
+
2
-
Ты преувеличиваешь вклад ментейнеров. Они собирают пакеты с -O2 и под паксимально возможное количество процов, так что всё "лучше" от бинарных пакетов уходит на то, что их не надо собирать и они дают максимальный безопасный разгон подо всё.
Но ведь не всегда измение флагов с -O2 на что-то дополнительное даст какой-то реальный прирост. Я вот слышал байку, что bzip2, например быстрее всего работает с -march=i686, нежели с чем-то еще, но не проверял.
Я не спорю про скорость, я лишь говорю, что ментейнеры не устраивают полноценное тестирование и перебор флагов.
А в однострочнике лучше убрать --color, но добавить -o. В разы нагляднее имхо.
А вот это уже ощутимый удар по оптимизяторам =) Ждём megabaks'a в топике )
shisoid
а зачем меня ждать?
www-client/firefox (alsa dbus ipc linguas_en linguas_ru methodjit webm) - 5746 Points
www-client/firefox-bin - 5654 Points
www-client/firefox (alsa dbus ipc linguas_en linguas_ru methodjit webm) - 5746 Points
www-client/firefox-bin - 5654 Points
я лисой не пользуюсь - потому не и не крутил/тестил
ща посмотрю с кастом-* юзами
ща посмотрю с кастом-* юзами
Имхо основной прирост от оптимизации должен наблюдаться от флагов вроде msse4.(1|2) и подобного в мультимедиа числодробилках типа mencoder (хотя там есть runtime cpu detection) ffmpeg, flac или подобного.
digiwhite
Scrill
Я на T7500 дооптимизировался до такого:
-march=core2 -O2 -pipe -mmmx -mssse3 -msahf -mcx16 -mtune=core2
а чуть позже оказалось, что это одно и то же с:
-march=native -O2 -pipe -mmmx -mssse3
-march=core2 -O2 -pipe -mmmx -mssse3 -msahf -mcx16 -mtune=core2
а чуть позже оказалось, что это одно и то же с:
-march=native -O2 -pipe -mmmx -mssse3
devl547
гента? на С2D? и 32-битная? нет пути!
Попробуй -fivopts, -ftree-loop-im, -ftree-loop-ivcanon, -ffast-math и что-нибудь из этой серии.
А в целом - большая часть опций сборки помогает выжать проценты производительности, не больше. Какие-то лишние секунды в архивации или перекодировании видео погоды не сделают. Сравнивая например свой SliTaz (у нас там вообще 486 тулчейн) со своей же гентой в большей части задач разницы нет.
Попробуй -fivopts, -ftree-loop-im, -ftree-loop-ivcanon, -ffast-math и что-нибудь из этой серии.
А в целом - большая часть опций сборки помогает выжать проценты производительности, не больше. Какие-то лишние секунды в архивации или перекодировании видео погоды не сделают. Сравнивая например свой SliTaz (у нас там вообще 486 тулчейн) со своей же гентой в большей части задач разницы нет.
Секунды и проценты хорошо будут видны при пакетной обработке видео/аудио/картинок, но для десктопа это очень редкая задача. )
thoughtful_fox
Нян, а что такого страшного с 32бит на кор2дуо? Мне вот совсем не улыбается возиться с мультилибами и размазанным юзерлендом... Что поделать, но рабочий софт довольно часто бывает все еще 32битный.
Пожалуй, стоит собрать на одной платформе две генты и сравнить 32 и 64 на том же файрфоксе. Интересно, сколько там процентов будет профита, и стоит ли оно того?
ПС. я руками-ногами за 64, только скажите это ораклу
Пожалуй, стоит собрать на одной платформе две генты и сравнить 32 и 64 на том же файрфоксе. Интересно, сколько там процентов будет профита, и стоит ли оно того?
ПС. я руками-ногами за 64, только скажите это ораклу
> Какие-то лишние секунды
4.2, лишние проценты. к примеру 2% для gzip это
4.2, лишние проценты. к примеру 2% для gzip это
1 2 |
не стОит
натив не всегда годится - например с distcc (объяснять, думаю не надо)
если уж и загоняться по флагам, то только для наиболее востребованного софта
и не стОит использовать экзотику (игры с циклами, грифты и прочее), т.к. если в данной версии компилятора они дают профит, то на следующей могут легко дать регресс
сам использую
"-fomit-frame-pointer" остался даже после перехода на 4.6 (в 4.6 на 32-х битах теперь сей флажок - дефолт), т.к. некоторый софт собираю старыми версиями (например первогруб не работает, если собрать с 4.6)
по поводу генерика - на очень многих процах даёт таки профит
всякие ffast-math тоже стоит использовать осторожно - редко где дают профит, обычно или ничего или регресс
а вообще...хозяин - барин
натив не всегда годится - например с distcc (объяснять, думаю не надо)
если уж и загоняться по флагам, то только для наиболее востребованного софта
и не стОит использовать экзотику (игры с циклами, грифты и прочее), т.к. если в данной версии компилятора они дают профит, то на следующей могут легко дать регресс
сам использую
1 |
по поводу генерика - на очень многих процах даёт таки профит
всякие ffast-math тоже стоит использовать осторожно - редко где дают профит, обычно или ничего или регресс
а вообще...хозяин - барин
> т.к. если в данной версии компилятора они дают профит, то на следующей могут легко дать регресс
У меня при перехода от 4.5.2 к 4.6.1 gzip дал прирост производительности 1.7%.(с графитом)
У меня при перехода от 4.5.2 к 4.6.1 gzip дал прирост производительности 1.7%.(с графитом)
молодец, а вот при переходе с 4.4 на 4.5 с графитом он даёт регресс
причём заметный
причём заметный
Хм...
Тест SunSpider
firefox-bin : 265 мс
firefox (default) : 255 мс
firefox (c native и сflags) : 236 мс
Funtoo gcc-4.4.5, core i5, 32 бит, не graphite
эх, не потестил на Пискипере, не успел) Покопаюсь-ка я в документации к gcc по такому поводу, но как-то уже на домашней машинке, а не на рабочей.
Тест SunSpider
firefox-bin : 265 мс
firefox (default) : 255 мс
firefox (c native и сflags) : 236 мс
Funtoo gcc-4.4.5, core i5, 32 бит, не graphite
эх, не потестил на Пискипере, не успел) Покопаюсь-ка я в документации к gcc по такому поводу, но как-то уже на домашней машинке, а не на рабочей.
SunSpider: firefox-bin - 1329.9ms +/- 0.6%
firefox (с тем что в топике) - 1437 +/- 0.4%
какие-то спорные результаты... :(
firefox (с тем что в топике) - 1437 +/- 0.4%
какие-то спорные результаты... :(
Апдейт по ПисКиперу:
файрфокс-бин - 5956 поинтов;
файрфокс с нативом и кастом флагами - 6364;
32 бит система. В данном случае это важно)
Отака штука.
На самом деле разброс не столь грандиозен, но все же небольшой профит есть. Все же, я сначала пороюсь в документации побольше, мало ли чего)
файрфокс-бин - 5956 поинтов;
файрфокс с нативом и кастом флагами - 6364;
32 бит система. В данном случае это важно)
Отака штука.
На самом деле разброс не столь грандиозен, но все же небольшой профит есть. Все же, я сначала пороюсь в документации побольше, мало ли чего)
Тот же firefox (с тем что в топике) но с включенными плагинами - 394.2 ms
firefox-bin - 402.8ms
firefox-bin - 402.8ms
thebeetlebum
Не знаю стоит ли лезть с моим старым железом и циферками, но все же.
Стенд: toshiba nb200-10z (UPD 2GB RAM) Intel Atom N280
firefox-bin:
firefox (gcc 4.5.3)
GRAPHITE="-floop-interchange -floop-block -floop-strip-mine"
CFLAGS="-O2 -march=atom -mtune=atom -mfpmath=sse -mssse3 -fomit-frame-pointer -pipe --param l2-cache-size=512 ${GRAPHITE}"
Сейчас пересяду на gcc 4.6 и посмотрим на цифры там с графитом и без него.
А пользователей с icc нет?
Стенд: toshiba nb200-10z (UPD 2GB RAM) Intel Atom N280
firefox-bin:
- sunspider: 1262.9 ± 0.9%
- peacekeeper: 943 points
firefox (gcc 4.5.3)
- sunspider: 1235.8 ± 0.9%
- peacekeeper: 967 points
GRAPHITE="-floop-interchange -floop-block -floop-strip-mine"
CFLAGS="-O2 -march=atom -mtune=atom -mfpmath=sse -mssse3 -fomit-frame-pointer -pipe --param l2-cache-size=512 ${GRAPHITE}"
Сейчас пересяду на gcc 4.6 и посмотрим на цифры там с графитом и без него.
А пользователей с icc нет?
Это у вас 5-й Firefox? А то я этот же суньспайдер запустил на Core i7-2600 в 64-битной системе но в Firefox 3.6 - вот я такие же циферки получил. :) Причем, что интересно, процессор тест не нагружал, а постоянно что-то дергал по сети с сервера.
firefox-6.0 (gcc 4.5.3)
sunspider: 1217 ms ± 1.8%
peacekeeper: 1008 points
Intel Core 2 Duo E6400 2.13GHz @ 3.14GHz
CFLAGS="-O2 -march=core2 -mtune=generic -mfpmath=sse -mssse3 -fomit-frame-pointer -pipe"
firefox 6.0 USE="alsa crashreporter dbus ipc libnotify linguas_en linguas_ru methodjit webm"
firefox 6.0 USE="alsa crashreporter custom-cflags custom-optimization dbus ipc libnotify linguas_en linguas_ru methodjit pgo startup-notification system-sqlite webm"
Итого, по первому тесту увеличение производительности на 5%, по второму на 11%
CFLAGS="-O2 -march=core2 -mtune=generic -mfpmath=sse -mssse3 -fomit-frame-pointer -pipe"
firefox 6.0 USE="alsa crashreporter dbus ipc libnotify linguas_en linguas_ru methodjit webm"
- sunspider 231.2ms
- peacekeeper 6006 points
firefox 6.0 USE="alsa crashreporter custom-cflags custom-optimization dbus ipc libnotify linguas_en linguas_ru methodjit pgo startup-notification system-sqlite webm"
- sunspider 220.1ms
- peacekeeper 6687 points
Итого, по первому тесту увеличение производительности на 5%, по второму на 11%
> Оказалось, что он наоборот замедляет свою систему.
Что замедляет? у тебя 2с половиной калеки, а не разные CFLAGS.
Что замедляет? у тебя 2с половиной калеки, а не разные CFLAGS.
CFLAGS="-O2 -march=native -mtune=native -pipe -fomit-frame-pointer \
-mfpmath=sse+387 -mmmx -msse3 -mssse3 -mcx16 -msahf -ftree-vectorize -ftracer \
-ftree-loop-linear -floop-interchange -floop-block -floop-strip-mine -fgraphite-identity \
--param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=1024 \
-fbranch-probabilities -fvpt -fexcess-precision=fast -fexpensive-optimizations -mstackrealign \
-finline-functions-called-once -fno-align-labels -fpredictive-commoning -funswitch-loops \
-fbranch-target-load-optimize -fbranch-target-load-optimize2 -fpeel-loops \
-fforce-addr -fgcse-after-reload -fivopts -fmerge-all-constants \
-frename-registers -ftree-loop-im -fsee \
${PROFILE} \
"
некоторые из -f* подключаются на native/02, но мне так надёжнее.
-mfpmath=sse+387 -mmmx -msse3 -mssse3 -mcx16 -msahf -ftree-vectorize -ftracer \
-ftree-loop-linear -floop-interchange -floop-block -floop-strip-mine -fgraphite-identity \
--param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=1024 \
-fbranch-probabilities -fvpt -fexcess-precision=fast -fexpensive-optimizations -mstackrealign \
-finline-functions-called-once -fno-align-labels -fpredictive-commoning -funswitch-loops \
-fbranch-target-load-optimize -fbranch-target-load-optimize2 -fpeel-loops \
-fforce-addr -fgcse-after-reload -fivopts -fmerge-all-constants \
-frename-registers -ftree-loop-im -fsee \
${PROFILE} \
"
Нет, недостаточно - и я как раз написал что вот только это:
-mcx16 -msahf --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=1024
как раз таки может отобрать 20% производительности приложения. Что, собственно явно показано именно на этих калеках. Или ты из тех кто "больше флагов - быстрее приложения"? :)
-mcx16 -msahf --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=1024
как раз таки может отобрать 20% производительности приложения. Что, собственно явно показано именно на этих калеках. Или ты из тех кто "больше флагов - быстрее приложения"? :)
> Или ты из тех кто "больше флагов - быстрее приложения"? :)
Телепат?
> -mcx16 -msahf --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=1024
Пробовал отключать при сборке gzip, потери производительности не обнаружено -> у тебя жёсткое и двойное 4.2
Телепат?
> -mcx16 -msahf --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=1024
Пробовал отключать при сборке gzip, потери производительности не обнаружено -> у тебя жёсткое и двойное 4.2
>> Пробовал отключать при сборке gzip, потери производительности не обнаружено -> у тебя жёсткое и двойное 4.2
У тебя лучше аргументы есть? Или 4.2 это твой показатель нефанатичности?
У тебя лучше аргументы есть? Или 4.2 это твой показатель нефанатичности?
> У тебя лучше аргументы есть?
Ты обкуренный, или отсутствие потери производительности не аргумент?
Ты обкуренный, или отсутствие потери производительности не аргумент?
Не, ну чтобы меня еще обкуреным обозвали после целого поста с результатами, которые показывают потерю производительности - такого я от этого ресурса не ожидал.
Сомнительные? В чем?
Ну так покажи не сомнительные-то, чего от тебя добиваются уже много дней-то. Еще и толпу своих фанатиков на меня натравил.
Ну так покажи не сомнительные-то, чего от тебя добиваются уже много дней-то. Еще и толпу своих фанатиков на меня натравил.
сойдёт) не разворачиваются:
-march=native -pipe -O2
-mfpmath=sse+387 -mmmx -msse3 -mssse3 -ftree-vectorize -ftracer
-ftree-loop-linear -floop-interchange -floop-block -floop-strip-mine -fgraphite-identity(graphite)
и пара -f*
-mfpmath=sse+387 -mmmx -msse3 -mssse3 -ftree-vectorize -ftracer
-ftree-loop-linear -floop-interchange -floop-block -floop-strip-mine -fgraphite-identity(graphite)
и пара -f*
не сойдёт
ибо графит даёт профит на очень малом кол-ве пакетов
на том же bzip2 только регресс причём овер 10%
так что думай дальше
ибо графит даёт профит на очень малом кол-ве пакетов
на том же bzip2 только регресс причём овер 10%
так что думай дальше
не надо совать sudo с echo PASSWORD | sudo в скрипты, это не сработает (ну и это почти все знают) ;). Лучше тогда уже весь скрипт запускать от рута чем такие выкрутасы делать.
> это не сработает (ну и это почти все знают) ;)
а теперь "жри свои слова"
echo "$ROOT_PASSWORD" | sudo -S bash -c "$1"
а теперь "жри свои слова"
echo "$ROOT_PASSWORD" | sudo -S bash -c "$1"
> Собственно, топик навеян одним спором с человеком, который упомянул что march=native это очень круто :)
ссылку.
ссылку.
Это начинает напоминать передачу MythBusters. Вышел слух, и человек его проверил. И как правило эксперимент всегда можно довести до ума, как и флаги в данном случае. native крут лишь в том случае, если ты ничего кроме него не знаешь и у тебя нет времени/желания/потенции с этим заниматься. Ну и опять же. Native сильно зависит от машины. У кого-то оно даст прирост в сравнении с bin, у кого-то регресс. Надо взять того человека и посмотреть на тесты у него.
-march=native и моя распределенная сборка (distcc) на трех компах будет выдавать бинари кусочно-оптимизированные под разные процы. будет весело запускать!
ну так на время отключи distcc и покажи результаты своих тестов. И кстати говоря, у меня есть мнение, что ff вообще под distcc не соберется.
Вот в том то и дело - речь идет о глобальном изменении, или только в отношении некоторого пакета. Многие пакеты не оптимизируются флагами оптимизации, имея жестко заданные.
Глобально стоит переключать только march (mtune уже включен в march, поэтому зачем его припекли еще, неясно - разница только в том, что mtune вносит несовместимый код).
Использовать ли глобально O2 или O3 - сугубо индивидуально, ибо разжирение бинарников на 30% даёт может быть процентов 5-10 скорости.
Использовать ли локально разные ключи оптимизации, коих намного больше, чем было указано - конечно использовать. На чем оптимизировать ключи? Для каждого пакета, в рамках того, насколько разработчики исходников обладали пониманием.
Есть ли какая-нибудь кукла для испытаний? Скорее всего, нет. Ибо пакеты слишком разнородны. Медиапакеты заточены на использование флагов фич процессоров. Пакеты для мультикоре не нуждаются в оптимизациях вообще. Что в остатке? Оптимизировать виджеты и разные другие рюшечки-окошечки? В общем, я не вижу смысла для себя поднимать глобально выше -O2, а лучше вообще -O. Код должен быть написан нормально, чтобы его не приходилось вообще "оптимизировать".
Глобально стоит переключать только march (mtune уже включен в march, поэтому зачем его припекли еще, неясно - разница только в том, что mtune вносит несовместимый код).
Использовать ли глобально O2 или O3 - сугубо индивидуально, ибо разжирение бинарников на 30% даёт может быть процентов 5-10 скорости.
Использовать ли локально разные ключи оптимизации, коих намного больше, чем было указано - конечно использовать. На чем оптимизировать ключи? Для каждого пакета, в рамках того, насколько разработчики исходников обладали пониманием.
Есть ли какая-нибудь кукла для испытаний? Скорее всего, нет. Ибо пакеты слишком разнородны. Медиапакеты заточены на использование флагов фич процессоров. Пакеты для мультикоре не нуждаются в оптимизациях вообще. Что в остатке? Оптимизировать виджеты и разные другие рюшечки-окошечки? В общем, я не вижу смысла для себя поднимать глобально выше -O2, а лучше вообще -O. Код должен быть написан нормально, чтобы его не приходилось вообще "оптимизировать".
Вообще, на современном железе заниматься подобной оптимизацией, имхо, смысла нет. Я изначально, когда ставил себе Gentoo, тоже долго вчитывался в мануалы gcc и искал максимально быстрое сочетание флагов. Но в итоге выяснилось, что это приносит прирост производительности в полпроцента(если судить в среднем по приложениям). Поигравшись с разными настройками, я пришёл к мнению, что достаточно включить оптимизацию по типу процессора(в моём случае это ARCH="amd64" и MARCH="k8") и минимум флагов, основной смысл из которых несёт -O2.
Да, возможно, если тот же firefox пересобрать, используя множество хитрых оптимизирующих ключей, он будет запускаться на полсекунды быстрее. Но при этом никто не гарантирует, что эти же флаги хорошо повлияют на какой-нибудь mplayer. И в таком случае мне эти полсекунды совершенно не нужны.
Да, возможно, если тот же firefox пересобрать, используя множество хитрых оптимизирующих ключей, он будет запускаться на полсекунды быстрее. Но при этом никто не гарантирует, что эти же флаги хорошо повлияют на какой-нибудь mplayer. И в таком случае мне эти полсекунды совершенно не нужны.
