LINUX.ORG.RU
Ответ на: комментарий от anonymous

Англоговорящему анонимусу: Я и говорю, что политика Intel по отношению к компиляторам более чем странная. Зачем выводить ICC на линукс, когда там уже есть kai, который стоит столько же, гораздо качественнее, и при этом принадлежит _им_же. Я не вижу в этом никакой логики кроме подковерных разборок в интеле. Может, они хотят затащить на линукс свой кодогенератор, который в отличие от kai умеет mmx/sse, может, хотят в будущем скрестить "оптимизатор" kai и свой кодогенератор, может, две разные команды соревнуются... Резюме -- "внешней" логике вывод этого компилятора не поддается -- смысла в нем очевидно нет.

AC
()
Ответ на: комментарий от mjt

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

Antichrist
()
Ответ на: комментарий от Antichrist

Кстати, Antichrist, расскажи, как это компилятор _C++_ может заюзать SIMD? Правда, интересно. Как он срюхнет, когда нужны соответствующие инструкции? Автоматом проанализирует циклы по массиву и разложит его по регистрам? Он же не знает ничего ни про векторы, ни про матрицы? Или SIMD будет использоваться в его реализации stl?

AC
()
Ответ на: комментарий от AC

Судя по всему - какой-то вумный анализ. Раскладывает dataflow в пределах функции, сортирует по независимым блокам, ищет похожие операции над разными данными - и сливает в одну SIMD. Я бы так сделал...

Antichrist
()
Ответ на: комментарий от AC

Thanx. Заврался я. Не нашёл демку для спарка - и обиделся зело :(

Antichrist
()

2ZhekaSmith: Ты туп, уж извини, но это факт.
"не умеющий читать по английски"
Почему-то для слащдота это нормально http://slashdot.org/developers/02/01/26/1328215.shtml
А для тебя нет. И я даже знаю почему :) Потому что ты относишся к этому как к своей личной обиде, что доказывает твой уровень развития.
"не умеющий ... писать по русски"
Уж кто-бы говорил... По-русски, по-английски пишется именно так, марш в школу, в пятый класс, до учиватся.
"Кстати, в VC есть куски кода интеловского компилятора"
И? А gcc инженеры от интеля тоже затачивали, чтоб он уж совсем отстойным не был...

Ogr
() автор топика
Ответ на: комментарий от Antichrist

KAI только под x86???

Ой, со зла це, ой со зла... Собственно, под x86-то как раз и промашка у них есть -- нет win32 версии. Потому и связались с Интелом.

Вчепятление: KAI правильнее во всех отношениях, но Intel -- очень-очень хорош. Хотя иногда-таки дерьмо лепит (типа Internal Compiler Error), но довольно редко и есть надежда на улучшение.

ingvarr
()

А где чайнику найти хорошие доки (желательно хотя бы часть на русском) про компиляцию программ под Линукс. Для меня опции gcc - это темный лес. О2 или О10 не о чем не говорят.

anonymous
()

а вот на Мипсы все болт положили :(, гады...

Вот и я говорю, нет кэя под МИПС-ы 32-р... ИСА-2... :( сиротааааа яяя... так и придётся гнуться (и они тоже положили :)), да на ассемблёре ручками разгребать... (мать... мать... мать... привычно отозвалось эхо:))

asoneofus
()

btw, кто там длинные строчки параметров gcc приводил, -mprentium != -march=pentium, второй вариант правильнее

anonymous
()

To Antichrist (*) (2002-01-28 23:49:16.0):

Н-да, впечатляет.

alexros
()

Быстрые опции GCC

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 <имя бинарника>

saper ★★★★★
()

Ogr "не умеющий ... писать по русски" Уж кто-бы говорил... По-русски, по-английски пишется именно так, марш в школу, в пятый класс,

***до учиватся.***

;)

anonymous
()

А для K7 какой он код делает?.

Господа! Какое качество кода у интеловского компилятора при оптимизации под K7 (Athlon)?
Если никакое - то нам такого "добра" задаром не нужно.

AffreuxChien
()

To Antichrist (*) (2002-01-28 23:49:16.0) >

Сравнения несколько, по-моему, некорректны.
У тебя для компиляции используется 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. Вот вам и коммерческий компилятор...

Kirill
()

Специально для людей верующих в крутизну 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

