Здравствуйте, Ka3a4oK, Вы писали:

KK>Ну что значит не настроил? Во-первых, я настроил VS-компилятор, поигравшись настрйоками проекта.
KK>При переключении проекта для компиляции Интел-компиялтором, подхватываются настройки от VS-проекта.
Я обычно проект под ICC пишу сразу под ICC, и настраиваю именно интеловские параметры.

KK>Если с этими настройками Интел-компилятор генерирует заметно более медленный код — это уже однозначно фэйл.
Отнюдь. Там считай почти ничего и не указано из параметров оптимизации. Более того, некоторые ключи, дающие бенефиты для cl порой лучше выключить для icl.
У ICC есть дополнительные ключи (которых нет в вижуалке, появляются в настройках после переключения проекта в "Intel режим")

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

KK>Разгадка проста — VS-компилятор генерирует 60 ассемблерных инструкуций
KK>для самого внутреннего цикла, а Интел — 90.
Выложи .cpp и оба .cod для этого цикла

В огороде бузина, в Киеве дядька, а C++ как всегда сливает высокоуровневым управляемым языкам по производительности.

Очередной перл воинствующего невежества от очередного .Net-программиста-гуру высокопроизводительного кода. У вас у всех свербит что-то насчет С++?

Про "вижуал генерирует простой код, а ICC — сложный, и простой код помещается в какие-то внутренние структуры процессора" особенно понравилось.

По теме: все, что ты написал полнейший нонсенс — от "неработающих" шаблонов до "замедляющего" ICC, так как многократно опровергнуто практикой на N-м числе проектов, написанных разными людьми (естественно, теми людьми, которые соображают в предмете и у которых лыжи едут).

молодец

Здравствуйте, okman, Вы писали:

KK>>2. Просто добавление обрамляющего блок try catch в функцию main привел к снижению скорости обработки на 10%. При этом не было выкинуто или обработано хоть одно исключение.
O>Потому что деструкторы объектов должны вызываться при разматывании стека.

Это не зависит от наличия try-catch блоков.

O>Эти механизмы задействуются каждый раз при входе в очередную область видимости (функция или блок),
O>отсюда и потери.

Мнэээ... вообще-то, явный код по входу в try и по выходу соответственно — это особенность так называемых sjlj-exceptions (названных так потому, что практически повторяют сишные setjmp/longjmp на буфере текущего треда). Все известные мне активно развивающиеся средства давно перешли на описание участков кода в специальных таблицах, которые используются только при размотке стека во время поиска обработчика исключения.

Вот снижение качества оптимизации из-за того, что какое-то действие не пересекло границу try-блока — да, может быть. Но чтобы в таком убедиться, надо таки смотреть в выходной ассемблер.

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, okman, Вы писали:

KK>>>2. Просто добавление обрамляющего блок try catch в функцию main привел к снижению скорости обработки на 10%. При этом не было выкинуто или обработано хоть одно исключение.
O>>Потому что деструкторы объектов должны вызываться при разматывании стека.

N>Это не зависит от наличия try-catch блоков.

O>>Эти механизмы задействуются каждый раз при входе в очередную область видимости (функция или блок),
O>>отсюда и потери.

N>Мнэээ... вообще-то, явный код по входу в try и по выходу соответственно — это особенность так называемых sjlj-exceptions (названных так потому, что практически повторяют сишные setjmp/longjmp на буфере текущего треда). Все известные мне активно развивающиеся средства давно перешли на описание участков кода в специальных таблицах, которые используются только при размотке стека во время поиска обработчика исключения.

Да, все написанное верно. Это я погорячился.
По крайней мере, в VC мне не удалось написать такой код, который бы доказывал обратное.

N>Вот снижение качества оптимизации из-за того, что какое-то действие не пересекло границу try-блока — да, может быть. Но чтобы в таком убедиться, надо таки смотреть в выходной ассемблер.

А вот такое было. Видел своими глазами в сгенерированном ассемблерном листинге.

Здравствуйте, Аноним, Вы писали:

А>В огороде бузина, в Киеве дядька, а C++ как всегда сливает высокоуровневым управляемым языкам по производительности.

