Есть ли смысл использовать компилятор Intel C++ Compiler, если программа будет исполняться на процессоре AMD? И не станет ли от этого программа медленнее работать?
Я понимаю, что ответ может быть неоднозначным, что зависит от программы... Поэтому прошу поделиться личным опытом тех, кто сам сталкивался с такой связкой (Intel C++ Compiler + AMD processor)

В общем понятно, Intel C++ Compiler наверно почти никто никогда не использовал.

Почему же, используют, но только тогда, когда знают, чего хотят и что получится   Так как для того, что бы его использовать надо УЖЕ иметь MS компилятор (на Windows) и дополнительно сделать массу телодвижений. Если у тебя программа не требует топовой производительности, то этим никто заниматься не станет.
По поводу AMD - привар даст, не такой большой, как для Intel'овского проца, но будет лучше, чем родной MS компилятор. Кстати, можно залезть на www.spec.org и посмотреть цифры производительности для AMD/Intel на Intel'овском компиляторе (для MS компилятора там цифр нет по причине одинаково плохой производительности относительно Intel компилятроа как для Intel CPU, так и для AMD)

Нет никакой разницы какой процессор, если он совместим с x86 архитектурой. У процессоров Intel и AMD абсолютно одинаковые команды, только их реализация и выполнение внутри процессора осуществлены по-разному.

начнем с того что 86 архитектура доживает свой век, а это

абсолютно неверное утверждение, начиная с Phenom vs Quad команды одинаковыми не являются

Серьезно?   
Может ты хотел сказать, что каждый из этих процессоров имеет свой собственной набор уникальных дополнительных инструкций.

Именно так и правильнее бы высказаться.



Смотря что понимать под архитектурой. Например, примером разных вариантов архитектур может быть разбиение процессоров на RISC и CISC архитектуры. Со времён  процессора 8086 сохраняется совместимая с ним архитектура и никаких потенциальных замен ей даже не предполагается (никто не станет выбрасывать миллионы созданных прог и купленных компов).

KaraKum, я думаю, речь шла о x86_32, которая действительно доживает свой век. На смену ей идет x86_64.

именно

именно 

Вы в другую сторону разговор увели - здорово, но не по теме. Изначально был вопрос про разницу между AMD и Intel, а не про разрядность. В первом случае со стороны программирования её вообще не видно и не нужно её учитывать, а во втором случае она конечно же есть.

Arm(el)?

?

Архитектур существует явно больше, чем две (x86 и x86_64), в частности arm(el), sparc, powerpc.

xvr, скажи про это чуть подробнее. Нужно настраивать MS VS для использования Intel C++ Compiler вместо своего родного компилятора? Других вариантов нет?



Тут я думаю шла речь о том, что расширение SSE4 первыми предложили AMD, а не Intel как обычно. На сайте Intel есть презенташка с какой-то их конференции, там говорится об одном из их последних процессоров и в частности реализованном в нем расширении SSE4.2. Я так понимаю, то что в AMD называется SSE4.1, а то что в Intel - SSE4.2, вот в этом и различие
Но как уже правильно заметили, это не совсем в тему топика

Да

Есть, можно использовать его с Platform SDK. У Intel компилятора нет своего линкера и системных библиотек. Не говоря уже об отсуствии у него своего IDE


Вообще то они отличаются не только дополнительными инструкциями, даже разные Intel'овские процессоры отличаются друг от друга в планировании кода. Для получения максимальной производительности (для чего собственно и сделан Intel'овский компилятор) кодогенерация для разных процессоров отличается. Это не значит, что код сгенерированный для одного процессора не пойдет на другом, это значит, что его производительность будет меньше, чем если бы использовался код сгенерированный именно для этого процессора.

xvr, спасибо


Ну это-то понятно. Я только заметил про разницу в наборах команд.

так в этом и заключается низкоуровневая оптимизация: использовать свойства CPU в рамках конкретной архитектуры
в качестве примера возьмем C2D (IA-32e)

за каждый такт Instruction Fetcher из кэша L1 для кода передает предекодеру 16 байт
предекодер определяет границы закодированных инструкций (или инструкции) в рамках данного блока
причем для C2D есть следующий инварианты: 
 - количество инструкций в блоке не может быть > 6
 - если количество инструкций = x > 6, то за следующий такт могут быть предекодированы x - 6 <= 6 инструкций
 - если инструкция лежит на 16-ти байтной границе, то ее предекодирование откладывается до загрузки следующего 16-ти байтного блока

предекодированные блоки помещаются в очередь декодера (есть суть кэш L0) размером 64 байта (отсюда можно сделать вывод, что если цикл можно разбить на 1, 2, 3, 4 части с учетом вышеназванных инвариантов и при этом общий его размер не будет превышать 64 байта, то он будет постоянно находится в L0, что в 2 раза увеличивает производительность (засчет того, что декодер за раз извлекает из L0 не 16, а 32 байта))

