Как пишет Intel, они на 30% обгоняют GCC. Интересно гонят или нет... Проверилбы кто.

ICC обычно чуть более эффективный код делает, но 30% редко, хотя на специальных тестах можно и 100% получить.

Таки да. Все мои знакомые тоже так говорят. собирает icc дольше, но и работает потом быстрее :)

ixbt жолтая преса

Я конечно понимаю, сравнение интерестное, но какая это новость годичной давности, архив какой-то...

ixbt себя дискредитировал. В морг..

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

> Наверное по хорошему им бы либы и кернел скомпилить, но что то мне подсазывает, что это довольно затруднительно...

А таки да. А есть ли у когото из присутствующих опыт сборки ядра линухового или ядра/мира фревого этим компилятором?

PS Токо не надо говорить что это изврат, сам знаю :)

Мож и изврат, но я пытался... Безнадежно. Как позже выяснилось, ядро заточено намертво под gcc

icc это плюсовый компилер. а большая часть всего линухового на plain c написано. так что сравнивать особо нечего.

Кто-нибудь на icc прогоните тест, пожалуйста:

#include <stdio.h>

int main() {
   unsigned char n=255;
   printf("Result is %d\n",n*256);
}

Что оно при этом выдает?

щас вылезет придурок niks с извечной историей как он разыменовывал висячий указатель

~> cat > test2.c
#include <stdio.h>

int main() {
unsigned char n=255;
printf("Result is %d\n",n*256);
}
~> icc test2.c
test2.c
~> ./a.out
Result is 65280
~>

А разве могло быть не 65280? (char)*(int)=(int)*(int)=(int).

Да чего-то были у меня смутные подозрения, навеянные беседой с одним красноглазым :-) Рад, что ошибся

Я компилировал mysql с помощью gcc и с помощью icc и потом сравнивал производительность на mysql benchmarks. Да, icc быстрее. но уж конечно не на 30% К примеру test-select отработался для gcc за 116 сек, для icc за 92 сек. test-insert 1273/1148 секунд (gcc/icc).

>>ixbt себя дискредитировал. В морг..
Абсолютно согласен ! Древняя статья про древний компилятор на дерьмовом сайте - в морг.

сильная сторона интелоидных компиляторов это хорошая оптимизация циклов, в которых немного ветвлений (например копирование одного массива в другой), на таких циклах icc додумывается разворачивать код в более линейный вариант (например развернуть цикл в 4 раза, на маленьких циклах это дает весьма неплохой прирост производительности)... слабое место icc (во всяком случае версии годичной давности) - это сильно развилистый код, в котором много возможных веток исполнения, на таком коде icc показывает себя не очень хорошо...

У меня после недавних публикаций на IXBT доверие к этой конторе пропало полностью.

>извечной историей как он разыменовывал висячий указатель

Не вылезет.:) На чем он свой mono собирает? :)

gcc 3.2x/3.3 вполне корректно отрабатывает "висяки", в отличие от 2.9x. Кроме того, gcc 3.2x/3.3 ближе к ANSI/ISO стандарту чем icc/icl. Так что приходится выбирать gcc 3.3 однозначно. (хотя рсчётчик Лацис в своей книге рекомендует Intel)

:)))

Ну то что статья старая - это ладно 

А вот то что автор:
1) Не знает что icc6 описываемый в статье чуть медленней чем icc5
   (я 7 не пробовал но правдв и на момент написания его небыло)
2) Плохо знаком с ключами gcc

3) Выбрал непонятную "синтетику" для тестов

4) Не знает что pgcc и icc нужно обязательно сравнивать с опцией -openmp   на соответствующем наборе тестов и на соответствующих железяках

Это медицинский факт.


Кстати icc уже перестал падать в корку вот на таком вот коде ? ;)

#include <iostream>
int main(int argc, char* argv[])
{
 exit(-1);
}

gcc наиболее близок к стандарту, а после недавней встречи разработчиков gcc ждем нового обещанного оптимизатора. Всех порвем ! :)

Хех - а порвалка не сломается ? 8)

Реально только gcc 3.2.3 способен более-менее успешно жевать опции чуть посложее чем -O3 -fomit-frame-pointer. 3.3 в этом плане - абсолютный урод. 3.3.1(CVS) от 3.3 практически ничем не отличается. 3.4(CVS) почти собрал себя с вышеупомянутыми опциями 8) - что вселяет определенные надежды...

При попытке собрать ядро с icc узнал, что у меня слишком старый gcc :]