А>Очередной перл воинствующего невежества от очередного .Net-программиста-гуру высокопроизводительного кода. У вас у всех свербит что-то насчет С++?

А>Про "вижуал генерирует простой код, а ICC — сложный, и простой код помещается в какие-то внутренние структуры процессора" особенно понравилось.

А>По теме: все, что ты написал полнейший нонсенс — от "неработающих" шаблонов до "замедляющего" ICC, так как многократно опровергнуто практикой на N-м числе проектов, написанных разными людьми (естественно, теми людьми, которые соображают в предмете и у которых лыжи едут).

Смайликов, по-моему, маловато. И вообще, почему анонимно ? Глаза прячешь ?

Здравствуйте, Ka3a4oK, Вы писали:

KK>Разгадка проста — VS-компилятор генерирует 60 ассемблерных инструкуций
KK>для самого внутреннего цикла, а Интел — 90.
это абсолютно ни о чём не говорит, C++ код в студию.

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, Ka3a4oK, Вы писали:

KK>>3. Попробовал скомпилировать компилятором Интел C++. Скорость работы упала(!sic) на 30%(!sic) по сравнению с программой откомпилированной С++ компилятором из Вижуал студии 2008.
CC>Очень странно. В моей практике как правило всё наоборот.

Интел сам не пишет компилятор, а использует готовый от EDG и прикручивает к нему свой оптимизатор. по крайней мере, так пишут в книжке "C++ Template Metaprogramming"

Здравствуйте, Comrade88, Вы писали:

C>Интел сам не пишет компилятор, а использует готовый от EDG и прикручивает к нему свой оптимизатор. по крайней мере, так пишут в книжке "C++ Template Metaprogramming"
как ты думаешь, что отвечает за скорость работы сгенерированного компилятором кода?

Здравствуйте, Ka3a4oK, Вы писали:

KK>Недавно писал одну небольшую утилиту для обработки неких данных. Программа преобразует один входной бинарный поток в другой бинарный поток, попутно проводя некие вычисления над потоком(подсчет CRC). Старался добиться максимальной скорости. Скорость я считал только для внутреннего цикла, который и выполнял всю основную работу, т.е. не учитывал ввода-вывода при подсчете скорости.

KK>Несколько наблюдений:

KK>1. Подход: "сделать все на адских C++ шаблонах — компилятор потом оптимизирует" не работает, если нужно добиться максимальной скорости. Переписал на макросах — заработало заметно быстрее. Одна функция заработала быстрее на 50%.

KK>2. Просто добавление обрамляющего блок try catch в функцию main привел к снижению скорости обработки на 10%. При этом не было выкинуто или обработано хоть одно исключение.

KK>3. Попробовал скомпилировать компилятором Интел C++. Скорость работы упала(!sic) на 30%(!sic) по сравнению с программой откомпилированной С++ компилятором из Вижуал студии 2008. Есть подозрение, что Майкрософтовский компилятор генерирует простой и, при этом, короткий код, который помещается в некие внутренние структуры процессора. Компилятор Интел С++ пытается оптимизировать, раздувая код, который перестает помещаться в эти структуры. Но это только мое предположение.

Всё так и есть. Сам это наблюдал и когда то писал об этом — меня заминусовывали.
Интеловский компилятор крайне плохо переваривает шаблонный код.

Здравствуйте, Ka3a4oK, Вы писали:

KK>Я тоже сначала пытался развернуть цикл, но "свернутый" цикл работает быстрее.

А развернутые циклы часто в L1 cache не помещаются, а это бида (!sic)...

Здравствуйте, Ulitka, Вы писали:

U>Здравствуйте, Ka3a4oK, Вы писали:

KK>>Я тоже сначала пытался развернуть цикл, но "свернутый" цикл работает быстрее.

U>А развернутые циклы часто в L1 cache не помещаются, а это бида (!sic)...

Трудно сказать. Там порядка 90 инструкций. Т.е. примерно ну максимум 500 байт. А L1 насколько мне известно измеряется килобайтами. Попытка развернуть хотя бы две итерации привела к замедлению.