» Intel C++ Compiler

SnowWhite
А если не в тупую, а подумать? Отчеты оптимизатора и векторизатора посмотреть? Задуматься над методикой тестирования?

если не "втупую", то здесь не спрашивал бы, а сделал все сам %)

выложил тут http://getfile.biz/20253 результаты по отчетам для х86-32 только для обычного зиона, потому как железок обычных без емт64 у меня больше.
амд64 вообще рвет в числодробильных тестах что х86-32, что х86-ЕМТ64 процы, неважно, каким компилером сгенерен код (мс или интел), интел вырывает победу только на мд5 (по тестам наблюдается достаточно ровная зависимости скорости работы (счета) хеширования по мд5 от тактовой частоты процессора), и то, когда у него тактовая частота задрана под 4ГГц, но такие таковые частоты - неспортивно, гнать процы вредно %).
тест проводился на сгенеренном коде путем выполнения строки "openssl.exe speed md5 sha1 aes" или что-то в этом роде. потом результаты заносились в таблицу =))

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

отчет оптимизатора во время компиляции были в стиле "unrolling loops", двухстадийную оптимизацию с применением VTune не делал - это уж совсем не честно по отношению в МС, так как у них подобные игрушки будут только в МС ВС 2005.

если интересно, то можете сами скомпилить библиотеку и посмотреть на отчеты, я сам смогу это сделать после выходных ;(

SnowWhite
Пока собрал на визуалке, на домашнем компе нет инетловского компайлера. На днях раздобуду, попробую отпишусь. Вообще есть еще некоторые вопросы.
1. Зачем соственно это нужно (кроме чисел). Я например твердо уверен что интеловский обгонит микрософтовский в умелых руках. Я этим уже занимаюсь двольно давно, чтобы так утверждать.
2. С какими ключами был собран проект, и под какую платформу _точно_ делаем.
3. Ваши результаты было бы неплохо увидеть. Хотя бы с чем сравниться. А то у меня может процессоры неправильные, и т.п.

ну вот скачайте файлик =))
там все написано - результаты теста (скорости работы), ключи компилеров, также указан процессор на котором гонялось (зион х86-32, 2.4 ГГц). в выложенном файлике есть две интересных страницы (sheet) - х32 и sheet6. просто почему тема меня заинтересовала?

осенью 2004-го делал то же самое - собирал актуальную на тот момент версию openssl двумя компилерами - мс и интел. тока в 2004-м я еще использовал (как смог) VTune. так вот, тогда скорость интелового кода была где-то на 25% быстрее! а сечас микрософтный код догнал и, в некоторых случаях, перегоняет по производительности интеловый код. но осенью 2004 я не делал таких масштабных тестов с ключами компилера - просто взял самые быстрые у каждого компилера и сваял. и год мне хватало производительности кода =) а вообще, почитав рассылку опенссл и посмотрев на какие-то куски кода, где я могу что-то понять, у меня создалось такое впечатление, что сама библиотека опенссл оптимизируется под амд и микрософтный компилер.

зачем это надо? любая программа, которая использует хеширование, шифрование. да и хочется некоторые cygwin-овские поделки перекомпилить под натив win32, потому как гцц под цигвином далеко не первый по скорости генерируемого кода.

SnowWhite
Посмотрел табличку. Я право немного в затуднении, как раз icl и неплохо выглядит по сравнению с cl. больший результат лучший - скорость изменяется в количестве байт, обработанных за 1с. Посмотрите свою табличку сами, сравните 13 тест для icl с любым у cl.
Есть конечно некоторые провисания, но я думаю что они устраняться после более детального изучения картины.
Кроме того вы сами мухлюете - используете /Qparallel и /Qssp, что имеет смысл тока на гипертридинге или SMP-шной машине (как у вас), а с сериальной версией еще до конца не разобрались.
Еще посоветую вам использовать:
/QxP - для векторизации под SSE2/3;
/ipo - для инлайнинга мелких функций;
/Ow - для выравнивания компилятором данных под SSE;
/ftz - для ускорения работы с денормализованными флоатами;
/Qrcd - ускорение перевода чисел;

По поводу unroll могу сказать что это неодназначно, и зависит от количества проходов цикла, так что на вашем месте я бы применял ее вдумчиво. Так же вариант с /O2 может быть быстрее чем /O3. Ну и не стоит забывать что есть еще прагмы и интринсики для особо упорных

