Компиляторное внезапное

[beldmit]

Скачал триал-версию компилятора от Intel. В своё время на криптокомовском коде он давал прирост производительности раза в два (без учёта асемблерных вставок, которые шансы выравнивали). Одновременно скачал компилятор от AMD и устроил недобенчмарк на том, что под руку попалось — машинка с AMD-шным процессором и машинка с Intel ATOM. Результат меня удивил.

Во-первых, разница между icc, aocc и gcc на новом хеше оказалась пренебрежимо малой, а на Intel-овом процессоре так даже в пользу gcc. Лёша Дегтярёв в своё время код оптимизировал неплохо.

Во-вторых, по подписи AMD-шный компилятор оказался быстрее процентов на 10 (на нашей арифметике), чем gcc, на обеих архитектурах, а Intel неожиданно отстал фатально даже от gcc на AMD-шных процессорах и пришёл ноздря в ноздрю c aocc на Intel-овом.

В-третьих, по шифру (который «старый» ГОСТ) AMD-шный компилятор быстрее gcc на 12% на AMD и примерно одинаков на Intel.

В-четвёртых, AMD-шный профайлер (который CodeXL) отказался показывать мне, что за код генерит AMD-шный компилятор, что отдельно смешно.

Что с этими данными делать, я пока не знаю. Ну то есть мы кое-что учтём в политике распространения, я надеюсь. А вообще я хочу об этом поговорить, но пока не знаю, с кем.

Предыдущая запись про сравнение компиляторов.

Update: Максим Дунин убедил меня, что скорее всего это эффект нового clang по сравнению с не новым gcc, но вопрос о целесообразности компилятора от Intel, пожалуй, закрыт.

Comments

[vitus_wagner]

А clang? Почему его в сравнение не включили?

И gcc какой - свежий (8.2, 7.4) или древний?

[beldmit]

6.что-то.

[vitus_wagner]

То есть который в текущем Debian stable.
Попробуй сравни с последним, который в текущей не-LTS убунте или Debian Testing.
И с 7.3 который в текущем LTS. Не зря же они сейчас первую цифру в версии меняют.

[beldmit]

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

[vitus_wagner]

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

[nasse]

Где-то в ноябре beldmit игрался в тестинг.
Сколь я помню, не впечатлило.
Но можно еще раз попробовать.

[vitus_wagner]

Меня зато впечатлило, насколько активнее 8-я версия начала хватать программиста за руку на предмет неаккуратного кода.

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

[beldmit]

Великую чистку warning-ов я тоже планирую.

[vitus_wagner]

А я ее уже произвел. Правда, остались ворнинги в древних компиляторах - у меня самый старый из поддерживаемых дистрибутивов SLES11, там 4.3. Там не почистишь так просто, так как в составе дистрибутива идет версия bison, которая не умеет генерировать warning-free code и версия python, хидеры которой полны warning-ов.

Поэтому у меня сейчас warning free начиная с 6-й. Ну и clang тоже - у него паранойя в другую сторону.

Заодно в процессе выучил какие модификаторы форматов нужно использовать для печати size_t и прочих интересных типов, чтобы warning-ов не было ни на 32, ни на 64 битных платформах. Вот бы еще визуалковый ворнинги победить...

[rdia.livejournal.com]

У меня не получалось на gcc 5/последнем sunpro избавиться от всех предупреждений от обоих компиляторов - они просто конфликтовали между собой.

[vitus_wagner]

sunpro у меня нет. Хотя может и зря. Но у меня спарк древний и слабенький.

[nasse]

так тебенадо новый gcc, или как?

[beldmit]

Надо.

[rdia.livejournal.com]

С учётом того, как они начали поступать с UB, разработчиков GCC пустили бы на колбасу, не начни они выдавать больше предупреждений. Так это хоть чуть-чуть морально компенсирует поведение в стиле "программист не должен делать ошибок".