>>Хех - а порвалка не сломается ? 8) Нет не сломаеться, ведь gcc не какое-то закрытое говно, а открытая программа - она создана побеждать !

Несомненно. То, что gcc догонит и перегонит по оптимизации intel -- вопрос только времени

Интел-компилер платный/закрытый и с АМДехами не работает.
Так что правда - в морг !

> То, что gcc догонит и перегонит по оптимизации intel -- вопрос только времени

Не факт. Что если icc использует неопубликованные особенности родного железа.

> Интел-компилер платный/закрытый и с АМДехами не работает. Так что правда - в морг !

Ну в морг не в морг, но мои друзья говорили что проги откомпиленые icc с оптимизацией (и с использованием intel-овских мат-библиотек) на athlon-ах получают достаточный прирост производительности и рвут всех как тузик грелку :)

>>Что если icc использует неопубликованные особенности родного железа. Сам-то понял что сказал ? Это тебе не масдай API...

>>Что если icc использует неопубликованные особенности родного железа.

>Сам-то понял что сказал ? Это тебе не масдай API...

Уууу, а вы мол чел видно в процах не сильно разбираетесь (где-то на уровне чайника :)

А теперь бегов на developer.intel.com и читать IA-32 Optimization manual (вроде так называется, лень смотреть/искать). А потом долго думаем над первой фразой :)

>>А потом долго думаем над первой фразой :) А тут и думать нечего для контор подобных интелу, закрытость - смерть. Так что делать какие-то недокументированные фичи им делать нет ну никакого резона :)

Да вот действительно, не пнём единым.
Посмотреть бы как на разных камнях какие
компилеры рулят.

t1

Честно говоря не спец по процессорам, но из общих соображений стандартным является только конкретный набор инструкций и регистров, а то как именно это воплощено в железе - дело хозяйское (Трансмента например вообще эмулирует какой угодно набор), а потому наверняка могут быть особенности..

Там разброс по скорости может быть до 30%. А 'недокументированные' фичи - это особенность внутреннего строения кристалла. Несколько модулей, которые могут параллельно обрабатывать комманды и как вы им их скормите - от этого зависит и скорость выполнения программ. Стандартного то наверное и нету. Есть описание на языке высокого уровня а в машинный код оно достаточно по разному может быть транслировано. И соотв с выгодой для определенной архитектуры и соотв не слишком удобной для остальных. Простой пример обнуления регистра: mov ax,0h или xor ax,ax .Результат тот же, но во втором случае будет затрачено меньше процессорного времени. В ядре же есть опция оптимизации под разные процессоры. По памяти: -mcpu={pentium,pentiumpro,cyrix...} -march={pentium,pentiumpro,cyrix...}

По памяти: -mcpu={pentium,pentiumpro,cyrix...} -это и есть оптимизация, а -march={pentium,pentiumpro,cyrix...} -это уже заточка под конкретный камень, т.е. под другим работать не будет.

Куда подевался Антихрист-Луговский?

Он все пел песни про якобы плохую оптимизацию gcc. Тест господина Степанова Маухуур, конечно, не гонял. :-Q

Маухуур против C++, поэтому естественно тест Степанова не гонял.

Я принимал участие в обсуждении подготовки данного тестирования на iXBT, так что...

>автор:
>1) Не знает что icc6 описываемый в статье чуть медленней чем icc5
А Вы прочли к чему эта статья является дополнением? например,
http://www.ixbt.com/cpu/insidespeccpu2000-compilers.shtml
http://www.ixbt.com/cpu/insidespeccpu2000-compilers-add1.shtml

>2) Плохо знаком с ключами gcc
Это так. Однако, учитывая специфику SPECcpuBASE, это не страшно.
Это проявилось бы в SPECcpuPeak, однако до этого iXBT пока не дошел.

>3) Выбрал непонятную "синтетику" для тестов
Прежде чем называть это "непонятной синтетикой", сходите на www.spec.org

>4) Не знает что pgcc и icc нужно обязательно сравнивать с опцией -openmp на соответствующем наборе тестов и на соответствующих железяках
О чем Вы?

[b]All[/b]
Если Вы заметили, Это только одна статья из постоянного цикла тестирования систем SPEC тестом. В частности, сейчас идет тестирование Opteron-ов. И именно gcc 3.3 компайлером.
Так что все, кто желает, чтобы тесты были проведены более качественно, милости просим в конференцию ixbt, например, в ветку
http://forum.ixbt.com/0006/002806.html
Это последняя из веток, где обсуждаются эта серия тестов. gcc и его опции обсуждались в более ранних, например,
http://forum.ixbt.com/0006/001889.html

