Здравствуйте, Ka3a4oK, Вы писали:
KK>Ну что значит не настроил? Во-первых, я настроил VS-компилятор, поигравшись настрйоками проекта. KK>При переключении проекта для компиляции Интел-компиялтором, подхватываются настройки от VS-проекта.
Я обычно проект под ICC пишу сразу под ICC, и настраиваю именно интеловские параметры.
KK>Если с этими настройками Интел-компилятор генерирует заметно более медленный код — это уже однозначно фэйл.
Отнюдь. Там считай почти ничего и не указано из параметров оптимизации. Более того, некоторые ключи, дающие бенефиты для cl порой лучше выключить для icl.
У ICC есть дополнительные ключи (которых нет в вижуалке, появляются в настройках после переключения проекта в "Intel режим")
KK> Во-вторых я немного поигрался настройками Интел-компилятора, мне так и не удалось научить его умум разуму.
А доку по ним читал?
KK>Разгадка проста — VS-компилятор генерирует 60 ассемблерных инструкуций KK>для самого внутреннего цикла, а Интел — 90.
Выложи .cpp и оба .cod для этого цикла
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
В огороде бузина, в Киеве дядька, а 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"
как ты думаешь, что отвечает за скорость работы сгенерированного компилятором кода?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Ka3a4oK, Вы писали:
KK>Недавно писал одну небольшую утилиту для обработки неких данных. Программа преобразует один входной бинарный поток в другой бинарный поток, попутно проводя некие вычисления над потоком(подсчет CRC). Старался добиться максимальной скорости. Скорость я считал только для внутреннего цикла, который и выполнял всю основную работу, т.е. не учитывал ввода-вывода при подсчете скорости.
KK>Несколько наблюдений:
KK>1. Подход: "сделать все на адских C++ шаблонах — компилятор потом оптимизирует" не работает, если нужно добиться максимальной скорости. Переписал на макросах — заработало заметно быстрее. Одна функция заработала быстрее на 50%.
KK>2. Просто добавление обрамляющего блок try catch в функцию main привел к снижению скорости обработки на 10%. При этом не было выкинуто или обработано хоть одно исключение.
KK>3. Попробовал скомпилировать компилятором Интел C++. Скорость работы упала(!sic) на 30%(!sic) по сравнению с программой откомпилированной С++ компилятором из Вижуал студии 2008. Есть подозрение, что Майкрософтовский компилятор генерирует простой и, при этом, короткий код, который помещается в некие внутренние структуры процессора. Компилятор Интел С++ пытается оптимизировать, раздувая код, который перестает помещаться в эти структуры. Но это только мое предположение.
Всё так и есть. Сам это наблюдал и когда то писал об этом — меня заминусовывали.
Интеловский компилятор крайне плохо переваривает шаблонный код.
Здравствуйте, Ulitka, Вы писали:
U>Здравствуйте, Ka3a4oK, Вы писали:
KK>>Я тоже сначала пытался развернуть цикл, но "свернутый" цикл работает быстрее.
U>А развернутые циклы часто в L1 cache не помещаются, а это бида (!sic)...
Трудно сказать. Там порядка 90 инструкций. Т.е. примерно ну максимум 500 байт. А L1 насколько мне известно измеряется килобайтами. Попытка развернуть хотя бы две итерации привела к замедлению.