Dust

в сравнении с 6 экземпляром cl 13 версия не так сильна.

/ipo (/Qipo) не работает - у компилера крышу сносит где-то в середине компиляции (начинает страшно ругаться на этапе линковки). Если внятно объясните, как ей пользоваться, то буду очень благодарен.

/QxP - я пользовался /QaxN (7-й вариант) - показало плохие результаты
/Ow - не пробовал
/ftz - не пробовал
/Qrcd - не пробовал
вообще-то меня заботит точность вычислений, при всяких трюках с помощью ключей компилера не будет ли фатальной потери точности вычислений?

Когда эта эпопея с компиляньем была, то читал про интринсики, не впечатлило, потому как вроде О2 или Ох включает все эти интринсики, или не так?

И еще: просто так интеловый компилер не слишком хочет компилить библиотеку 098 или 098а, как буду на работе, попробую с этими четыремя ключами. Так что, было бы неплохо, если бы вы сами попробовали откомпилить сие чудо интеловым компилером, чтобы "изнутри" на картину взглянуть...

Да, у меня смп машина, но самое интересное, что эти /Qparallel и /Qssp только портят картину. Библиотека (длл) не слишком многопоточная (((

В общем, хотелось бы достичь большей скорости, чем 6-й вариант =))))

п.с. как раз у 13-го варианта самые низкие показатели...
п.п.с. и еще: усредненная производительность у 6-го варианта самая большая, и в sha-1 он - лидер.

SnowWhite
Про IPO. Есть там бажина (или фича, я не пойму почему ее так долго не пофиксят), если на промежуточном этапе сборки сначала собирается библиотека, которая используется в следующей стадии, то IPO не собирается. В общем в нашем случае это скорее всего глухой угол, можно попробовать собрать финальный бинарь с ним. Или орграничиться на первое время IP. Разница в них в том, что IPO осуществляет оптимизаицию между модулями, тоесть может заинлайнить функцию с дркгого *.с.
Из вышеназванных ключей на точность может повлиять только Qrcd, ftz - очень слабо, никогда мне не попадалось таких приложений.
Так же я вижу что вы не понимаете что такое интринсики. Это, подобно ассемблеру, псевдокод, который напрямую транслируются в машинные инструкции. Из поддержка целиком относиться к компилятору, поэтому код на интринсиках не является портабельным.
Работа с интринсиками есть при любой степени оптимизации.
Ладно, пока есть предложение свести противостояние к некоторым вариантам.
Например вы жалуетесь на sha-1, и будем пытаться его подтянуть.

cool!

спасибо за участие! =)

прав ли я, если скажу, что интринсики есть и в МС? если да, тогда я примерно понимаю в чем дело и почему их не совсем корректно использовать (вернее, надо аккуратно) - в интеловом компилере есть надмножество интринсиков, которые ни в мс ни в гцц не поддерживаются. это раз. два - некоторые мс-ные интринсики не поддерживаются в интеле. в рассылке по опенссл был разговор про переносимость кода между компилерами. и был отдельный спор вроде про memmove (или что-то такое) - про скорость инструкции и то, как она превращается в ассемблерный код. в общем, я не думаю, что с моими знаниями нужно лезть в ассемблерные куски библиотеки =)

SnowWhite
Есть интринсики (типа __mm_movpd()), есть функции, которые распознаются компилятором и переводяться им на интринсики. Так например функция работы с памятью (например memcpy()) распознается, и вместо побайтового копирования (как это забито в библиотеках) используется SSE копирования по 64бита.

SnowWhite

Цитата:

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

/Ow (выравнивание на 16 байт) -- для интеловских процессоров (на AMD не пробовал) дает ускорение даже при использовании FPU.

Потеря точности может произойти при использовании SSE2/3 (это надо проверить). Внутренне представление чисел в FPU 80- битное независимо от представление исходных. Для SSE2 исходные числа 64 - битные, а скольно разрядов использутся при внутренних вычислениях это вопрос.

Неделю меня не было...

Короче, на выходных сделал 10 вариантов компиляции опенссля...

МС рулит )))

В результирующей софтине самые большие цифры показывает опессл, которая собрана на вижуал студии.