ALSA 0.9.6 released

2VLev
>автор:
>1) Не знает что icc6 описываемый в статье чуть медленней чем icc5
>А Вы прочли к чему эта статья является дополнением? например,

Изначально ссылок на дополнения я не увидел - посмотрю, спасибо

>http://www.ixbt.com/cpu/insidespeccpu2000-compilers.shtml
>http://www.ixbt.com/cpu/insidespeccpu2000-compilers-add1.shtml>2) Плохо 

>знаком с ключами gcc
>Это так. Однако, учитывая специфику SPECcpuBASE, это не страшно.

то что тест для 2.953 собирался для i386 ? ;)

>Это проявилось бы в SPECcpuPeak, однако до этого iXBT пока не дошел.>3) 

>Выбрал непонятную "синтетику" для тестов
>Прежде чем называть это "непонятной синтетикой", сходите на >www.spec.org

А Вы сами внимательно там все посмотрели ? ;)
Это я о следующем вопросе :)

(сам по себе набор пузомерок там представленных тоже вобщем то
нехорош тем что производители компилеров могут подточит свои поделия под "типа стандарт тестов")

>4) Не знает что pgcc и icc нужно обязательно сравнивать с опцией -openmp на соответствующем наборе тестов и на соответствующих железяках
О чем Вы? 

Это я о том что Портланд по жизни это компилер для параллельных приложений и унипроцессорный код он генерирует преотвратительный всю жизнь (ну на самом деле автор как не видимо спец в PHPC мог этого и не знать но на будущее следует иметь это ввиду)

вот и нужно его было тестировать с icc для OpenMP (см. http://www.spec.org/omp/)

ALSA 0.9.6 released

>http://www.ixbt.com/cpu/insidespeccpu2000-compilers-add1.shtml

Вот Вы даже оказывается знаете об OpenMP (правда почему то Вы называете это технологией - если применять этот термин к программированию то возможно еще можно с некоторой натяжкой так сказать - только это все же
спецификация ;))

Правда она рассматривается в разрезе hyperthreading а не скажем
масштабируемости кода ....

>(Трансмента например вообще эмулирует какой угодно набор)
>NiKel (*) (2003-07-28 23:44:50.151466)
Далеко не какой угодно :) Чтобы не писали о двоичной компиляции, в круизёрах не всё так гладко :)

>то что тест для 2.953 собирался для i386 ? ;)
А что, это так? -O3 опция не включает в этом случае target платформу, которая была, видимо, i686?
Честно говоря, судя по результатам, это крайне сомнительно IMHO.
Но если Вы в этом уверены, то этот факт заслуживает очень большого внимания. Не могли бы Вы привести какие-нибудь ссылки на это?

>производители компилеров могут подточит свои поделия под "типа стандарт тестов"
И в следующем варианте набора тестов, который выходит раз в 5 лет, с треском проиграть? Это на самом деле давольно большой скандал.
Кстати говоря, в смысле последнего скандала отличилась SUN, компилятор которой в подтесте 179.art позволяет Sparc-ам не слишком позорно проигрывать всем своим конкурентам.

>вот и нужно его было тестировать с icc для OpenMP
Так смысл какой без аппаратной поддержки многопоточности?
Тем более SPECcpu --- не поддерживает OpenMP. Для этого есть другие тесты, в том числе и производные от SPECcpu, но не сам SPECcpu.

>Вот Вы даже оказывается знаете об OpenMP
Да, я знаю

>(правда почему то Вы называете это технологией - если применять этот термин к программированию то возможно еще можно с некоторой натяжкой так сказать - только это все же спецификация ;))
Я --- не автор этих статей, и с материалами, опубликованными на, iXBT почти никак не связан. Я лишь давал автору некоторые советы по настройке gcc под linux. Вероятно, не очень хорошие, но других специалистов там в данный момент не было.

>Правда она рассматривается в разрезе hyperthreading а не скажем
масштабируемости кода ....
Меня тоже интересуют тесты на масштабируемость вычислительных приложений. Однако сомневаюсь, что подобные тесты будут интересны настолько многим, что это подвигнет iXBT на проведение специального тестирования. Впрочем, они размещают и чужие статьи, вот недавно одна статья по этому поводу была.
http://www.ixbt.com/cpu/ls-dyna-cpu-test.shtml
Однако, если есть конструктивные предложения, их неплохо бы высказать.

