Англоговорящему анонимусу: Я и говорю, что политика Intel по отношению к компиляторам более чем странная. Зачем выводить ICC на линукс, когда там уже есть kai, который стоит столько же, гораздо качественнее, и при этом принадлежит _им_же. Я не вижу в этом никакой логики кроме подковерных разборок в интеле. Может, они хотят затащить на линукс свой кодогенератор, который в отличие от kai умеет mmx/sse, может, хотят в будущем скрестить "оптимизатор" kai и свой кодогенератор, может, две разные команды соревнуются... Резюме -- "внешней" логике вывод этого компилятора не поддается -- смысла в нем очевидно нет.
Кстати, Antichrist, расскажи, как это компилятор _C++_ может заюзать SIMD? Правда, интересно. Как он срюхнет, когда нужны соответствующие инструкции? Автоматом проанализирует циклы по массиву и разложит его по регистрам? Он же не знает ничего ни про векторы, ни про матрицы? Или SIMD будет использоваться в его реализации stl?
Судя по всему - какой-то вумный анализ. Раскладывает dataflow в пределах функции, сортирует по независимым блокам, ищет похожие операции над разными данными - и сливает в одну SIMD. Я бы так сделал...
2ZhekaSmith: Ты туп, уж извини, но это факт.
"не умеющий читать по английски"
Почему-то для слащдота это нормально http://slashdot.org/developers/02/01/26/1328215.shtml А для тебя нет. И я даже знаю почему :) Потому что ты относишся к этому как к своей личной обиде, что доказывает твой уровень развития.
"не умеющий ... писать по русски"
Уж кто-бы говорил... По-русски, по-английски пишется именно так, марш в школу, в пятый класс, до учиватся.
"Кстати, в VC есть куски кода интеловского компилятора"
И? А gcc инженеры от интеля тоже затачивали, чтоб он уж совсем отстойным не был...
Ой, со зла це, ой со зла...
Собственно, под x86-то как раз и промашка у них есть -- нет win32 версии. Потому и связались с Интелом.
Вчепятление: KAI правильнее во всех отношениях, но Intel -- очень-очень хорош. Хотя иногда-таки дерьмо лепит (типа Internal Compiler Error), но довольно редко и есть надежда на улучшение.
А где чайнику найти хорошие доки (желательно хотя бы часть на русском) про компиляцию программ под Линукс. Для меня опции gcc - это темный лес. О2 или О10 не о чем не говорят.
Вот и я говорю, нет кэя под МИПС-ы 32-р... ИСА-2... :( сиротааааа яяя... так и придётся гнуться (и они тоже положили :)), да на ассемблёре ручками разгребать... (мать... мать... мать... привычно отозвалось эхо:))
2Старый пионэр:
>> та же хрень. Вот так строка для gcc выглядит в последней инкарнации:
>> -O20 -mpentiumpro -funroll-loops -fomit-frame-pointer -ffast-math -malign-jumps=2 -malign-loops=2
Неправильно это, тут уже написали, к тому же другие -malign могут все тормознуть (сам не раз убеждался в этом), и так, попробуй (если не влом) следующую строку и только ее:
-O20 -march=pentiumpro -fomit-frame-pointer -ffast-math
>> По размеру делает icc в те же 3 раза, по скорости - примерно на ~15% (мне лично скорость более интересна, бо задача практически переборная).
По поводу размера: ты strip сделал??? strip <имя бинарника>
Сравнения несколько, по-моему, некорректны.
У тебя для компиляции используется gcc-2.96, а вот для альфы ты юзал 2.95 ...
Однако известно, что 2.96 - сакс, который оптимизацию производит только по известным только инженерам RedHat правилам. К примеру такая библиотека как ATLAS (Automatically Tuned Linear Algebra Software)(релизация BLAS) с 2.96-м на Intel'е даёт ужасные результаты (правда на Alpha - все ок).
P.S. Несколько offtopic: Сейчас как раз занимаюсь сравнением Portland Group и GNU компайлеров. Сравниваю на LINPACK'е (точнее ScaLAPACK'е) и мерю мелкий кластер из 2-х проц. P3-1000. Так вот, gcc+g77+g++ почти всегда либо делает ЛУЧШЕ, либо так же, как и Portland Group. Вот вам и коммерческий компилятор...
Специально для людей верующих в крутизну GCC.
Только сейчас снял цифирки...
платформа - Sun UltraSparcIIi 360Mhz, Solaris 8
Прога - стандартный тест FLOPS
gcc - GNU CC
cc - CC из Sun WorkShop
gcc -DUNIX flops.c -O3 -o flops.gcc
cc -DUNIX flops.c -xO5 -o flops.cc
./flops.gcc
FLOPS C Program (Double Precision), V2.0 18 Dec 1992
2AffreuxChien:
а шо, разве все пингвинофилы сидят исключит-но на камнях от AMD ? "Вам" могет это добро и не надо, а другим будет крайне полезно
ЗЫ: оптимизации для AMD at least в опциях icc не замечено ни разу
Я компилил ScaLAPACK под MPI причем без какого-либо использвоания SMP (а оно возможно, но МЕДЛЕННЕ для обоих компиляторов, чем обмен между процессорами через сетевой адаптер). НО! задача очень сильно грузит процессоры (решение систем линейных уравнений) и я, честно говоря, не понимаю почему pgi тут работает не быстрее GNU.
.... из малоприятного наблюдается несовместимость STL от gcc и icc :(
2Kirill: А я вот не представляю как можно соптимизироваить код - написанный под
MPI когда там уже все разложено _руками_ ... там же вся синхронизация фактически
выполняется вручную ...
BTW: А как был сделан вывод о более медленном исполнении в SMP ?
Или я чего не понял насчет железяки ? У тебя N узлов по 2xPIII ?
Я правильно понял ?
У нас в конторе делали евалюейшн Intela на ~30
разных машин на вычислительном софте под Вынь в сравнении
с MSVC. Прикольно, что было как относительное ускорение
до 35% так и замедление до 10%. Машины не самые
старые, памяти много, и интелы и амд. По данным углядеть
хоть какие-то закономерности мне не удалось.
Впрочем ускорение было на большинстве машин.
>Прикольно, что было как
>относительное ускорение до 35% так и замедление до 10%.
>Машины не самые старые, памяти много, и интелы и
Видимо первые это интель а вторые AMD
Сейчса как раз тестю icc на Athlon-ах (TB, XP)
- icc на них как раз проигрывает процентов по 10%
(а по размеру кода до 40% 8) )
Ну и еще имеется некий прикол при исполнении задачки на загруженом
до LA=4 (не локально - то есть нагрузка создается мигрировавшими задачами) ноде MOSIX кластера:
- задача построенная в gcc - в mtop показывает 100% загрузку процессора
- та же задача построенная в icc в mtop показывает 25 % (это РЕАЛЬНАЯ доля загрузки процессора данной задачей)
Из косяков наблюдаются глюки с обработкой exception-ов ...
А ты на слэшдот не ссылайся. У них своя башка, у тебя своя. Разницу между "делает код быстрее на 47%." и "делает код быстрее на 47% в тестах на интенсивные вычисления." понимаешь? Если нет, то и разговаривать с тобой не о чем. Если да, то признай ошибку и не пытайся скрыть за криками "ламера" свое собственное ламерство.
> asoneofus, хотите решение? Переходите на другую платформу, и не мучайтесь:)
> AC (*) (2002-01-29 02:21:26.0)
На интел? Увольтессс... Нафиг с пляжа!
Сан, ХП, - вещЧи неплохие, но на них девайс не сваяешь - запчастя в розницу не продаются :) (им.вв. кирпичи)
Остаётся АРМ - но эта поделка ещё та...
Кто - нить компИлер хороший под МИПС32 ИСА-2 знает?
Да и не дружит интель с gcc как то - инклуды ему, понимаш не те.
Да и что это за сервер регистрации такой, непонятно мне.
Можно говорить о преимуществах того или иного продукта по скорости на _отдельных_
тестах, но нет исходного кода - нет для меня и софта. Исходный код то ведь математически доказать можно, а фокусников-иллюзионистов много сейчас развилось.
2ZhekaSmith: "Разницу между"
Я же говорю - ты туп. Делает icc код быстрее? Делает? Есть еще вопросы? Ах да, он на вычислительных задачах делает, но вот бЯда, игрушки это тож вычислительные задачи, вебсервер тоже где-то там вычислительная задача... Так что иди отдохни...
Прежде всего большое спасибо Пионэру за публикацию, как сломать icc. Этот с%ка у меня никак
эту долбаную лицензию не находил и запускаться не хотел. А теперь о компиляторе. Ну, попробовал
я эту штковину на своем эмулятое. На самый первый самый поверхностный взгляд
а) то, что с icc размер запускаемого файла получается меньше - неправда. C gcc размер ~230к
c icc - 320k. б)*очень* непорадовало одно обстоятельство : компилю с -tpp5, он мне пишет
"overriding with -tpp6". Ну, и что сие значит ? То, что под P5 компилить не умеет ? Ну, во-первых,
это плохо, во-вторых, в хелпе
выдает, что может... Ну, машина-то у меня PIII, но на моей-то машине эмулятор и без оптимизации
летает ! Мне надо скомпилить как раз под первый пенек ! А вот что=то пока не получилось.
Скорость пока оценить не могу, завтра на пеньке погоняю (если запустится), о результатх напишу.
Мля ! Народ ! Этот iсс дейсвительно rulez ! Не дожидаясь завтра, я решил посмотреть, сколько
периодов тактовой частоты CPU кушают некоторые алгоритмы из моего эмулятора, при компиляции
разными компиляторами. Выбрал алгоритм синтеза звука как ИМХО наиболее ресурсоемкий. Так вот,
при компиляции эмулятора с помощью gcc этот алгоритм кушает ~540k периодов тактовой частоты CPU
за 1/50 секунды. При компиляции с помощью icc ... 320k !!! Т.е. ускорение ~60% !!! Я блин такого
не ожидал !!! Эмулятор написан на С. Плавающей запятой в этом аглоритме нет. Ключи gcc -0x,
где x=2,3,20 (разницы практически никакой) От разных -mx только хуже, от разных allignов никакого
эффекта. Ключи icc -ip -tpp5 -O3. А вот файлы больше получаются именно с icc. C разными ключами
получается поразному, но у icc стабольно на примерно идентичных ключах ~70% побольше.
Пора Огру еще прлюсик к хардлинкам записать.
Он, оказывается, не знает еще что есть вычислительные задачи.
Для него везде, где есть хоть одно вычислительное действие (например,
a[2]) - вычислительная задача. LOL.
2Ogr: меня мягко говоря поразило ваше представление о "вычислительных задачах" - похоже что вы несколько не рубите в данном вопросе. А сказать чего-нть непеременно хочется, да ? Большинство приведенных примеров целесообразнее писать вообще на скриптовых языках (вроде Perl & Python), а на C/C++ писать только действительно resource consuming вещи (SWIG rulez, очень рекомендую)
2lenin: KAI кстати на моей задачке тоже генерит код меньше чем gcc - уж и не знаю, чем это объясняется (скорее всего тем что gcc вставляет кучу мусора в init код, вроде инициализации системы ввода-вывода и проч. shit). Но KAI сосет по скорости по сравнению с icc.
Неприятно поразило следующее - большинство GNU софта настолько кривы и убоги и так заточены под кривой и убогий же gcc, что ничем другим просто не хочут собираться (для тех кто захочет обвинить меня в ереси и злобных нападках на любимого пингвинячьего бога c предложением сжечь на костре святой инквизиции - ну пересобирите хотя бы binutils на чем-либо отличном от GCC. Тогда и поговорим аргументированно. Я уже просто молчу про ваш главный фетиш Linux kernel). Есть повод задуматься...
2all: я тут еще отломал за компанию PGroup C++ 3.3-2 - надо кому ? Оно шо-то тоже не поражает воображение (код медленный и размерчик приличный у выходных файлов получается)
А мне кажется, что ничего удивительного в том, что коммерческий компилятор, да еще от производителя процессора генерирует код под этот процессор лучше, чем бесплатный и разработанный под тучу платформ. Странно, если было бы наоборот. И очень хорошо, что, в целом, gcc генерирует сравнимый код - по крайней мере всегда есть выбор.
>>>Я уже просто молчу про ваш главный фетиш Linux kernel
Уже не молчишь... Но причина - в истории вопроса. Заточка кода кернела именно под gcc _сознательный_выбор_ тов. Линуса. Обоснование - давайте не будем писать код портабельно под РАЗНЫЕ компиляторы, а будем писать код под ОДИН, но многоплатформенный компилятор. Практика все же говорит о том, что он похоже был прав - кто не согласен, пусть попробует сделать иначе. Давно пора.
На том же самом flops.c результаты которого на спарке были, на интеле под Linux было проведено сравнение gcc и icc.
Результат аналогичный - выигрыш от 50% до 100%.
2Ogr: "Number crunching" и "numerically intense" в оригинальной статье означают определенный тип задач. Это - расчетные задачи (погоды,
атомных взрывов), мультимедиа (включая обработку изображений) и цифровая сигнальная обработка (DSP).
Такие задачи характеризуются тем, что хорошо подходят для векторной архитектуры - в них много одинаковых операций над векторами (массивами) данных. Если использовать SIMD (Single Instruction Multiple Data) расширения, такие как MMX/SSE, можно добиться ускорения в несколько раз. При необходимости такие задачи оптимизируют вручную (для интела на ассемблере), т.е. хороший компилятор помогает, но ручная оптимизация может добавить еще немало скорости.
Веб-серверы, ядра, перл, офисы и прочее к таким задачам не относятся.
Вообще. Игрушки относятся, но, сюрприз, критические участки тоже оптимизируют вручную.
2ZhekaSmith: Теоретик ты наш... Помолчал бы, а?
"хороший компилятор помогает, но ручная оптимизация может добавить еще немало скорости"
Тебе дать url с документацией по процессору и попросить тебя ею воспользоватся при оптимизации руками? :) Или сам уже понял какую чушь сказал? Оптимизация асемблера руками это критинизм достойный студента первого курса заборостроительного техникума.