Module Error RunTime MFLOPS (usec) 1 2.8422e-14 0.1541 90.8722 2 2.5047e-13 0.0605 115.6129 3 -7.6605e-15 0.1450 117.2414 4 2.2771e-13 0.1661 90.3104 5 3.8858e-14 0.2418 119.9354 6 7.5495e-15 0.1845 157.2215 7 -1.1369e-13 0.2871 41.7959 8 1.2612e-13 0.2088 143.7126

Iterations = 128000000 NullTime (usec) = 0.0030 MFLOPS(1) = 116.1403 MFLOPS(2) = 74.5155 MFLOPS(3) = 105.2430 MFLOPS(4) = 129.2069 /flops.cc

FLOPS C Program (Double Precision), V2.0 18 Dec 1992

Module Error RunTime MFLOPS (usec) 1 -7.6739e-13 0.0664 210.6996 2 -5.7021e-13 0.0515 135.9636 3 -2.4314e-14 0.0492 345.6712 4 6.8501e-14 0.0464 323.2323 5 -1.6320e-14 0.1466 197.7624 6 1.3961e-13 0.1104 262.7965 7 -3.6152e-11 0.1994 60.1881 8 9.0483e-15 0.1255 239.1034

Iterations = 256000000 NullTime (usec) = 0.0000 MFLOPS(1) = 169.6012 MFLOPS(2) = 124.9462 MFLOPS(3) = 196.2716 MFLOPS(4) = 274.5875 Смотрим преимущество в процентах над GCC MFLOPS(1)= 46% MFLOPS(2)= 68% MFLOPS(3)= 87% MFLOPS(4)= 113% То есть минимальное преимущество - 46%, максимальное - 113%.

anonymous
()

BTW: Так он (Intel) как выяснилось еще и OpenMP умеет *8) !!!!

Кто нибудь сравнивал его в оном на SMP с Portland ?

2Kirill: А что твой тест юзает ? MPI ? OpenMP ?

Насколько я знаю Portland хорош для SMP+OpenMP а на "плоском" коде он проигрывает gcc PS: ... для кластера все сложнее ...

/SS

anonymous
()

2saper: да, был сделан strip -R .comment -R .note

Для полноты жизни еще отломал KAI C++ 4.0f for RedHat(e) 7.1
(вот тут лежит: http://developer.intel.com/software/products/downloads/KCC-4.0f3-i386-7.1.htm)

kfront (size 2847600)
Offset 2ad2e8, меняем первый 0 из 00 00 00 00 a0 a8 20 08 на 1
kfront-thin (size 1775660)
Offset 1ac888, меняем первый 0 из 00 00 00 00 84 5b 16 08 на 1

Есть подозрение что и под все остальные платформы весь FlexLM 7 отламывается исправлением одного бита, но мне смотреть ломы. Да и надо ли оно кому ?

Старый пионэр

anonymous
()

2AffreuxChien:
а шо, разве все пингвинофилы сидят исключит-но на камнях от AMD ? "Вам" могет это добро и не надо, а другим будет крайне полезно
ЗЫ: оптимизации для AMD at least в опциях icc не замечено ни разу

Старый пионэр

anonymous
()

To SS:

Я компилил ScaLAPACK под MPI причем без какого-либо использвоания SMP (а оно возможно, но МЕДЛЕННЕ для обоих компиляторов, чем обмен между процессорами через сетевой адаптер). НО! задача очень сильно грузит процессоры (решение систем линейных уравнений) и я, честно говоря, не понимаю почему pgi тут работает не быстрее GNU.

Kirill
()

.... из малоприятного наблюдается несовместимость STL от gcc и icc :(

2Kirill: А я вот не представляю как можно соптимизироваить код - написанный под MPI когда там уже все разложено _руками_ ... там же вся синхронизация фактически выполняется вручную ...

BTW: А как был сделан вывод о более медленном исполнении в SMP ? Или я чего не понял насчет железяки ? У тебя N узлов по 2xPIII ? Я правильно понял ?

/SS

anonymous
()

У нас в конторе делали евалюейшн Intela на ~30 разных машин на вычислительном софте под Вынь в сравнении с MSVC. Прикольно, что было как относительное ускорение до 35% так и замедление до 10%. Машины не самые старые, памяти много, и интелы и амд. По данным углядеть хоть какие-то закономерности мне не удалось. Впрочем ускорение было на большинстве машин.

anonymous
()
Ответ на: комментарий от anonymous

>Прикольно, что было как >относительное ускорение до 35% так и замедление до 10%. >Машины не самые старые, памяти много, и интелы и

Видимо первые это интель а вторые AMD

Сейчса как раз тестю icc на Athlon-ах (TB, XP)

- icc на них как раз проигрывает процентов по 10%

(а по размеру кода до 40% 8) )

Ну и еще имеется некий прикол при исполнении задачки на загруженом до LA=4 (не локально - то есть нагрузка создается мигрировавшими задачами) ноде MOSIX кластера: - задача построенная в gcc - в mtop показывает 100% загрузку процессора - та же задача построенная в icc в mtop показывает 25 % (это РЕАЛЬНАЯ доля загрузки процессора данной задачей)

Из косяков наблюдаются глюки с обработкой exception-ов ...

/SS

anonymous
()

Ogr: "Почему-то для слащдота это нормально"

А ты на слэшдот не ссылайся. У них своя башка, у тебя своя. Разницу между "делает код быстрее на 47%." и "делает код быстрее на 47% в тестах на интенсивные вычисления." понимаешь? Если нет, то и разговаривать с тобой не о чем. Если да, то признай ошибку и не пытайся скрыть за криками "ламера" свое собственное ламерство.

ZhekaSmith
()
Ответ на: комментарий от AC

> asoneofus, хотите решение? Переходите на другую платформу, и не мучайтесь:)
> AC (*) (2002-01-29 02:21:26.0)

