Comments 55
Это еще ладно, что скорость в реальных приложениях зачастую не улучшается, так еще в редких случаях icc приводит к странным падениям и непонятным ошибкам.
0
Кстати gcc имеет еще несколько хитростей:
ну например некоторые оптимизации не включенные даже в -O3 а также штуки навроде fastmath, которые понижают точность вычислений с плавающей точкой, но значительно их ускоряют.
Ну и еще в gcc есть такая штука, как gprof
www.network-theory.co.uk/docs/gccintro/gccintro_80.html
Суть её в том, что при первом проходе gcc в код добавляет некоторые счетчики и тому подобные вещи, потом приложение запускается, а на выходе появляется результирующий файл, после чего уже вторым прогоном можно по этому файлу дополнительно заоптимизировать приложение.
ну например некоторые оптимизации не включенные даже в -O3 а также штуки навроде fastmath, которые понижают точность вычислений с плавающей точкой, но значительно их ускоряют.
Ну и еще в gcc есть такая штука, как gprof
www.network-theory.co.uk/docs/gccintro/gccintro_80.html
Суть её в том, что при первом проходе gcc в код добавляет некоторые счетчики и тому подобные вещи, потом приложение запускается, а на выходе появляется результирующий файл, после чего уже вторым прогоном можно по этому файлу дополнительно заоптимизировать приложение.
+3
Это PGO? icc, кстати, тоже умеет.
PGO пробовали, большого выигрыша не было, поэтому здесь я его почти нигде не приводил.
PGO пробовали, большого выигрыша не было, поэтому здесь я его почти нигде не приводил.
+2
А можете провести тесты производительности серверного ПО под разными компиляторами.
Было бы интересно посмотреть mysql, apache, php, и nginx.
Было бы интересно посмотреть mysql, apache, php, и nginx.
-19
Для gcc наилучшей опцией считается –O3
Это не совсем так, а иногда совсем не так. -O3 дает на выходе файлы куда большего размера, а значит приводит к повышенному потреблению памяти со всеми вытекающими.
Далеко не весь код хорошо оптимизируется с -O3 и бывает что результат оказывается хуже, чем -O2. А бывает что и вообще не собирается.
Так что в общем случае оптимальным вариантом все же считается -O2.
+3
Почему тогда не -Os? Он использует почти все те же флаги оптимизации, что и -O2, кроме тех, что увеличивают размер итогового файла.
0
Пожалуй, это правда.
Большая часть кода FREngine собирается с флагом -O3, это меня заставило поверить, что он оптимальный.
Большая часть кода FREngine собирается с флагом -O3, это меня заставило поверить, что он оптимальный.
+1
UFO just landed and posted this here
Не совсем, -O3 это в первую очередь направление на оптимизацию скорости выполнения кода, в ущерб всему остальному. По типу как -Os оптимизация на уменьшение размера в ущерб всему остальному.
А -O2 компромиссный вариант. Поэтому многие методики оптимизации, которые вполне стабильны, так и останутся в -O3.
А -O2 компромиссный вариант. Поэтому многие методики оптимизации, которые вполне стабильны, так и останутся в -O3.
+1
А попробуйте за одно и clang…
0
clang разве уже с «плюсами» нормально работает? Не так давно у него только С и Obj-C нормально получались.
+2
У него поддержка C++ пока совсем новая. Пока она устаканится, пройдёт ещё пару лет. Выгребать сейчас проблемы из-за того, что компилятор неправильно/по-другому поддерживает стандарт — не самый хороший способ потратить своё время.
0
clang пока хорошо юзать как статистический анализатор кода, на большее он не годится еще в случае с плюсами.
0
да ну, мы им успешно собираем достаточно тяжелые проекты для iOS, написанные на плюсах. И, вы знаете, работает.
+1
Речь идёт о примерно 2 миллионах строк кода. Работает?
0
Много строчек не означает, что проект тяжелый, если много шаблонов юзать, то clang иногда ну очень странные ошибки кидает, например не может найти деструктор, хотя он есть точно и все другие компиляторы: gcc,icc,msvs этот код нормально едят.
0
Приветствую вас, Евгений,
ну, и ты, Аби заходи. ;-)
Рад, что Аби стала портировать на линюкс, прогресс, однако; мало наших компаний на пигвина обращают внимание.
Хочу показать вот эту ОЧЕНЬ важную статью:
habrahabr.ru/blogs/hardware/80050/
(там есть ссылка на метод преодоления даже)
Очень странно, что у вас в тестировании на АМД не выявилось ухудшения по сравнению с gcc.
Зато по сравнению с интелом в два раза хуже, как и предсказано.
Предположения:
а) возможно у вас процессор АМД ниже классом и явно слабее;
если же нет, то:
б) возможно в gcc встроена такая же гадость, или не встроена, а просто недопилен
в) возможно компилятор интела настолько хитёр, что на тривиальных задачах не портит код для АМД
ну, и ты, Аби заходи. ;-)
Рад, что Аби стала портировать на линюкс, прогресс, однако; мало наших компаний на пигвина обращают внимание.
Хочу показать вот эту ОЧЕНЬ важную статью:
habrahabr.ru/blogs/hardware/80050/
(там есть ссылка на метод преодоления даже)
Очень странно, что у вас в тестировании на АМД не выявилось ухудшения по сравнению с gcc.
Зато по сравнению с интелом в два раза хуже, как и предсказано.
Предположения:
а) возможно у вас процессор АМД ниже классом и явно слабее;
если же нет, то:
б) возможно в gcc встроена такая же гадость, или не встроена, а просто недопилен
в) возможно компилятор интела настолько хитёр, что на тривиальных задачах не портит код для АМД
-1
Всегда считалось что для гцц лучше всего -О2. Первый раз здесь слышу про -О3
+2
А почему нету тестов для ветки gcc 4.5 он же теперь current?
+ интересно было бы посмотреть на результат работы FineReader Engine при сборке gcc с турбонадувом, привязкой под процессор и т.д. Возможно какие-то флаги из 4.5 ветки позволили бы увеличить скорость.
Поскольку FineReader Engine скорее всего будет собран для домашнего использования, включение подобных флагов допустимо.
+ интересно было бы посмотреть на результат работы FineReader Engine при сборке gcc с турбонадувом, привязкой под процессор и т.д. Возможно какие-то флаги из 4.5 ветки позволили бы увеличить скорость.
Поскольку FineReader Engine скорее всего будет собран для домашнего использования, включение подобных флагов допустимо.
+3
1. В 4.2.1 напоролись на баг в компиляторе, так что теперь используем только хорошо протестированные и пропатченные версии компилятора.
2. См. первую таблицу. FR Engine — это серверный продукт. Затачиваться под конкретный процессор имеет смысл только под конкретного заказчика с большим кошельком, т.к. требует дополнительный билд и дополнительное тестирование.
2. См. первую таблицу. FR Engine — это серверный продукт. Затачиваться под конкретный процессор имеет смысл только под конкретного заказчика с большим кошельком, т.к. требует дополнительный билд и дополнительное тестирование.
+1
В gcc-4.5 появилась link time optimization, включается флагом -flto.
+3
А почему недопустима сборка под конкретный процессор? ну или семейство?
+1
Плохо совместимо с таблицей системных требований. Имеет смысл затачиваться на самый массовый процессор (флаг -mtune), но использовать набор инструкций, доступный практически всем современным процессорам.
0
Было бы интересно еще и LLVM посмотреть, если это возможно.
0
ICC известны тем, что плюёт на стандарты IEEE о числах с плавающей точкой (п. 4.3.2). Поэтому следует сравнивать скорость компиляции с флагами gcc -mrecip и -ffast-math (конкретно — -funsafe-math-optimizations). Также gcc не делает -funroll-loops даже на уровне O3.
Если вам так нравится межпроцедурная оптимизация, советую попробовать скомпилировать в gcc 4.5 с флагом -flto. На практике может уменьшить размер исполняемого файла в разы (да-да), но мне не удалось ни разу заметить ускорение выполнения, отличное от погрешности измерения.
Если надо скомпилировать под текущий процессор, используйте флаг -march=native (компилятору виднее, какой набор инструкций у процессора).
Если вам так нравится межпроцедурная оптимизация, советую попробовать скомпилировать в gcc 4.5 с флагом -flto. На практике может уменьшить размер исполняемого файла в разы (да-да), но мне не удалось ни разу заметить ускорение выполнения, отличное от погрешности измерения.
Если надо скомпилировать под текущий процессор, используйте флаг -march=native (компилятору виднее, какой набор инструкций у процессора).
+6
Любопытно было бы узнать, какой версией ICC вы пользовались?
0
11.1
0
Спасибо. И за пост — отдельное спасибо, впечатляющее исследование.
0
Вообще, лучше чем O2 или O3 для gcc — итеративная компиляция. Дело в том, что в компиляторе несколько сотен оптимизаций, агрессивных и не очень. Очень важен порядок, в котором они применяются, ну и, конечно, применяются ли вообще (например, если бы в gcc была неудачная оптимизация циклов наподобие icc, то ее просто следует отключить). Ручками находить такую оптимальную последовательность — адский труд. Применяя эвристики вроде генетического алгоритма в acovea, можно достигнуть значительного прироста производительности программ, найдя нечто похожее на оптимум. Подробнее см. www.coyotegulch.com/products/acovea
+5
Интересно, спасибо! Можно попробовать поставить такую штуку работать на неделю, вдруг найдёт оптимум.
+1
Интересная идея.
Насколько я понял, для поиска применяется генерический алгоритм, где роль особи выполняет, судя по всему, билд с конкретными опциями. Набор опций — это набор хромосом, который и подвергается скрещиванию/мутации. Функция приспособленности, очевидно, — время работы билда на каком-то(каком?) наборе тестов. Таким образом, всего полных компиляций и запусков происходит N * M, где N — количество особей в поколении, M — количество поколений(пусть 30). Особей в поколении, я полагаю, несколько десятков? Я правильно все понял?
Если да, то, боюсь, к FREngine'у это применить будет достаточно тяжело, потому что время полной сборки составляет около двух часов, а если их количество измеряется сотнями…
В любом случае, интересная идея, спасибо.
Насколько я понял, для поиска применяется генерический алгоритм, где роль особи выполняет, судя по всему, билд с конкретными опциями. Набор опций — это набор хромосом, который и подвергается скрещиванию/мутации. Функция приспособленности, очевидно, — время работы билда на каком-то(каком?) наборе тестов. Таким образом, всего полных компиляций и запусков происходит N * M, где N — количество особей в поколении, M — количество поколений(пусть 30). Особей в поколении, я полагаю, несколько десятков? Я правильно все понял?
Если да, то, боюсь, к FREngine'у это применить будет достаточно тяжело, потому что время полной сборки составляет около двух часов, а если их количество измеряется сотнями…
В любом случае, интересная идея, спасибо.
0
Дык, а зря Вы открещиваетесь от возможности сборки версии под конкретный процессор. Вот например, если я сканирую в промышленных масштабах, то рад 5% производительности мне будет не влом скачать и поставить версию именно под мой процессор.
0
Очень интересные результаты. Надо отметить, что вы отлично поработали. Я обязательно покажу ваши результаты дизайнерам компилятора. Было бы интересно посмотреть на результаты последнего Intel® Parallel C++ Composer XE (т.е. Intel® С++ Compiler Professional edition). Предлагаю пообщаться для этого уже в кулуарах, а по завершению совместной работы опубликовать результаты.
0
Sign up to leave a comment.
Gcc vs Intel C++ Compiler: собираем FineReader Engine for Linux