декодер состоит и 4 частей: 1-ая декодирует инструкции, состоящими из <= 4uops; 2,3,4-ая - из <= 1 uops
отсюда вывод, если на вход декодеру подаются инструкции в последовательности 1 uops <- 4 uops <-1 uops <- 1 uops
то вместо 7-ми декодированных uops за такт, мы получим только 3, т. е снижение производительности в 2.3 раза

возьмем теперь концепцию micro-op fusion (объединение пары микроопераций в micro-op fusion-микрооперацию и интерпретация ее всеми частями конвеера (за исключением execution unit-ов) как одной микрооперации)
т. к большинство компонентов конвеера могут за такт обработать фиксированное количество микроопераций, слияние 2-ух микроопераций в одну повышает общую производительность

таким образом, только лишь изменяя порядок инструкций, мы можем получить повышение пропускной способности конвеера, а значит и общей производительности CPU
причем все, что написано выше специфично для С2D, хотя архитектура команд (за исключением некоторых расширений) идентична, скажем K10 от AMD

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

Мне вот ещё интересно. Этот компилятор перед компиляцией определяет на каком он проце работает и оптимизирует под него? Если да, то значит он каждому AMD-шному процу сопоставляет какой-то свой? А если не так, то наверно флагами компилятору указывается, под что оптимизировать, а значит вообще без разницы на каком процессоре это делать, т.к. можно сделать кучу сборок и проверить какя быстрее (или вообще может можно отключить оптимизацию?).

Нет. 
Да. Есть куча флагов для управления (linux версия, beta):


Можно

динамическое определение типа CPU (__intel_new_proc_init(), __intel_proc_init(), __intel_cpu_indicator(), ...)
+ возможность жесткой привязки через флаги на этапе компиляции

Интеграция последнего компилятора от Intel в студию >= 8.0 полностью автоматизирована. Я без проблем установил и чтобы переключаться между двумя компиляторами использую просто одну кнопочку(ну, грубо говоря). 

Что касается в общем уровня генерируемого кода в сравнении с компилятором от MS, то никаких гениальных и качественно новых идей в машинном коде, который генерируется компилятором от Intel, я не нашёл. Всё что я говорю связано, конечно, с тем спектром задач, которые решаю я. А пару месяцев назад я столкнулся с проблемой обоснования выбора языка и компилятора для реализации одной задачи. Я взял алгоритм, который в задаче используется достаточно часто. Алгоритмы называется SVD - singular value decomposition или сингулярное разложение матриц. Это достаточно ресурсоёмъкий и сложный алгоритм. 

Я брал матрицу 1681х1681 и применял к ней SVD. SVD алгоритм был реализован на 2х языках, в том числе на С++ он компилировался с использованием родного компилятора от MS из 2005 студии, и с использованием 10ой версии компилятора от Intel. На С++ он компилировался в одном случае с использованием SSE2 команд, а в другом без. 

Далее, все полученые модификации, были протестированы на 7ми разных процессорах. Вот сводная таблица(значения - время работы алгоритма в секундах):



Я занимался профилированием алгоритма, основная часть(~80%) времени уходит на обращение к памяти и здесь C2D может быть быстрее только из-за того, что у него достаточно большой объём кеша по сравнению с AMD. В общем-то даже на самих процессорах от Intel их компилятор даёт весьма неоднозначный результат для процессоров разных семейств и поколений. 

Что касается машинного кода. Машинный код, полученный двумя этими компиляторами фактически оказался идентичным, т.е. в рамках этой задачи я не увидел, чтобы Intel C++ Compiler 10.0 проводил какую-то тонкую оптимизацию. Возможно из-за того, что я не указывал точно семейство процессоров для которых компилирую(т.к. алгоритм используется на разных процессорах в этом просто нет смысла). 

Я с VC не сравнивал, но вот разница между gcc4.1 и icc10.0 огромная.
Например у меня при оптимизации -О3 (без указания типа процессора, т.е. программа может работать как на intel так и на amd) программа от gcc весит 450кб, а от iсс 240кб (причём даже меньше чем при -О2  ), ну и соответственно выполняется процентов на 30 быстрее.
ИМХО тут важна не оптимизация под процессор, а оптимизация собственно кода.

Это сообщение отредактировал(а) georain - 29.5.2008, 02:03

В общем случае, размер программы никак не влияет на скорость исполнения.

Я не говорил что размер влияет на скорость, я лишь привёл результаты на основе моего проекта. Не обращая внимания на размер, интегральный прирос в 30% это результат хороший.
Кроме того icc производит более глубокую диагностику и намного лучше придерживается стандарта, мне даже приходится не использовать некоторые возможности для совместимости с gcc.
В общем моё мнение такое, если позволяют возможности обязательно используйте icc.

