Кто-нибудь здесь тестировал компилятор Intel C ++ и GCC? - PullRequest
Новая
       25

Кто-нибудь здесь тестировал компилятор Intel C ++ и GCC?

26 голосов
/ 14 ноября 2009

Я не уверен, стоит ли мне публиковать этот вопрос здесь, потому что это веб-сайт, ориентированный на программирование.

В любом случае, я думаю, что здесь должен быть какой-то гуру, который знает это.

Теперь у меня есть сервер AMD Opteron, работающий под CentOS 5. Я хочу иметь компилятор для довольно большой программы на основе c ++ Boost. Какой компилятор мне выбрать?

Ответы [ 9 ]

25 голосов
/ 14 ноября 2009

Здесь есть интересный PDF здесь , который сравнивает количество компиляторов.

19 голосов
/ 02 декабря 2009

Надеюсь, это поможет больше, чем ранит:)

Я снимал компилятор чуть больше года назад, и у меня не хватает памяти.

  1. GCC 4.2 (Apple)
  2. Intel 10
  3. GCC 4.2 (Apple) + LLVM

Я протестировал несколько шаблонных программ для обработки тяжелых звуковых сигналов, которые я написал.

Время компиляции: компилятор Intel был безусловно самым медленным компилятором - более чем в 2 раза медленнее, как цитировалось в другой публикации.

GCC очень хорошо обрабатывает глубокие шаблоны по сравнению с Intel.

Компилятор Intel сгенерировал огромных объектных файлов.

GCC + LLVM дал наименьший двоичный файл.

Сгенерированный код может иметь значительные различия из-за конструкции программы и места, где может использоваться SIMD.

Что касается того, как я пишу, я обнаружил, что GCC + LLVM генерирует лучший код. Для программ, которые я написал до того, как серьезно относился к оптимизации (как я писал), Intel в целом был лучше.

Результаты Intel варьировались; некоторые программы работали намного лучше, а некоторые - намного хуже. Он очень хорошо справлялся с необработанной обработкой, но я даю торт GCC + LLVM, потому что когда он помещается в контекст более крупной (нормальной) программы ... он работает лучше.

Intel выиграла «из коробки», число хрустило на огромных наборах данных.

Один GCC генерировал самый медленный код, хотя он может быть таким же быстрым с измерениями и нано-оптимизацией. Я предпочитаю избегать этого, потому что ветер может изменить направление, так сказать, со следующим выпуском компилятора.

Я никогда не измерял плохо написанные программы в этом тесте (т. Е. Результаты превосходили дистрибутивы популярных библиотек производительности).

Наконец, программы были написаны в течение нескольких лет с использованием GCC в качестве основного компилятора того времени.

Обновление: я также включил оптимизации / расширения для Core2Duo. Программы были достаточно чистыми, чтобы включить строгие псевдонимы.

15 голосов
/ 14 ноября 2009

Однажды команда MySQL сообщила, что icc дает им повышение производительности примерно на 10% по сравнению с gcc. Я постараюсь найти ссылку.

В общем, я обнаружил, что «родные» компиляторы работают лучше, чем gcc на соответствующих платформах

редактировать: я был немного не в себе. Типичный прирост составлял 20-30%, а не 10%. Некоторые узкие грани получили удвоение производительности. http://www.mysqlperformanceblog.com/files/presentations/LinuxWorld2004-Intel.pdf

6 голосов
/ 20 ноября 2009

Полагаю, это зависит от кода, но с базой кода, над которой я сейчас работаю, ICC 11.035 дает почти 2-кратное улучшение по сравнению с gcc 4.4.0 на Xeon 5504.

ICC опции: -O2 -fno-alias
параметры gcc: -O3 -msse3 -mfpmath=sse -fargument-noalias-global

Эти параметры относятся только к файлу, содержащему интенсивный код, где я знаю, что нет псевдонимов. Однопоточный код с 5-уровневым вложенным циклом.

Хотя автовекторизация включена, ни один из компиляторов не генерирует векторизованный код (это не ошибка компиляторов)

