Russian Qt Forum

На днях осознал странную вещь - приложение на основе libsamplerate, скомпилированное с использованием Intel C++ Compiler 12 стало работать на 30% медленнее, чем оно же, собраннное ICC 9  c теми же опциями. Решил поисследовать и получил, что с каждой новой версией ICC (10, 11, 12) приложение становилось медленнее примерно 10%. Кроме того, MSVC 2010 отстаёт всего на 2% от ICC 9, тогда как MSVC 2008 проигрывал в своё время процентов 15. Что бы это могло значить?

"Медленнее" что? Просто некое приложение или приложение с интенсивным openMP (поэтому я использую icc для одного проекта). И на какой платформе?

Платформа Win7 x64, приложение и dll - x32. Приложение тестовое (ресемплит достаточно большой wav файл с 48 kHz до 7,2 kHz) -просто обёртка над dll libsamplerate, собранной с помощью ICC. OpenMP не использовал, где именно внутри dll стало медленнее - пристально не разбирался, просто захотелось оценить эффективность новых компиляторов. И вот оценил - стало на 30% менее эффективно.

2 xokc А процессор на целевой машине какой AMD или Intel?

Ну Intel, конечно :). Если точнее, то Core 2 Duo. В понедельник на Core i7 посмотрю.

Тогда есть такое предположение... с интеловскими компиляторами дел никогда не имел....
При сборке указывается модель целевого процессора?
Возможно каждая новая версия компилятора принимает в качестве модели по умолчанию все более новые процессоры и соответственно пытается оптимизировать код под них, а на младших моделях процессоров это приводит к тормозам.

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

Попробуй указать одну модель процессора при компиляции каждой из версий и сравнить их.

А в чём смысл-то таких сравнений? Я же говорил, что принудительная установка типа целевого процессора статистически значимых изменений производительности не даёт. Кроме того, мне необходимо, чтобы код был быстрым на любых современных Intel CPU.

Вопрос конечно интересный, но не лучше ли задать его на форуме Intel?

(В случае чего скажете что сравнивали trial - ну это если спросят  :))

У них есть адекватный рускоязычный форум? В плане английского я немой - читаю легко, с письмом - напряг.

Боюсь на 9 версию ICC срок trial вышел ещё пару лет назад.

Ну как бэ пытаемся разобраться...
Если один и тот же код собранный для одной и той-же модели процессора разными версиями компилятора даст разный результат, то тут будет повод задуматься и обратиться за комментариями на тот же форум Интела.

Вроде раньше его можно было скачать свободно с их сайта, или это специальная версия какая была.

Ну это бы уже совсем клиника была бы. Попробую, если руки дойдут.

Ну так что, у Вас не остался старый билд?

Русскоязычный есть, но там "пустовато". Поэтому

Назовите как нибудь напр "Building libsamplerate with icc (performance problem)" - не надо говорить компилятор плохой и.т.п.

запостил: hччp://software.intel.com/en-us/forums/showthread.php?t=86271
Но там с активностью тоже не очень.

надо не только указать модель процессора но и поддерживаемый набор инструкций. SSE *.* хотя по опыту использования все зависит от кода. есть библиотеки которые после компилирования интеловским компилятором реально становились медленее (по сравнению с MS VS 2008)... где в таком случае искать грабли не известно...

Прошу меня правильно понять - Ваш пост могут читать люди которые никогда не пользовались icc, и у них может сложиться впечатление что это кал. По личному опыту могу сказать что "в общем и целом" icc заметно впереди gcc, хотя заморочек с интеграцией хватает. А если копнуть multi-threading, то gcc проигрывает с разгромным счетом (Аргентина-Ямайка 12:0)

Прошу меня правильно понять - Ваш пост могут читать люди которые никогда не пользовались gcc, и у них может сложиться впечатление что это кал. Бла-бла-бла... А если копнуть multi-threading, то бла-бла (Аргентина-Ямайка 12:0).

Где тесты, где цифры? :)

BRE чего завелись-то? :)  Используете icc - обсудим (если будете вести себя прилично), а нет - так о чем речь?  И много ли здесь кто никогда не работал с gcc? Думается что нет

А что обсуждать, я не пользуюсь. Под мой Phenom он компилирует хуже чем gcc (почему-то :) )

Судя по нашим постам (kind_shubin. твоему и моему), мы просто собрались почесать языками и обменяться своими субъективными мнениями. Так что я не завелся, а высказал свое мнение, так же как и ты. ;)

В этом нет ничего плохого, если (как и все) оно в меру. Далеко не всегда мне нужен icc, но для интенсивных расчетов - да. "Просто" прирост 15-20% - ну не то чтобы уж офигеть, но приятно. А вот если "разпоточить" - то намного больше, если операции (кластеры) не так уж велики. Реализация omp намного лучше, гибче, больше директив. Покажите мне нормальный/профессиональный атомарный лок на gcc - мне такой неизвестен. На intel - наливай и пей. Какая-то либа стала тормозить с очередной версией? Вполне возможно, спрашивайте производителей, это их проблемы. А вот так охаять "потому что мне не дали эту цацку" - ума много не надо  :)

Кого спрашивать-то? Интел или авторов библиотеки?