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 не могу внутри класса определить явную специализацию для шаблонной функции.