Pull to refresh

Comments 55

Это еще ладно, что скорость в реальных приложениях зачастую не улучшается, так еще в редких случаях icc приводит к странным падениям и непонятным ошибкам.
В gcc они тоже случаются. Поэтому на каждую новую версию лучше переходить, когда у неё в конце будет хотя бы 4: 4.2.4, 4.4.4 и т.д.
Очень интересно, страшно интересно было бы взглянуть на результат CLang-а в даной ситуации
Кстати gcc имеет еще несколько хитростей:
ну например некоторые оптимизации не включенные даже в -O3 а также штуки навроде fastmath, которые понижают точность вычислений с плавающей точкой, но значительно их ускоряют.
Ну и еще в gcc есть такая штука, как gprof
www.network-theory.co.uk/docs/gccintro/gccintro_80.html
Суть её в том, что при первом проходе gcc в код добавляет некоторые счетчики и тому подобные вещи, потом приложение запускается, а на выходе появляется результирующий файл, после чего уже вторым прогоном можно по этому файлу дополнительно заоптимизировать приложение.
У ICC тоже есть возможность использовать оптимизацию вычислений с плавающей точкой: strict (без оптимизации), safe (оптимизация, не влияющая на результат), fast (с потерей точности). Причем именно последняя опция стоит по дефолту при включении оптимизации.
Это PGO? icc, кстати, тоже умеет.
PGO пробовали, большого выигрыша не было, поэтому здесь я его почти нигде не приводил.
А можете провести тесты производительности серверного ПО под разными компиляторами.

Было бы интересно посмотреть mysql, apache, php, и nginx.
UFO just landed and posted this here
Для gcc наилучшей опцией считается –O3


Это не совсем так, а иногда совсем не так. -O3 дает на выходе файлы куда большего размера, а значит приводит к повышенному потреблению памяти со всеми вытекающими.
Далеко не весь код хорошо оптимизируется с -O3 и бывает что результат оказывается хуже, чем -O2. А бывает что и вообще не собирается.
Так что в общем случае оптимальным вариантом все же считается -O2.
Почему тогда не -Os? Он использует почти все те же флаги оптимизации, что и -O2, кроме тех, что увеличивают размер итогового файла.
Начиная с четвертой версии gcc -Os направлен чисто на уменьшение размера и очень существенно проигрывает в производительности.
Пожалуй, это правда.
Большая часть кода FREngine собирается с флагом -O3, это меня заставило поверить, что он оптимальный.
UFO just landed and posted this here
Не совсем, -O3 это в первую очередь направление на оптимизацию скорости выполнения кода, в ущерб всему остальному. По типу как -Os оптимизация на уменьшение размера в ущерб всему остальному.
А -O2 компромиссный вариант. Поэтому многие методики оптимизации, которые вполне стабильны, так и останутся в -O3.
clang разве уже с «плюсами» нормально работает? Не так давно у него только С и Obj-C нормально получались.
Там поддержка плюсов уже относительно вменяемая, но всё равно даже не самый извращенный qutIM он уже не собирает
Вроде как они писали, что да
У него поддержка C++ пока совсем новая. Пока она устаканится, пройдёт ещё пару лет. Выгребать сейчас проблемы из-за того, что компилятор неправильно/по-другому поддерживает стандарт — не самый хороший способ потратить своё время.
clang пока хорошо юзать как статистический анализатор кода, на большее он не годится еще в случае с плюсами.
да ну, мы им успешно собираем достаточно тяжелые проекты для iOS, написанные на плюсах. И, вы знаете, работает.
Речь идёт о примерно 2 миллионах строк кода. Работает?
это вы у меня спрашиваете? у нас 500к строк, никаких проблем при переходе на clang вообще замечено не было.
Много строчек не означает, что проект тяжелый, если много шаблонов юзать, то clang иногда ну очень странные ошибки кидает, например не может найти деструктор, хотя он есть точно и все другие компиляторы: gcc,icc,msvs этот код нормально едят.
ну тут, как говорится, your mileage may vary…
Приветствую вас, Евгений,
ну, и ты, Аби заходи. ;-)

Рад, что Аби стала портировать на линюкс, прогресс, однако; мало наших компаний на пигвина обращают внимание.

Хочу показать вот эту ОЧЕНЬ важную статью:
habrahabr.ru/blogs/hardware/80050/
(там есть ссылка на метод преодоления даже)

Очень странно, что у вас в тестировании на АМД не выявилось ухудшения по сравнению с gcc.
Зато по сравнению с интелом в два раза хуже, как и предсказано.

Предположения:
а) возможно у вас процессор АМД ниже классом и явно слабее;

если же нет, то:
б) возможно в gcc встроена такая же гадость, или не встроена, а просто недопилен
в) возможно компилятор интела настолько хитёр, что на тривиальных задачах не портит код для АМД
Эту статью мы видели, даже сослались на неё :-)

