[ЖЖ][GCC]О флагах оптимизации

Понятно...

А я теперь всё с опциями icc играю :)

>>А я теперь всё с опциями icc играю :)

В моём случаи это не труЪ, ибо проц от AMD :) Хотя ради интереса глянул бы, вот только с моим инетом качать компилятор "немаленьких" размеров - мазохизм.

ЗЫ: кто-нить в курсе, слухи о том что icc не компилирует ничего толкового для AMD-процов - правда? :)

>ЗЫ: кто-нить в курсе, слухи о том что icc не компилирует ничего толкового для AMD-процов - правда? :)

Сегодня, пока рылся в форумах, перед глазами неоднократно пробегал этот вопрос. Но в детали не вдавался. Общий поверхностный осадок - icc на amd работает, но принципиально не лучше и не хуже gcc.

>>Сегодня, пока рылся в форумах, перед глазами неоднократно пробегал этот вопрос. Но в детали не вдавался.

ага, аналогично не изучал сильно вопрос, но когда читал об icc, то пробегали некоторые месседжи, но конкретики не было.

Что-то я не понял, теперь можно кино в четыре раза быстрее смотреть?

угу, запуская mplayer с ключом -benchmark :D

Забавно, я тоже баловался.. Попробуй профайлингом еще позаниматься, но там эффект все же не такой уж серьезный

Фигня, все эти ваши оптимизации, какие-то жалкие процессы. Проще процессор помощнее купить.

s/процессы/проценты/

вы просто идеальный клиент фирмы Microsoft :) Для вас уних есть специальное предложение в лице Windows Vista.

>> Итак, проверить решил на том, что чаще всего в обиходе - mplayer.

Такой вопрос: а ты только mplayer пересобирал с новыми флагами? Просто он сам почти ничего не делает, нужно пересобирать ffmpeg, x264, etc.

А вообще, в среднем программы собранные с -O2 работают быстрее чем с другими режимами оптимизации, так как на -O3 и выше включаются некоторые агрессивные оптимизации из-за которых код распухает, даёт лишнюю нагрузку на кеш и плохо поддаётся предсказаниям. Но это не всегда так. -Os - это тот же -O2, только без оптимизаций, которые могут привести к увеличению объёма кода.

mplayer не лучший вариант для подобных тестов

> Athlon X2 3800+(@2.52Ггц), 1Гб DDR2-800

Диагноз ясен, озвучивать не буду.

Так я не понял, ведро уже icc собирает без патчей или как?

>Но это не всегда так. -Os - это тот же -O2, только без оптимизаций, которые могут привести к увеличению объёма кода.

Только ты ещё забыл про «It also performs further optimizations designed to reduce code size.» И вот из-за этих оптимизаций скорость падает весьма ощутимо. Я уже писал, что однажды, пытаясь сэкономить память на десктопе и начитавшись, что «-Os - это тот же -O2» перевёл всю систему на -Os. Тормоза были просто удручающие :)

>Так я не понял, ведро уже icc собирает без патчей или как?

Не знаю, ядро у меня GCC-шной сборки.

>>а ты только mplayer пересобирал с новыми флагами?

У меня mplayer собирается статически с последним ffmpeg, который стягивается из svn'а :) Т.е. для теста собиралось все что нужно для проигрывание ролика(не пойму правда зачем ты в список енкодер x264 внес :)). А про флаги - при -march=i686 разница между -O2 и -O3 минимальна(доли меиллисекунд, что вписывается в пределах погрешности тестирования). Стоило -march заменить на athlon64, разница сразу выросла до стабильной 1сек.

>>Silvy: mplayer не лучший вариант для подобных тестов

да, в разных ситуациях может быть по разному, но mplayer чаще всего используется из того софта, где можно что-то проверить :) Можно конечно издеваться с gzip/bzip2/etc., но это неинтересно :)

>>Gharik: Диагноз ясен, озвучивать не буду.

можешь не напрягаться, мне это не интересно :) Разгон не смертельный, но был очень важен, когда пришлось рипать 26 DVD-диска с GitS'ами )

А еще, как ему сказать, чтобы не привязывал свою libimf.so?

>> Только ты ещё забыл про «It also performs further optimizations designed to reduce code size.»

Действительно, это часть в мане я как-то проглядел 8).

прибить ее ) -limf будет в таком случае линковать с libimf.a

а вот с libintlc.so это не пройдет... там нет статической библиотеки

libsvml.so - туда же

остальные он кажется не прилинковывает

да и статически она мне не сдалась. Тем более либы не маленькие.

IMF = intel memory functions

fast_memcpy и прочее

за счет этого оно быстрее и работает, если нужно отбросить imf - лучше уже сразу собирать с GCC, разница в производительности итак минимальна