Обновление (2015/02/27): Оптимизировав некоторый геофизический код (Q2, 2013) для запуска на Sandy Bridge-E Xeons, я имел возможность сравнить производительность ICC 11.1 с GCC 4.8.0, и теперь GCC генерировал более быстрый код, чем ICC. В коде использовались встроенные функции AVX и использовались 8-сторонние векторизованные инструкции (ни один из компиляторов не выполнил автоматическую векторизацию кода из-за определенных требований к разметке данных). Кроме того, реализация LTO в GCC (с ядром IR, встроенным в файлы .o) была намного проще в управлении, чем в ICC. GCC с LTO работал примерно в 3 раза быстрее, чем ICC без LTO. Я не могу найти номера для GCC без LTO, но я помню, что это было все еще быстрее, чем ICC. Это ни в коем случае не общее утверждение о работе ICC, но результатов было достаточно для того, чтобы мы могли продолжить работу с GCC 4.8. *.

С нетерпением ждем GCC 5.0 (http://www.phoronix.com/scan.php?page=article&item=gcc-50-broadwell)!

)
5 голосов
/ 14 ноября 2009

Мы используем компилятор Intel в нашем продукте (DB2), в Linux и Windows IA32 / AMD64, а также в OS X (то есть во всех наших портах платформы Intel, кроме SunAMD).

Я не знаю цифр, но производительность достаточно хорошая, чтобы мы:

  • плата за компилятор, который мне говорят, очень дорогой.
  • живет в 2 раза медленнее времени сборки (в основном из-за времени, которое он тратит на приобретение лицензий, прежде чем он сам себя запустит).
3 голосов
/ 05 февраля 2012

PHP - Компиляция из исходного кода с использованием ICC, а не GCC, должна привести к увеличению скорости на 10-20% - http://www.papelipe.no/tags/ez_publish/benchmark_of_intel_compiled_icc_apache_php_and_apc

MySQL - Компиляция из исходного кода с использованием ICC, а не GCC, должна привести к увеличению скорости на 25-50% - http://www.mysqlperformanceblog.com/files/presentations/LinuxWorld2005-Intel.pdf

1 голос
/ 15 апреля 2013

Я использовал UnixBench (v. 5.1.3) в openSUSE 12.2 (ядро 3.4.33-2.24-default x86_64) и скомпилировал его сначала с GCC, а затем с компилятором Intel. *

С 1 параллельной копией UnixBench, скомпилированный с Intel, примерно на 20% быстрее, чем версия, скомпилированная с GCC. Однако это скрывает огромные различия. Dhrystone с компилятором Intel работает примерно на 25% медленнее, а Whetstone работает в 2 раза быстрее.

При параллельном запуске 4-х копий UnixBench улучшение компилятора Intel по сравнению с GCC составляет всего 7%. Опять же, Intel намного лучше в Уитстоне (> 200%) и медленнее в Dhrystone (около 20%).

1 голос
/ 14 ноября 2009

Раньше я работал на довольно большой системе обработки сигналов, которая работала на большом кластере. Мы привыкли считать, что математические вычисления очень сложны, компилятор Intel дал нам примерно на 10% меньше нагрузки на процессор, чем GCC. Это очень ненаучно, но это был наш опыт (это было около 18 месяцев назад).

Что было бы интересно, если бы мы могли использовать математические библиотеки Intel, которые используют их чипсет более эффективно.

0 голосов
/ 25 мая 2015

Для многих оптимизаций, которые регулярно выполняет компилятор Intel, требуется определенный синтаксис исходного кода и использование -O3 -ffast-math для gcc. К сожалению, компонент -funsafe-math-optimizations -ffast-math -O3 -march = native оказался несовместимым с -fopenmp, поэтому я должен разбить мои исходные файлы на группы, названные с различными параметрами в Makefile. Сегодня я столкнулся с ошибкой, когда сборка g ++ с использованием -O3 -ffast-math -fopenmp -march = native смогла записать на экран, но не перенаправить в файл. Одним из наиболее вопиющих отличий, на мой взгляд, является оптимизация с помощью icpc только std :: max и min, где gcc / g ++ хочет, чтобы fmax | min [f] с -ffast-math изменило их значение по сравнению со стандартным.

...