gcc vs icc

А как там поживают Graphite и OpenMP из GCC-4.4 на многопроцессорных системах? У меня подозрение, что на 12 ядрах оно будет так работать, что большего не захочется. Ну, хотяб первое время :)

может у них просто код такой?

> А как там поживают Graphite и OpenMP из GCC-4.4 на многопроцессорных системах? У меня подозрение, что на 12 ядрах оно будет так работать, что большего не захочется. Ну, хотяб первое время :)

ты идиот, зачем 12 ядер для файнридера ?

Правильно! Криворукие быдлокодеры с пропропиетарным глюкоподелием не нужны! Так... а о чём это я?..

Или в задницу, это для фапа.

> может у них просто код такой?

Не верю, что они специально так писали, чтобы быстрее работало в MVC++ и icc и плохо в gcc. У них самих проблемы, что gcc дает медленный результат.

ICC отличается крайне агрессивным инлайнингом кода и специфичным для intel выравниванием.
Мне интересно, на каком процессоре они все это дело тестировали..

>код откомпилированный gcc медленнее до 35-40%

вероятно не осилили флажки выставить получше?
Хотя ICC на математике libgmp опережает Gcc на 17-25%
Так что вполне возможно, если у них такой специфичный код ICC будет и лучше

>Почему так сейчас, если было время gcc генерировал хороший код?

GCC генерирует хороший код, просто ICC имеет свою изюминку и в отдельных случаях проявляет себя гораздо лучше для оптимизации некоторого кода.

>А как там поживают Graphite и OpenMP из GCC-4.4 на многопроцессорных системах?

OpenMP требует усилий программистов по распаралелливанию, а вот ICC умеет эвристически распаралелливать код ( флажок -parallel ) , вот только практического эффекта с ускорением я пока не наблюдала от этого

Сильви, ты местный Онотоле!

фу

>OpenMP требует усилий программистов по распаралелливанию

Не думал что ты настолько хорошо это изучишь )) Подскажи ссылки на документацию, тесты, если не сложно.

исключительно в интеллектуальном плане.

я не пишу программы, поэтому посмотрела первую попавшуюся статью на openmp.org
и парочку примеров по распаралелливанию оттуда же

Благодарю! :)

GCC сейчас полное говнище по сравнению с icc и msvc8-9. Непотяно, чего ты так рьяно пытаешься отстоять его честь.

>GCC генерирует хороший код, просто ICC имеет свою изюминку и в отдельных случаях проявляет себя гораздо лучше для оптимизации некоторого кода.

Скорее наоборот: gcc генерирует хороший код для _некоторых_ случаев (там работа с матрицами и мат. выражениями), но во всем остальном сливает где только может - по мелочам конечно, но в итоге из этих мелочей и накапливается 30-40% проигрыша.

на маке же есть искод. зачем они использовали ггц?

Реквестирую тест GCC vs ICC на процессорах amd. Ни про какие 40% там даже речи идти не будет.

хорошо, выдайте другой , желательно свободный , компилятор для *nix

есть альтернативы? то-то же

Будет, если пропатчить бинарник, сделанный ICC, чтобы он не проверял производителя процессора.

>хорошо, выдайте другой , желательно свободный , компилятор для *nix
>есть альтернативы? то-то же

отсутствие свободных альтернатив - не оправдание GCC и не повод, чтобы фанатично доказывать на всех форумах, что "это просто код у вас неправильный" (типа товарища zlobnyi uzer)

в таком случае идите на винфак, целевую платформу msvc обсуждают там.

Ололо, сразу так переход на личности/офтопик =) Слив защитан.

с того форума

>Код идентичен, версия icc 11. разрядность платформы 32. настройки gcc -03 для большей части файлов, у интела - дефолтные, пока с ним только играемся.


нда, хоть бы -march=pentium3 -mfpmath=sse -fomit-frame-pointer добавили, а то просто -O3 с -march по умолчанию (386 / 486) и математикой 387

* pentium3 - используется ICC by default

> хорошо, выдайте другой , желательно свободный , компилятор для *nix
> есть альтернативы? то-то же

Свободный - лишние условие. Взрослые люди не фапают на открытые исходники. Важен результат.

Столлмана на вас нет...

trusted trust

>Реквестирую тест GCC vs ICC на процессорах amd

я тестировал из любопытства на одной своей программке на амд 2600. при аналогичной оптимизации код icc был на пару процентов быстрее. на бенчмарк конечно не претендую

> Ололо, сразу так переход на личности/офтопик =) Слив защитан.

Трололо, твоя опера чем откомпилена?

> У меня подозрение, что на 12 ядрах оно будет так работать, что большего не захочется. Ну, хотяб первое время :)

Само оно работать не начнет под openmp код надо затачивать. Если делать в тупую, то оно может начать жрать все 4 ядра, а работать при этом медленнее.

>было время gcc генерировал хороший код?
Кто тебе сказал, что оно было? АФАИК gcc всегда сливал icc по оптимизации.

Ясно. Спасибо. Подождём несколько лет, пока многоядерные системы распространятся :)

А если найду? =)

Компиляторов СИ хоть жопой жуй. От маленьких типа tcc, до таких как ack, которым афаик миникс собирается. С си++ сложнее - есть tendra, но "C++ support is extremely limited in this release". Ну и есть gcc-llvm и clang.

Ты забыл форк части GCC для нужд ядра. Недавно в рассылке это извращение попалось. Хотя там больше препроцессор хотят переписать...

Мрм, это kgcc64 чтоль? один хрен это производный.

Врядли. Этому уже не первый год пошёл, а обсуждение новое. Ну, если я ничего не напутал :)

gcc-llvm это тот же самый gcc, но он генерит код для llvm

ищите, только чтобы это был действительно компилятор способный собрать чуть больше пакетов чем только себя и с хоть какими-то возможностями для оптимизации, боюсь не найдете...
Ну и в основном многое очень делают для GCC, я вот в другом треде aria2 для теста пыталась собрать ICC - не вышло.

> А как там поживают Graphite и OpenMP из GCC-4.4 на многопроцессорных системах? У меня подозрение, что на 12 ядрах оно будет так работать, что большего не захочется.

OpenMP - расширение языка(pragma), отвечающее за возможность сказать компилятору что, где и как параллелить. В особо очевидных случаях некоторые компиляторы (Intel, и похоже gcc 4.4) научились сами вставлять те же инструкции, но это нужно очень большое везение чтобы так распаралеленная прога нормально использовала хотябы 2 ядра. Руками нужно писать...

P.S. Год назад пробовал собрать свой проет по работе(область - CFD HPC) на intel - получил примерно тот же уровень производительности что и gcc -O2. На этом и забил.

> Ну и в основном многое очень делают для GCC

Что есть плохо.

Вот кстати benchmark-и нескольких версий gcc и intel 11 на матричных операциях(судя по числам - матрицы плотные): http://eigen.tuxfamily.org/index.php?title=Eigen2_benchmark_Intel . Intel там далеко не всегда так уж и жжот. Так что imho в каждом отдельном случае нужно смотреть кто быстрее а не молиться на intel/ms/ibm/sun/etc. ожидая от них гарантированного выигрыша.

>а не молиться на intel/ms/ibm/sun/etc. ожидая от них гарантированного выигрыша.
для этого знания нужны, легче верить и чтобы все другие тоже верели, а не gcc использовали ;)