А что, это так? -O3 опция не включает в этом случае target платформу, которая была, видимо, i686

Кому сиё видимо ? :)

вот кусок из info gcc 3.2.2 (ясен пень что 2.95.3 вряд ли более интелектуален)

the compiler will not
     generate any code that does not run on the i386 without the
     `-march=CPU-TYPE'

>>вот и нужно его было тестировать с icc для OpenMP 
>Так смысл какой без аппаратной поддержки многопоточности? 
>Тем более SPECcpu --- не поддерживает OpenMP. Для этого есть >другие тесты, в том числе и производные от SPECcpu, но не сам >SPECcpu. 

ну вопервых речь то шла об портланде а во вторых я ссылку дал
на соответствующий тест 

>Я --- не автор этих статей, и с материалами, опубликованными на, iXBT >почти никак не связан. Я лишь давал автору некоторые советы по >настройке gcc под linux. Вероятно, не очень хорошие, но других >специалистов там в данный момент не было.

Я из поста как раз подумал что Вы автор ... ну раз не автор, значит не автор ;) 


>http://www.ixbt.com/cpu/ls-dyna-cpu-test.shtml 
>Однако, если есть конструктивные предложения, их неплохо бы >высказать.

Будет время, будем посмотреть ;)

>Кому сиё видимо ? :)
Ok, согласен. Честно говоря, уже и не припомню что побудило автора использовать именно такой набор опций. Возможно, с другой target платформой результаты были хуже. Это же iP4, для которого gcc тогда вообще очень плохо код генерил. А может, и элементарная лень. По крайней мере я вроде советовал какие-то конкретные -march=... Можно поискать в конференции...
К сожалению, на данный момент gcc не конкурент icc по производительности под intel-овские же процессоры (да и вообще конкурентов нет). Под AMD, в принципе, чуть лучше (особенно x86_64), но icc тут тоже не плох.
В результате на iXBT для этого SPEC тестирования icc стал фактически стандартом де-факто, что лично меня не слишком радует.

>я ссылку дал на соответствующий тест
Ну, это тест совсем другого порядка и другой сложности, нежели specCPU.

>Будет время, будем посмотреть
Будем ждать...

>Ok, согласен. Честно говоря, уже и не припомню что побудило автора >использовать именно такой набор опций. Возможно, с другой target >платформой результаты были хуже. Это же iP4, для которого gcc тогда >вообще очень плохо код генерил. А может, и элементарная лень. По >крайней мере я вроде советовал какие-то конкретные -march=... Можно >поискать в конференции... 
>К сожалению, на данный момент gcc не конкурент icc по >производительности под intel-овские же процессоры (да и вообще >конкурентов нет). Под AMD, в принципе, чуть лучше (особенно x86_64), >но icc тут тоже не плох. 

Могу в 2-х словах рассказать почему icc на практике не так хорош как
в тестах (на примере решения CPU expensive задач с большим числом FP вычислений - как то CFD задачи)

- Реальный образ задачи (попросту говоря массива данных над которым производят вычисления) это как правло порядка 50-100Мб
минимум для самых простеньких случаев и поэтому на фактор скорости FP вычислений накладывается выктор эффективности управления доступом к памяти

- Реальные задачи имеют сильноветвящийся код с довольно большим числом целочисленных вычислений (на то они и реальный)

В результате у меня на реальных конкретных задачах 
к примеру на Athlon XP icc 5.01 проигрывал gcc 2.95.3 порядка 7-10%
при максимально полной оптимизации,  не факт кстати что
gcc 3.x был бы в данном случае лучше (к сожалению из за изменений, 
сделанных в стандарте С++ для 3 версии gcc  эту задачу туда напрямую перенести не получается)

Кроме того - если задача исполняется в гетерогенном кластере (то есть
узлы работают на разных типах или даже степпингах процессоров - например P III, P4, Athlon TB, Athlon XP, Athlon MP )
то при тонкой оптимизации задачи под процессор могут возникать
ситуации невозможности миграции процесса на узел в котором 
соответствующие дополнительные возможности процессора отсутствуют - то есть либо придется мирится с этим либо собирать задачу с заведомо меньшим набором поддерживаемых возможностей
(см. cpu.x86_capability)

А вот для Win  платформы в разрезе вышеперечисленных задач icc
действительно хорош...

Лучший компилятор эта visual studio

> Лучший компилятор эта visual studio

А лучшая рыба - это колбаса :)

ALSA 0.9.6 released

>Лучший компилятор эта visual studio
Жванецкий, однако ;)