Неожиданный результат. Соотношение gcc-4.4.4 / gcc-4.2.4 вполне согласуется с замерами на бенчмарке, и даже слегка превышает ожидания. Но что с icc? Он проигрывает не только новому gcc, но и gcc двухлетней давности!

Мы отправились за правдой к oprofile, и вот что удалось выяснить: в некоторых (достаточно редких) случаях icc испытывает проблемы с оптимизацией циклов.

С помощью профайлинга удалось обнаружить еще одну, более серьезную проблему. В отчете профайлера для версии FineReader Engine, собранной icc, на достаточно высоких позициях находилась подобная строчка:

Namespace::A::GetValue() const (На всякий случай все имена изменены на ничего не значащие)

в то время как в версии от gcc такой функции вообще не было. A::GetValue() возвращает простую структуру, содержащую несколько полей. Чаще всего этот метод вызывается для глобального константного объекта в конструкции вида

GlobalConstObject.GetValue().GetField()

которая имеет тип int. Все приведенные методы Get..() тривиальны – они просто возвращают какое-то поле объекта (по значению или ссылке). Таким образом, GetValue() возвращает объект с несколькими полями, после чего GetField() вытаскивает одно из этих полей. В этом случае вместо постоянного копирования всей структуры с целью вытащить всего одно поле, вполне возможно цепочку превратить в один вызов, возвращающий нужное число. Кроме того, все поля объекта GlobalConstObject известны (могут быть вычислены) на этапе компиляции, поэтому цепочку этих методов можно заменить на константу.

gcc так и делает(по крайней мере, он избегает лишнего конструирования), однако icc с включенными оптимизациями -O2 или -O3 оставляет все, как есть. А учитывая количество таких вызовов, это место становится критическим, хотя здесь не выполняется никакой полезной работы.

Последняя строчка – версия, собранная icc, где в самых критичных местах цепочка вызовов была заменена на константу. Как видно, это позволило версии icc работать быстрее gcc-4.2.4, но все еще медленнее gcc-4.4.4. Можно попытаться выловить все подобные критические места и вручную поправить код. Очевиден недостаток — на это уйдет огромное количество времени и сил.

При этом gcc сливает своей же старой версии и самому себе с настройками -march .., (бедные гентушники :) )

Первый график — бенчмарки. В них icc всех рвёт. Смотреть надо графики пониже.

Ты где там это увидел?

Блин, там графики в секундах. Надо было графики сортировать в порядке от лучшего к худшему, как это принято на всех сайтах.

Почему «бедные гентушники»?))Вроде всё верно, прирост есть, причем приличный)

Не инлайнит? Вот даёт!

Больше лучше.

Блин, там графики в секундах. Надо было графики сортировать в порядке от лучшего к худшему, как это принято на всех сайтах.

Надо было графики строить «больше — лучше». Если измеряется время прохождения какого-то задания, то столбики надо было построить для количества прохождений этого задания за N'ный промежуток времени.

По ссылке не ходил, ничего не читал, но, пользуясь случаем, замечу, что когда я собирал интеловским компилятором софт в своей генте, я получал отставание от gcc на 1-10% на архиваторах и проигрывателях. С тех пор я к icc отношусь с недоверием.

Процессор - core i5.

>icc в реальных приложениях сливает gcc

Тут рядом была пара тем, в которых обнаружилось обратное..

Забыл добавить «сливает на атлонах».

Отставание на проигрывателях? O_o А как оно замерялось? Или речь идёт о времени компиляции?

ложь и провокация
на bzip2 профит от icc до овер 30%
в реальных условиях!
кстати - очень зависит от архитектуры - на 32-х битной профита от icc на фоне гцц куда больше чем на 64

с icc лучше собирать архиваторы и кодеки, а не морды всякие :)

А кто может похвастать системой, которая собрана на icc?

тонко ^_^

а вдруг. Будет о чем поговорить