На интел? Увольтессс... Нафиг с пляжа!
Сан, ХП, - вещЧи неплохие, но на них девайс не сваяешь - запчастя в розницу не продаются :) (им.вв. кирпичи)
Остаётся АРМ - но эта поделка ещё та...

Кто - нить компИлер хороший под МИПС32 ИСА-2 знает?

КАИ не в счёт, он для МИПС64 ИСА-1/2...

asoneofus
()

To SS:

Эта тема - offtopic. Ежели есть интерес пиши на birk_at_chat.ru

Kirill
()
Ответ на: комментарий от Kirill

На Byte2 - точно никакой разницы между 2.95.x, 2.96 и 3.x нет, я уже проверял. Так что корректно.

Ну а по поводу g77 - на фига он такой, если только 77? Мне 90 нужно. И HPF. Именно в разпараллеливании вся прелесть Portland-а.

Antichrist
()
Ответ на: комментарий от Kirill

А я понимаю... ATLAS и без того ручками заоптимизирован до опупения, компилеру там делать нечего. ;)

Antichrist
()

А почему g++

void main(){}

может, а для интеля надобно

int main() {}

Да и не дружит интель с gcc как то - инклуды ему, понимаш не те.

Да и что это за сервер регистрации такой, непонятно мне.

Можно говорить о преимуществах того или иного продукта по скорости на _отдельных_ тестах, но нет исходного кода - нет для меня и софта. Исходный код то ведь математически доказать можно, а фокусников-иллюзионистов много сейчас развилось.

NikS
()

2ZhekaSmith: "Разницу между"
Я же говорю - ты туп. Делает icc код быстрее? Делает? Есть еще вопросы? Ах да, он на вычислительных задачах делает, но вот бЯда, игрушки это тож вычислительные задачи, вебсервер тоже где-то там вычислительная задача... Так что иди отдохни...

Ogr
() автор топика
Ответ на: комментарий от Ogr

Ogr (*) (2002-01-29 20:15:51.0)

Юродивое ты наше...

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

Это мог сказать только человек, не имевший дела с вычислениями.

При вычислительных штуках 1% производительности -- это экономия часов и дней. Для игрушки или вебсервера это ноль без палки.

4-7% -- недалека разница...

ingvarr
()

Прежде всего большое спасибо Пионэру за публикацию, как сломать icc. Этот с%ка у меня никак эту долбаную лицензию не находил и запускаться не хотел. А теперь о компиляторе. Ну, попробовал я эту штковину на своем эмулятое. На самый первый самый поверхностный взгляд а) то, что с icc размер запускаемого файла получается меньше - неправда. C gcc размер ~230к c icc - 320k. б)*очень* непорадовало одно обстоятельство : компилю с -tpp5, он мне пишет "overriding with -tpp6". Ну, и что сие значит ? То, что под P5 компилить не умеет ? Ну, во-первых, это плохо, во-вторых, в хелпе выдает, что может... Ну, машина-то у меня PIII, но на моей-то машине эмулятор и без оптимизации летает ! Мне надо скомпилить как раз под первый пенек ! А вот что=то пока не получилось. Скорость пока оценить не могу, завтра на пеньке погоняю (если запустится), о результатх напишу.