По поводу AMD vs Intel. ICC обычно производит лучший код, чем gcc, просто это улучшение на архитектуре AMD не такое существенное, как улучшение на intel.
Всегда считалось что для гцц лучше всего -О2. Первый раз здесь слышу про -О3
-O3 нынче ещё и векторизацию в себя включает, а она может дать неслабый прирост производительности при правильной организации циклов.
А почему нету тестов для ветки gcc 4.5 он же теперь current?
+ интересно было бы посмотреть на результат работы FineReader Engine при сборке gcc с турбонадувом, привязкой под процессор и т.д. Возможно какие-то флаги из 4.5 ветки позволили бы увеличить скорость.
Поскольку FineReader Engine скорее всего будет собран для домашнего использования, включение подобных флагов допустимо.
1. В 4.2.1 напоролись на баг в компиляторе, так что теперь используем только хорошо протестированные и пропатченные версии компилятора.

2. См. первую таблицу. FR Engine — это серверный продукт. Затачиваться под конкретный процессор имеет смысл только под конкретного заказчика с большим кошельком, т.к. требует дополнительный билд и дополнительное тестирование.
Ну хотя бы ради интереса.
В gcc-4.5 появилась link time optimization, включается флагом -flto.
А почему недопустима сборка под конкретный процессор? ну или семейство?
Плохо совместимо с таблицей системных требований. Имеет смысл затачиваться на самый массовый процессор (флаг -mtune), но использовать набор инструкций, доступный практически всем современным процессорам.
ну может имеет смысл делать один общий билд

и еще парочку: для корки, i7 и тд — самые распространенные архитектуры
Было бы интересно еще и LLVM посмотреть, если это возможно.
ICC известны тем, что плюёт на стандарты IEEE о числах с плавающей точкой (п. 4.3.2). Поэтому следует сравнивать скорость компиляции с флагами gcc -mrecip и -ffast-math (конкретно — -funsafe-math-optimizations). Также gcc не делает -funroll-loops даже на уровне O3.

Если вам так нравится межпроцедурная оптимизация, советую попробовать скомпилировать в gcc 4.5 с флагом -flto. На практике может уменьшить размер исполняемого файла в разы (да-да), но мне не удалось ни разу заметить ускорение выполнения, отличное от погрешности измерения.

Если надо скомпилировать под текущий процессор, используйте флаг -march=native (компилятору виднее, какой набор инструкций у процессора).

Любопытно было бы узнать, какой версией ICC вы пользовались?
Спасибо. И за пост — отдельное спасибо, впечатляющее исследование.
Было бы лучше, если в итоге этого исследования мы перешли на icc. Тестовые замеры были очень многообещающими.
А уж нам бы как этого хотелось ;).
Но, полагаю, все понимают сложности подобного перехода. Сейчас главное, что ваш пост заставил задуматься… Будем посмотреть, что еще можно сделать.
Вообще, лучше чем O2 или O3 для gcc — итеративная компиляция. Дело в том, что в компиляторе несколько сотен оптимизаций, агрессивных и не очень. Очень важен порядок, в котором они применяются, ну и, конечно, применяются ли вообще (например, если бы в gcc была неудачная оптимизация циклов наподобие icc, то ее просто следует отключить). Ручками находить такую оптимальную последовательность — адский труд. Применяя эвристики вроде генетического алгоритма в acovea, можно достигнуть значительного прироста производительности программ, найдя нечто похожее на оптимум. Подробнее см. www.coyotegulch.com/products/acovea
Интересно, спасибо! Можно попробовать поставить такую штуку работать на неделю, вдруг найдёт оптимум.
Нашим компиляторщикам делают как раз такие заказы по ускорению кода (причем иногда пишем свои оптимизации для конкретных продуктов). Типичное время работы acovea составляет несколько дней, через 30 поколений получаются хорошие результаты
Интересная идея.
Насколько я понял, для поиска применяется генерический алгоритм, где роль особи выполняет, судя по всему, билд с конкретными опциями. Набор опций — это набор хромосом, который и подвергается скрещиванию/мутации. Функция приспособленности, очевидно, — время работы билда на каком-то(каком?) наборе тестов. Таким образом, всего полных компиляций и запусков происходит N * M, где N — количество особей в поколении, M — количество поколений(пусть 30). Особей в поколении, я полагаю, несколько десятков? Я правильно все понял?
Если да, то, боюсь, к FREngine'у это применить будет достаточно тяжело, потому что время полной сборки составляет около двух часов, а если их количество измеряется сотнями…
В любом случае, интересная идея, спасибо.
Тьфу ты, опять не туда! Никак не могу привыкнуть к древовидной структуре, а еще эта открытая формочка внизу страницы с приглашением к комментарию…
Дык, а зря Вы открещиваетесь от возможности сборки версии под конкретный процессор. Вот например, если я сканирую в промышленных масштабах, то рад 5% производительности мне будет не влом скачать и поставить версию именно под мой процессор.
Очень интересные результаты. Надо отметить, что вы отлично поработали. Я обязательно покажу ваши результаты дизайнерам компилятора. Было бы интересно посмотреть на результаты последнего Intel® Parallel C++ Composer XE (т.е. Intel® С++ Compiler Professional edition). Предлагаю пообщаться для этого уже в кулуарах, а по завершению совместной работы опубликовать результаты.
Ответил личным сообщением.
Sign up to leave a comment.