Так сложилось, что я в MS VS практически не работал. Использую BCB6. У меня в нем установлено расширение С++ Compiler Enchancements 2.75. Служит оно в основном для увеличения скорости компиляции. Но я нашёл в нём настройки bcc32.exe replacement (C++ Compiler) и ilink32.exe replacement (Linker). Т.е. стандартные компилятор и линковщик можно заменить. 
Так может возможно использовать ICC не только с MS VS, но и Билдером? Как думаете, стоит попытаться их подружить или уже проверено, что не будут вместе работать?

C VCL на 99% работать не будет - там используются нестандартные расширения языка, icc их не понимает

Какие архитектуры поддерживает этот компилятор? насколько эффективный код он генерирует для процессоров AMD? Какая лицензия и цена у этого компилятора?

Добавлено через 52 секунды

Давай конкретику. gcc бери версии 4.3.

Не совсем ясно, что за диагностику вообще компилятор призван проводить? И прямо-таки намного лучше по части стандарта? Последний компилятор от студии кстати, версия 9.0, очень даже неплох. У самого пока нет возможности перейти, но со слов очень грамотных коллег, занимающихся разработкой драйверов(т.е. люди много времени проводят за асм-листингами) компилятор неплохо эволюционировал.

У меня работает на amd и intel 32-х и 64-х разрядных версиях. ОС: windows, linux, mac os x.
На данный момент для 64-х разрядных систем эффективность кода для intel и amd почти одинакова, наверное ввиду близкого набора команд. Как дальше будет не знаю. Для 32-х не проверял к сожалению.
Для некоммерческого использования под linux он бесплатный. Для остальных систем есть 30 дней тестового периода. А цена около 500. 
А вообще лучше смотреть на www.intel.com ;)


Не могу брать, 4.2.3 под 64 не протестин, а 4.3 вообще пока считается нестабильным. Мне кажется нужно говорить о том что есть.
Вот недавно столкнулся, в gcc не могу внутри класса определить явную специализацию для шаблонной функции.

господа
причем здесь вообще набор команд?   

Кем? Да и странно, а чем я программы собираю уже который месяц...


Кем считается?

Добавлено @ 02:29

Как насчёт sparc, arm?

Добавлено @ 02:30

А gcc/g++ - свободный.

Это сообщение отредактировал(а) JackYF - 30.5.2008, 02:32

JackYF, блин задрали вы уже приводить примеры платформ на которых ничего кроме вашего любомого гцц, не пашет, это что показатель?
а вот знаешь такую ОС SOS, так вот там гцц пахать не будет.
Сорри, просто накипело уже, подобный бред читать.

Господа, остыньте! Забыл в начале топика сказать. Интересно под Винду, и только...

один из

Добавлено через 11 минут и 31 секунду

однако для создания модулей и компиляции ядра используется GCC   

Заглянул на www.spec.org (чего и всем рекомендую), для AMD'ных процов в основном используются QLogic PathScale и gcc

Где бред? Я что-то неправильно сказал?

Временем. Я пользуюсь некоторыми не протестированными программами, чтобы сказать другим стабильны они или нет. Но вот только компилирую их протестированным gcc. А если и то и другое "работает не на 100%", то бывает непонятно что из них работает не правильно.


+1   

Это сообщение отредактировал(а) georain - 30.5.2008, 17:52

ты все правильно сказал, сорри за слово "бред", не сдержался

ksili, я использую icc для Visual Studio на AMD Athlon. Разница по сравнению с M$ бывает, что видна. Оптимизацию в этом случае нужно настраивать на SSE3. Посмотрите компиляторы pgroup (Portland Group) - они вроде бы считаются лучше для AMD.

К диагностическим сообщениям относятся предупреждения и сообщения об ошибках.


Стандарт не разрешает это. Но нарушения стандарта, касающиеся шаблонов, у GCC всё же имеются.

Это сообщение отредактировал(а) UnrealMan - 8.7.2008, 16:45

up!

Недавно читал статью Агнера Фога, где он пишет, что Intel Compiler генерирует код, который применяет инструкции SSE только для процессоров Intel, а не для любых процессоров которые поддерживают SSE.
http://agner.org/optimize/blog/read.php?i=49

GoldFinch, собственно, ничего удивительного 

JackYF, вобщем-то да, но это как-то сразу убирает всю ценность Intel Compiler для софта ориентированного на широкую аудиторию пользователей.

:yes

честно говоря, не знаю, в тему или нет, но юзаю библиотеку IPP ( Intel Performance Primitives ). Вызываю функцию FFTGetSize_C (получить размер буфера для FFT). На Intel-процессоре возвращает правильное  значение, на AMD - возвращает какую-то чушь, после чего падает функция FFTFwd_CToC, отлично работающая на Intel. Впечатление, что специально. Если размер буфера задать руками, то всё отрабатывает как надо