gcc 4.3.2 -O3 -fomit-frame-pointer -mmmx -msse -msse2 -msse3 -march=native -mtune=native -g0

>gcc 4.3.2 -O3 -fomit-frame-pointer -mmmx -msse -msse2 -msse3 -march=native -mtune=native -g0

А смысл этого без "-mfpmath=sse -ftree-vectorize" ?

>> да и статически она мне не сдалась. Тем более либы не маленькие.

При статической компоновке всё неиспользуемое должно выкинуться. Если конечно не используются функции типа doEverythingAtOnce, которые вытянут все кишки библиотеки за собой.

спасибо, посмотрю что за флажки

> > Athlon X2 3800+(@2.52Ггц), 1Гб DDR2-800

> Диагноз ясен, озвучивать не буду.

это ты про разгон, что ли?

>>это ты про разгон, что ли?

у Гарика видать какие-то комплексы :) И ему невдомёк, что на 1.8Ггц даже обыкновенные 1080p рипы особо не посмотреть, да и скорость кодирование видео не фонтан. Да и если подобный разгон дался даром, то почему бы и нет? Возможностей СО хватает, дабы удерживать температуру процессора в допустимых пределах.

> 1.8Ггц

хм, у меня тоже 3800+ и там 2ггц

> Возможностей СО хватает, дабы удерживать температуру процессора в допустимых пределах.

у меня на со стандартным кулером только до 2.2 получалось разгонять

>>хм, у меня тоже 3800+ и там 2ггц

Тьфу блин, че-то очепятался, просто недавно имел дело со стареньким Athlon 2500+, вот че-то и пристала цифра 1.8 )

>>у меня на со стандартным кулером только до 2.2 получалось разгонять

На это много факторов влияет :) Допустим память у меня спокойно работает на частоте чуть выше 800МГц, материнская плата вытягивает FSB свыше 260Мгц, но тогда и проц начинается греться, и HT-шина уже не выдерживает. Поэтому остановился на среднем значении в 252, хотя более органично вписывает 240 по FSB, когда частота становится 2.4Ггц и память ровно DDR2-800 :)

> это ты про разгон, что ли?

Ну а про что ещё? Сказки про "бесплатно" тот пылкий юноша пусть девочкам рассказывает, платить общей нестабильностью системы и резким повышением вероятности сбоев вменяемому народу весьма неохота.

P.S. К тому ж 1080p замечательно смотрится в MPEG-2 =)

>>Сказки про "бесплатно" тот пылкий юноша пусть девочкам рассказывает, платить общей нестабильностью системы и резким повышением вероятности сбоев вменяемому народу весьма неохота.

Много консерватизма, паранойи и т.д. вижу в тебе я :) Да, не везде разгон возможен и "бесплатен", но моя машина работает уже больше чем полтора года в таком режиме, ниче, еще ниодного левого бага, падения, зависания и т.д., хотя нагрузки были - тоже кодирование видео сутками на пролёт :) Не сравнимо конечно с серверами, но разгонять сервера - это да, идиотизм )

ЗЫ: хотя странный ты, такое ощущение, что ты о разгоне наслышан, ровно столько же, сколько виндоуз-юзеры о "страшном Linux с консолью, в котором даже видео смотреть нельзя!".

ЗЫЫ: Ну и на какую машинку хватило денег, такую и купил, специально для разгона её не брал. Просто так уж повезло с моделью и остальными комплектующими. Старая машина была более удачной - 64-битный Sempron 2800+, который до сих пор стабильно работает в режиме 2.4Ггц(FSB 300, дальше не пустила материнская плата, ибо в BIOS это было предельное значение :)), хотя стандартная его частота - 1.6Ггц. При этом температурный режим его не изменился почти, от чего можно предположить, что мне попалась старшая модель не прошедшая тестирования, которую отправили в продажу с пониженными частотами... в общем лан, рекомендую просто ознакомится с тем как процессоры проходят маркировку, и не раздавать людям странные диагнозы из-за собственных фобий/etc. :)

>>P.S. К тому ж 1080p замечательно смотрится в MPEG-2 =)

:)

> начитавшись, что «-Os - это тот же -O2» перевёл всю систему на -Os. Тормоза были просто удручающие :)

Если "удручающие тормоза" означают больше 10-15% производительности, рекомендую написать в багзиллу gcc, вдруг поправят.

>Если "удручающие тормоза" означают больше 10-15% производительности

Много больше. «в граммах» не измерял, но общее ощущение работы за системой было - как будто даунгрейд на два поколения. Что-нить типа Celeron-733 :) (при родном Athlon XP).

>рекомендую написать в багзиллу gcc, вдруг поправят.

Вряд ли они по 4.1 версиям баги принимают. А с новыми gcc экспериментировать лень.