На микрософте рулят ключи /MD /Ox /O2 /Ob2 /W3 /WX /Gs0 /GF /Gy /nologo /G7 /GL /arch:SSE2

У интела скорость меньше на 10%. Самая рульная сборка у интела получается с ключами компилятора /MD /Ox /O2 /Ob2 /W3 /Gs0 /GF /Gy /nologo /Ow /Qip

это правда. нечто типа /arch:xxx /QxX /Qssp совершенно не катят (только хуже). Ванильная компиляция интелом на зионе работает быстрее всего из интеловых вариантов и проигрывает мс-ной компиляции ))))))))

Интел аццтой, я так не играю. Хотя, чует мое сердце, это асмовские куски md5 и sha1 заточены под ml.

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

тогда зачем такая странная методика тестирования?
генерим ~~1M случайных чисел, пишем все это дело в файл. пишем простейшую сортировку пузырем и запускаем...

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

вопрос: как добиться максимальной скорости софтины? ответ: экспериментировать с тем, с чем можно - с библиотекой опенссл.

SnowWhite
Странно что /MD. Это ж dll использоваться будет.

Цитата:

У интела скорость меньше на 10%. Самая рульная сборка у интела получается с ключами компилятора /MD /Ox /O2 /Ob2 /W3 /Gs0 /GF /Gy /nologo /Ow /Qip

Как я понял из доки, /Ox то же самое что /O2.

Код: O2
Enables optimizations for speed. This is the generally recommended optimization level.
On Itanium-based systems, this option enables optimizations for speed, including global code scheduling, software pipelining, predication, and speculation.
-- skip --
On Linux systems, this option is the same as the O option.
On Windows systems, this option is the same as the Ox option.
On Windows IA-32 systems, the O2 option sets options /Og, /Oi-, /Os, /Oy, /Ob1, and /Gs.

/O3 не очень...
Там я выкладывал ексель со сводными результатами. О3 не катит.

Ох и О2 вдвоем это от того, что мне вдумчиво доку лень читать =) Так что, на всякий случай, вместе. Тем более, что компилер самую быструю выберет.

А что такого странного в /MD? =)) Лучше /MT? Если библиотека подгружается вместе со стартом софтины, и потом начинается числомолотилка, то библиотека все это время в памяти висит, потому что счетчик юзаний библиотеки не уменьшается до нуля. Вроде так ) Так что, с этой точки зрения мд=мт. Или нет?

Я не уверен, но не исключено, что при использовании /MT компилятору будет легче оптимизировать код - во-первых, он будет иметь доступ к содержимому библиотек (что ему вряд ли поможет), а во-вторых, у него будет возможность делать inline, он же использует link time code generation (а вот это может ускорить работу)

х-мм...
надо будет затестить )

ну, статическая компиляция дала плоды - прирост порядка 1-3% =)))
только /MT в понимании микрософтного компилера совсем не то, что в понимании интелового, начались глюки с объявлением одних и тех же функций в разных мс-ных библиотеках:
Цитата:

libeay32.lib(rand_lib.obj) : warning LNK4218: non-native module found; restarting link with /LTCG
MSVCRT.lib(MSVCR71.dll) : error LNK2005: _isdigit already defined in LIBCMT.lib(_ctype.obj)
MSVCRT.lib(MSVCR71.dll) : error LNK2005: _memchr already defined in MSVCRT.lib(MSVCR71.dll)

пришлось /G7 /arch:SSE2 /Ox /O2 /Ob2 /nologo /MT /W3 /Gs0 /GF /Gy
менять на /G7 /arch:SSE2 /Ox /O2 /Ob2 /nologo /MD /W3 /Gs0 /GF /Gy

сама либа стала 8 мегов =))

Появился вопрос - чем отличаются релизы 9.1.028 и 9.1.029. На сайте не нашел

Добавлено:
Эк меня глючит сегодня 029 еще нет.
А где вообще changelog посмотреть-то?

Хороший компилятор. В полтора раза ускоряет, минимум.
А еще лучше объединить его с ручным ассемблером SSE2/3.
Тогда вообще хорошо становится.

Уже месяц имеюсь с этим делом...

Компилировал программу по решению некоего дифура в частных производных.
gcc 3.4.5. msvc 8.0 (2005), icc 9.1.0.28

