Ресурс Phoronix опубликовал (http://www.phoronix.com/scan.php?page=article&item=gcc_47_op...) результаты выполнения серии тестов производительности, выполненных при сборке с использованием различных режимов оптимизации GCC 4.7.2. Результаты тестирования позволяют оценить насколько велики отличия в производительности при выполнении тех или иных тестов, собранных с разными флагами оптимизации (-O0, -O1, -O2, -O3, -Os, -Ofast). Как правило, отличия не столько существенны, но как и можно ожидать лидируют режимы "-O3" и "-Ofast", от которых немного отстаёт "-O2".URL: http://www.phoronix.com/scan.php?page=article&item=gcc_47_op...
Новость: http://www.opennet.me/opennews/art.shtml?num=35080
А что это ещё за режимы оптимизации?
> А что это ещё за режимы оптимизации?Читайте маны, они рулез.
> Не нужно быть фанатом, нужно трезво оценивать ситуацию.Если трезво оценивать ситуацию, любая электроника может быть бракованной. Некоторый процент брака есть всегда. Что могут - ловят на этапе тестирования. Но как вы понимаете, возможен и случай когда чип кой-как пролез на грани а при малейшей деградации или изменении каких либо параметров - запаса не осталось и начались проблемы.
Если посмотреть на интель - так у них вообще бывают совершенно лютые факапы. У них то юсб выгорал от малейшего пшика статики, унося за собой весь чипсет, т.к. чудаки зачем-то сэкономили за защите от статики в чипе. То sata порты отпадали через некоторое время работы, потому что транзисторы не к тому питанию вообще подключили, то еще какая пакость приключалась. При том это именно лажа в дизайне, а не просто случайность приведшая к неудачным параметрам конкретного кристалла, может быть одного на всю пластину. И ничо, пипл схавал :)
Куда интереснее вопрос: были ли когда-либо у кого-либо проблемы с -О3 или -Оfast и тем более с -О2, и если нет, то почему их до сих пор не сделали по умолчанию.
естественно, были, есть и будут. Потому по дефолту используют только -O2
О-о-о, да! Неизгладимые впечатления оставили глюки при сборки CLFS... Когда-то использовал рекомендации по составлению опитимизируемого кода, но глубже изучив gcc плюнул - нормальная сборка с -O3 дело случая, качественный код полезнее писать))
wine например не будет пахать на системе скомпиленной на -O3. Только на -O2.
Пишу из Gentoo, полностью скомпилированной с "-march=amdfam10 -O3 -pipe". Wine работает.
Хм.. у меня вообще ни в какую. Пришлось всю на -O2 пересобирать. Пробовал отдельно глибец и вайн с -O2, но всё бестолку.
Обычно почти все, что начинает глючить от -O3 перестает при оптимизации -O3 -fno-tree-vectorizeТак как большая часть злобных багов в gcc как раз в модуле автовекторизации, который включается при -O3.
Интересно. Запомню, но и на -O2 уже и так хорошо.
> Пишу из Gentoo, полностью скомпилированной с "-march=amdfam10 -O3 -pipe". Wine работает.Звучит как "пишу из горящего танка" :)
DannyBoy, спасибо! Пересобрал сейчас wine с -О2 - и оно заработало! С -О3 у меня на Debian'e запускался криво, и вообще был считай неработоспособен...
> wine например не будет пахать на системе скомпиленной на -O3. Только на
> -O2.откуда мыслишки?
И да. -O2 это безопасная оптимизация. Т.е. прога к чертям не полетит от неё.
> Куда интереснее вопрос: были ли когда-либо у кого-либо проблемы с -О3Да запросто. Безопасно только -O2, а на -O3 на ряде программ вполне могут вылезти очень странные, а иногда еше и трудноуловимые глюки.
большинство (FreeBSD) работают, в часности, мир переживает О3 и проблем не наблюдается. А вот некоторые программы, типа мускуля/посгре/файрбёрд, почти всегда в корке - их обычно отдельно с О2 собирают.
> большинство (FreeBSD) работают, в часности, мир переживает О3 и проблем не наблюдается.
> А вот некоторые программы, типа мускуля/посгре/файрбёрд, почти всегда в корке -
> их обычно отдельно с О2 собирают.Бывало ловили глюки и на O3, и на O2.
http://sysoev.ru/freebsd/digest1.html
> Бывало ловили глюки и на O3, и на O2.
> http://sysoev.ru/freebsd/digest1.htmlFreeBSD 5? Давай, до свидания (c) :)
> большинство (FreeBSD) работают, в часности, мир переживает О3 и проблем не наблюдается."Если вам кажется что дела идут хорошо, значит вы просто чего-то не заметили".
А раньше озон сливал.
Полным ламером это написано:> Компилятор таких изменений в процессорной линейке не фиксирует и определить не способен. Они учитываются адекватными разработчиками адекватных дистрибутивов
на деле все наоборот, адекватные разработчики знать не знают о фишках ваших процессоров, и собирают пакеты под г-нo мамонта, плюс любят перестраховываться, собирая порой чуть ли не без оптимизаций вообще. В то же время компилятор с -march=native сам разберётся что у вас за процессор и соберет всё правильно. А O3 никто не мешает включать не для всего, а только там где он реально нужен - т.е. для числодробилок. И увеличением скорости всяких рейтрейсеров и физических рассчётов потом неосилятором оптимизаций в рoжу плевать.
И опять же, насчёт -O3. Почему все виновато молчат и никто не говорит о чьих-нибудь кривых руках?
Для применения -03 желательно понимать, что вся эта оптимизация хороша только на хорошем коде. Программисту надо знать, как gcc разбирает специфичные блоки кода и что в итоге получается на выходе.
Спасибо за ликбез
IMHO: сомнительные результаты - достаточно большое различие -O2 и -Os.
Например, здесь http://www.linux-mag.com/id/7574/1/ результаты несколько другие (правда для другого CPU и другой версии GCC).
А какие тесты Phoronix не сомнительны? У них такие эпикфейлы есть, вообще странно, что еще хоть кто-то воспринимает их всерьез.
> А какие тесты Phoronix не сомнительны? У них такие эпикфейлы есть, вообще
> странно, что еще хоть кто-то воспринимает их всерьез."Вот никаких и не читайте." ? "Вы не любите пролетариат!" :-P