lenin
()

Мля ! Народ ! Этот 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% побольше.

lenin
()

Пора Огру еще прлюсик к хардлинкам записать. Он, оказывается, не знает еще что есть вычислительные задачи. Для него везде, где есть хоть одно вычислительное действие (например, a[2]) - вычислительная задача. LOL.

anonymous
()

2 lenin:
Ну раз даже ленин из мавзолея поднялся чтобы зарулезить новый компилер - значит он и правда рулез :-D lol

eXOR ★★★★★
()

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 - надо кому ? Оно шо-то тоже не поражает воображение (код медленный и размерчик приличный у выходных файлов получается)

Старый пионэр

anonymous
()
Ответ на: комментарий от anonymous

А мне кажется, что ничего удивительного в том, что коммерческий компилятор, да еще от производителя процессора генерирует код под этот процессор лучше, чем бесплатный и разработанный под тучу платформ. Странно, если было бы наоборот. И очень хорошо, что, в целом, gcc генерирует сравнимый код - по крайней мере всегда есть выбор.

anonymous
()

>>>Я уже просто молчу про ваш главный фетиш Linux kernel

Уже не молчишь... Но причина - в истории вопроса. Заточка кода кернела именно под gcc _сознательный_выбор_ тов. Линуса. Обоснование - давайте не будем писать код портабельно под РАЗНЫЕ компиляторы, а будем писать код под ОДИН, но многоплатформенный компилятор. Практика все же говорит о том, что он похоже был прав - кто не согласен, пусть попробует сделать иначе. Давно пора.

anonymous
()

Простите, может быть я что нибудь недопонимаю, но для меня переносимость и открытость кода важнейшие критерии.

Я лучше куплю себе машину, работающую побыстрее, нежели откажусь от этих критериев.

Если бы не AT&T UNIX+C, то сейчас бы и писали на ассемблере, да на Фортранах, что конечно бы было бы хорошо, но дороговато.

NikS
()

Из косяков icc замечено:

SIGSEGV в exit(status)

#include <iostream.h> int main( int argc, char **argv ) { cout << "Test\n"; exit(-1); return 0; }

При status != 0 ... интересно почему ?

/SS

anonymous
()

На том же самом flops.c результаты которого на спарке были, на интеле под Linux было проведено сравнение gcc и icc. Результат аналогичный - выигрыш от 50% до 100%.

anonymous
()

2Ogr: "Number crunching" и "numerically intense" в оригинальной статье означают определенный тип задач. Это - расчетные задачи (погоды, атомных взрывов), мультимедиа (включая обработку изображений) и цифровая сигнальная обработка (DSP). Такие задачи характеризуются тем, что хорошо подходят для векторной архитектуры - в них много одинаковых операций над векторами (массивами) данных. Если использовать SIMD (Single Instruction Multiple Data) расширения, такие как MMX/SSE, можно добиться ускорения в несколько раз. При необходимости такие задачи оптимизируют вручную (для интела на ассемблере), т.е. хороший компилятор помогает, но ручная оптимизация может добавить еще немало скорости.

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

ZhekaSmith
()

2ZhekaSmith: Теоретик ты наш... Помолчал бы, а?
"хороший компилятор помогает, но ручная оптимизация может добавить еще немало скорости"
Тебе дать url с документацией по процессору и попросить тебя ею воспользоватся при оптимизации руками? :) Или сам уже понял какую чушь сказал? Оптимизация асемблера руками это критинизм достойный студента первого курса заборостроительного техникума.

Ogr
() автор топика

Для тех кто говорил про работу на AMD http://rsdn.ru/article/?devtools/perftest.xml довольно интересное чтение.
2ZhekaSmith: А Вам в обязательном порядке прочитать вот эту часть http://rsdn.ru/article/?devtools/perftest.xml#IDAYQR2JB надеюсь что после это перед произнесением слова уже будет думать.

Ogr
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.