gcc: сетка считается 23 секунды.
icc 9.1.0.28 12 секунд
icc 9.1.0.30 11 секунд
msvc 8.0 (2005) 7 секунд!!!!!!!!!!

Железо одно и то же.

Полагаю с настройками gcc по оптимизации знаком не очень. Пробовал все, что есть.

Почему интеловский так сделал? Я на интуитивном уровне считал его немеряным рулезом.
Да и реклама на интеловском сайте обещает ого-го!

мобыть интеловский косит под дурня на амд-платформе? (немного, понимаю, туманно-глупое предположение)

Если запускалось всё это на AMD, то вполне нормально, Intel делает оптимизацию именно под архитектуру Intel процессоров. А вообще не мешало бы привести ключики каждого компилятора. Иногда помогает некоторые ключики опускать когда хочется чтобы код сделанный ICC работал быстрее на AMD. Как говорится, что русскому хорошо, то немцу ... ну сами знаете

Я сравнивал таблицы таймингов по опкодам для Интела и АМД. Картина резко различается.
АМД рекомендует использовать интеловский компилятор с конкретными опциями оптимизации. Иначе может быть деградация...

Ага. Счас Intel начнёт опримизировать код под AMD. Они скорее наоборот поступят, хоть за это и иск могут схлопотать.
Мож кто-нибудь расскажет, где достать средства разработки, ориентированные под AMD? А то самого давно уже мучит проблема непредвзятого сравнения своего ПО под Intelом и AMD.

Для знакомых с английским - пару статей по теме...
http://www.swallowtail.org/naughty-intel.html
http://techreport.com/onearticle.x/8547

Для неангличан : попросту говоря, Intel не пользуется стандартными способами проверки наличия скажем поддержки SSE процессором, а в самом начале проверки способностей проца, просто смотрит есть ли процессор "GenuineIntel" и не обладающие данным достоинством процессоры отправляются в кучу и даже не анализируются на поддержу различных расширений и способностей. Хотя статьи немного староваты, не удивлюсь если "проблема" до сих пор существует и в девятых версиях компилятора.

Смотря что...

Я компилирую на Интеле, а целевой сервер - 2*2 АМД Оптерон. Так интелловский компилятор ставит раком и MSVC 6, и даже - 2005.
Что же касается критичного кода, то я его постепенно переписываю в ассемблер SSE3. Работы еще много, но меня это устраивает...

На интеле лежат несколько файлов, в частности:
W_CC_C_9.1.028.exe и W_CC_P_9.1.022.exe
W_CC и номер версии - ясно,
а кто знает за что отвечает буква: С (Р)?

Следует обратить внимание на то, что SSE2/3 работают с 8-ми байтовыми числами, а FPU, во внутреннем представлении, с 10-ти байтовыми. Следовательно, арифметические в первом случае будут больше, особенно ошибки компенсации. Так что, при решении ДУЧП к использованию SIMD команд следует подходить очень аккуратно.
А если решение принято в пользу SSE, рекомендую заглянуть на
http://www.applied-mathematics.net/miniSSEL1BLAS/miniSSEL1BLAS.html
A fast library for SDOT,DDOT,SAXPY,DAXPY operations on x86 processor

PS
>мобыть интеловский косит под дурня на амд-платформе?
Так оно и есть, особенно в "числодробилках", где в полной мере видна разница длин конвейеров AMD и Intel

Что-то я не понял. Они что же, export templates только в компиляторе под Linux реализовали, что ли? В документации на версию 9.1 явно сказано, что для Linux-версии имеется ключик -export для включения export templates, а для Windows - None. По дефолту экпорт выключен... Что-то я не догоняю.
Удалось нарыть вот такой сюрприз из буржуйного форума:
Цитата:

Currently export is only implemented on:

Comeau C++
Intel C++ (?, an undocumented switch)
Borland C++ (as yеs unreleased )

Кто-нибудь что-нибудь слышал по этому поводу?

У ICC нужно правельны ключи ставить
Например у меня на 25% быстей чем у VC2003

Нужно поставить минемальный код но приоритет на быстрые
отключить SSE, SSE2 (Это тормозит) и оставить совместимось с P3 (MMX)
и ненадо включать параллелизм (если явно его не используеш)


P.S. Выкрутыв все на максимум тока угробиш оптимизацию и вообще лучше использовать диррективы в коде