URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 92479
[ Назад ]
Исходное сообщение
"Сравнение производительности C++ компиляторов GCC, Clang и ICC"
Отправлено opennews , 05-Ноя-13 11:29 
Представлены (http://slashdot.org/topic/bi/speed-test-comparing-intel-c-gn.../) результаты оценки производительности компиляторов Intel C++, GNU C++ (g++) и LLVM Clang. Экспериментаторы постарались подобрать реалистичные сценарии тестирования с использованием средств распараллеливания выполнения на многоядерных системах.

Лидером по скорости процесса сборки стал Clang (в режиме полной оптимизации ICC - 6.074 сек, GCC - 2.974 сек, Clang 1.752 сек). Размер бинарного файла оказался минимален у GCC и Clang (по 8329 байт, в ICC - 20331 байт). При оценке средств для параллельного программирования, тестированию Clang мешало неготовность поддержки Cilk Plus и Threading Building Blocks. Производительность  параллельного приложения, использующего Threading Building Blocks, для ICC и GCC оказалась примерно на одном уровне 10.983 сек. и  10.510 сек. Параллельное приложение, написанное с использованием Cilk Plus, было выполнено при компиляции в ICC за 0:09.98, GCC - 0:11.28, Clang - 0:10.96.

URL: http://slashdot.org/topic/bi/speed-test-comparing-intel-c-gn.../
Новость: http://www.opennet.me/opennews/art.shtml?num=38341

Содержание
Сообщения в этом обсуждении
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Аноним , 05-Ноя-13 11:30 
Мне кажется Intel стоит приложиться для улучшения оптимизации кода для их платформ в GCC/CLang, чем дальше развивать свой компилятор
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Аноним , 05-Ноя-13 11:56 
Они продают свой компилятор. Стоит ли особо упорствовать в разработке конкурента?
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено ананим , 05-Ноя-13 12:25 
Не поверишь, они ещё и процессоры продают.
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Аноним , 05-Ноя-13 15:50 
Вообще-то интел извествен в основном продажами своих процессоров. А компилятор для них - сильно побочная хрень. Так что они известны и тем что например gcc допиливали под свои процессоры.
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено pavlinux , 05-Ноя-13 17:01 
причём насильно, заставляя майнтенеров gcc и glibc вкуячивать свой код.
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Аноним , 05-Ноя-13 19:21 
> причём насильно, заставляя майнтенеров gcc и glibc вкуячивать свой код.

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

"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено nagual , 06-Ноя-13 15:42 
> Мне кажется Intel стоит приложиться для улучшения оптимизации кода для их платформ
> в GCC/CLang, чем дальше развивать свой компилятор

А кто такой slashdot.org новый друг похороникса ? И почему новый друг похороникса забыл о сан студии ? Или о процах амд он тоже не в курсе ? Этакая скрытая реклама интела ?

"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено IMHO , 05-Ноя-13 11:32 
зачес нам скорость ? Сравните качество кода
"Сравнение производительности C++ компиляторов GCC, Clang..."
Отправлено arisu , 05-Ноя-13 14:46 
> зачес нам скорость ?

…ведь наш приветмир всё равно собирается мгновенно!

"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Аноним , 05-Ноя-13 16:28 
Какой код вы имеете ввиду?
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено IMHO , 05-Ноя-13 16:35 
машинный
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Аноним , 05-Ноя-13 11:42 
Это всё равно что сравнивать 32-битные и 64-битные приложения по размерам бинарников. Почему нет сравнения скорости работы самих приложений?
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Аноним , 05-Ноя-13 11:46 
А последние цифры - это что?
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено all_glory_to_the_hypnotoad , 05-Ноя-13 12:56 
цифр как-то мало. Я лично вижу стабильное отставание clang на процентов 10 и выше от gcc
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Аноним , 05-Ноя-13 15:27 
гугл с яблоком не хотят, чтобы вы это видели.
поэтому они очень заинтерисованы в проведении подобных сравнений с сильно подчёркнутым первенством цланга.
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено all_glory_to_the_hypnotoad , 05-Ноя-13 17:05 
гуглу то какая пичаль до шланга? В таких сравнениях заинтересованы разве что больные на голову BSDшники.
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Аноним , 05-Ноя-13 12:56 
Oh my God! Аж одна какая-то тестовая программка! Ура! Ну теперь я валю с GCC
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено all_glory_to_the_hypnotoad , 05-Ноя-13 12:57 
кстати, последние цифры это тоже скорость компиляции
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Аноним , 05-Ноя-13 16:22 
А зачем? Размер то один и внутри только единички и нули))
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено pavlinux , 05-Ноя-13 17:05 
> А зачем? Размер то один и внутри только единички и нули))

Всего то 2^64 * 8329! вариантов.  (! - факториал.)

"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Аноним , 05-Ноя-13 19:23 
> Всего то 2^64 * 8329! вариантов.  (! - факториал.)

на самом деле 2^(8*8329)!
(! - не факториал, а восклицательный знак)

"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено AlexAT , 05-Ноя-13 22:26 
Плюсую.

2^64*8329! меня сначала вогнало в ступор конкретно. Это получается число перестановок для 8329 уникальных позиций, с наличием дополнительного уникального параметра размером 64 бита, но никак не число вариантов для 8329 байт ")

"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Аноним , 05-Ноя-13 12:29 
интел по традиции в бинарник, пихает две нити кода. Одну быструю, для своих процессоров, и вторую огромную и тормозную, для всех остальных.
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено BratSinot , 05-Ноя-13 12:35 
Ну в принципе логично, так оно хотяб на остальных работать будет.
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено annulen , 05-Ноя-13 12:42 
>интел по традиции в бинарник, пихает две нити кода.

Посмотри в ассемблер, умник

"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Аноним , 05-Ноя-13 16:23 
Куда посмотреть, прости?
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено annulen , 05-Ноя-13 16:37 
> Куда посмотреть, прости?

Собери файл с -S и убедись, что там нет никакой "второй нитки"

"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено annulen , 05-Ноя-13 16:37 
>> Куда посмотреть, прости?
> Собери файл с -S и убедись, что там нет никакой "второй нити"
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Inome , 05-Ноя-13 16:41 
Тот вывод, что даёт флаг -S совершенно отличается от того, что выдает мне бинарник в дизассемблере или objdump -S ./elf. В это случаи у gcc самый лучший вывод, хотя и в нем мусора хватает.
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено pavlinux , 05-Ноя-13 17:22 
> Тот вывод, что даёт флаг -S совершенно отличается от того, что выдает

gcc -O0 -mcpu=generic  -S (и куча других -fno-* )
> мне бинарник в дизассемблере или objdump -S ./elf. В это случаи
> у gcc самый лучший вывод, хотя и в нем мусора хватает.

asm volatile( "cpuid" : "=a"(*a), "=d"(*d) : "0"(code) : "ebx", "ecx");
...

Закатать в бинарь проверку на CPU и замену syscall и библиотечных функций как два байта об асфальт.
Работу через CR регистры, которые обычные дизасмы не ловят. Самомодифицирующийся код...

"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Crazy Alex , 05-Ноя-13 17:57 
Угу. А заодно они сотрудничают с инопланетянами. Прими таблетки уже, а то паранойя больше тебя.
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено AlexAT , 05-Ноя-13 22:31 
>>> Самомодифицирующийся код...

Умер, как только появились кеши предвыборки и параллелизм/конвееры. Встречается либо в виде исключений, либо (чаще) в виде JIT, но это специфичные применения, сопровождающиеся  командами, сбрасывающими очередь исполнения при переходе на собранный участок. Накладные расходы на сие велики, и допустимы только при приличном размере собранного кода.

"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено annulen , 06-Ноя-13 20:39 
> в виде JIT

Я бы не стал называть такой код "самомодифицирующимся", так как в JIT создается новый код в отдельно замапленной области памяти, а не меняется существующий.

"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено AlexAT , 06-Ноя-13 20:45 
> Я бы не стал называть такой код "самомодифицирующимся", так как в JIT
> создается новый код в отдельно замапленной области памяти, а не меняется
> существующий.

В целом да, но есть такая категория JIT-компиляторов (pre-JIT, я бы сказал), как рекомпайлеры в эмуляторах. В таких применениях иногда действительно может модифицироваться существующая область при определенных событиях.

"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено annulen , 06-Ноя-13 20:37 
> Тот вывод, что даёт флаг -S совершенно отличается от того, что выдает
> мне бинарник в дизассемблере или objdump -S ./elf.

Естественно, у icc там подробностей больше. Что сказать-то хотел?

>В это случаи у gcc самый лучший вывод, хотя и в нем мусора хватает.

Если под "лучшим" выводом понимается отсутствие комментариев от оптимизатора, то да, лучший.

"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Аноним , 05-Ноя-13 12:54 
> Лидером по скорости процесса сборки

А мне не пофиг какая будет скорость сборки? Мне важно какой будет скорость бинарника.
До сих пор не понимаю почему все так переключись мерятся скоростью сборки, тем более когда разница на деле не так уж велика. Выглядит как маркетинг.

"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено NikolayV81 , 05-Ноя-13 13:40 
Наверное всех так отладка в проектах с большими бинарниками достала ;)
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Аноним , 05-Ноя-13 13:54 
Может лучше использовать другие инструменты для сборки или научиться самому писать makefile, а не пересобирать весь проект при изменении одного файла, в котором не меняется API.
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено NikolayV81 , 05-Ноя-13 14:22 
> Может лучше использовать другие инструменты для сборки или научиться самому писать makefile,
> а не пересобирать весь проект при изменении одного файла, в котором
> не меняется API.

Может быть не знаю, на это тоже время тратить надо ;)
p.s. Предыдуще-текущие основные компилятор + среда собирали проект (как тут люди любят говорить с набросанными на формы кнопками и гридами в количестве большем сотни ) целиком за пару десятков секунд, при полном билде, а отладка запускалась на уровне скорости открытия форточки в ос. Но он не особо правильный идеологически, при этом ничего писать не надо было. Текуще-будущий комплект делает это дольше (но не дольше чем Qt), даже для формочки с 1-й кнопкой но он ещё менее идеологически чист, и повлиять на него не представляется возможным.

"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Аноним , 05-Ноя-13 18:18 
Ну да, некогда точить, пилить надо.
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Аноним , 05-Ноя-13 19:20 
> Может быть не знаю, на это тоже время тратить надо ;)

Не тратьте времени на отладку. Вам она все равно ни к чему.

"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Аноним , 05-Ноя-13 16:31 
Проекты выросли, поэтому. В сборке того же Chromium CLang делает GCC как по времени так и по потребляемой памяти при сборке. Там больше 8 ГБ рама нужно, если ничего не путаю. С ростом проектов, разница во времени сборки и потребляемой памяти будет всё более ощутимой.
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Crazy Alex , 05-Ноя-13 18:04 
Путаешь, наверное. Во всяком случае, с 4-мя гигами рамы и полутора свопа собирается.
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено all_glory_to_the_hypnotoad , 05-Ноя-13 18:28 
память в таких проектах при сборке жрут ar и ld, особенно если собирать с отладочными данными. Именно на линкове вылетают сборки при недостаточном кол-ве ram, своп при этом не помогает.
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Crazy Alex , 05-Ноя-13 19:17 
Чего это ради он не будет помогать? Помогает, еще и как. И да, линковка - самый прожорливый этап, а если с LTO - вообще весело.
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено all_glory_to_the_hypnotoad , 05-Ноя-13 20:41 
а хз почему так. Как только rss у ar/ld доходит до предела свободной памяти сразу падает, в своп не уходит. Мб это какие-то мои локальные особенности
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Crazy Alex , 05-Ноя-13 21:33 
Наверное. Я гентушник, и у меня сборка хрома и файрфокса лечилась именно включеним свопа.
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено all_glory_to_the_hypnotoad , 06-Ноя-13 01:13 
о, я тоже. Сборка pypy валится как раз на ar/ld и своп не юзает. А с ff никогда проблем таких не было. С вебкитом такая же фигня если собирать с дебаг символами.
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Crazy Alex , 06-Ноя-13 20:33 
Звучит так, как будто свопа мало просто. pypy, помнится, отличался какими-то совсем запредельными требованиями к памяти при сборке, а если еще и опциями компилятора что-то вроде LTO накрутить - он, пожалуй, гиг десять захочет. Насчет вебкита с дебагом - мыслей нет никаких.
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено anonymous , 05-Ноя-13 13:10 
А я могу печатать со скоростью 600 знаков в минуту. Правда, такая фигня получается.
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Аноним , 05-Ноя-13 14:33 
пфф...  есть g++ и не нужно более для счастья, т.к. оптимальноидеален.
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Аноним , 05-Ноя-13 15:01 
slashdot обнаглел и редиректит с https на http, у меня из-за httpseverywhere вкладка ушла в бесконечный редирект
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Аноним , 05-Ноя-13 17:28 
Нет там никаких редиректов. Проверьте, не устраивает ли вам СОРМ MITM.
"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Anonymouse , 05-Ноя-13 15:49 
>I won’t post the code here because bla-bla-bla

Голосуй сердцем!

"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Sylvia , 05-Ноя-13 18:18 
лучше бы они соревнования по поеданию хотдогов устраивали,
3 секунды, очень показательно... ни о чём

И кто будет смотреть производительность результирующего кода? И самое главное - его стабильность ?

"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено Adblog , 06-Ноя-13 13:01 
Странные люди. Какая разница сколько компилируется, главное - каков результат. Как по мне пусть лучше сам компилятор будет тормозным, но на выходе дает быстрый код, чем наоборот ...
"Сравнение производительности C++ компиляторов GCC, Clang..."
Отправлено arisu , 06-Ноя-13 13:41 
я понял: это из-за таких, как ты, в gcc 4.8 появилась идиотская каретка, включеная по умолчанию!
"Сравнение производительности C++ компиляторов GCC, Clang..."
Отправлено Adblog , 06-Ноя-13 14:17 
> я понял: это из-за таких, как ты, в gcc 4.8 появилась идиотская
> каретка, включеная по умолчанию!

А причем тут каретка-то? Она что как-то влияет на производительность? Оо

"Сравнение производительности C++ компиляторов GCC, Clang..."
Отправлено arisu , 06-Ноя-13 14:20 
> А причем тут каретка-то?

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

"Сравнение производительности C++ компиляторов GCC, Clang..."
Отправлено Vkni , 07-Ноя-13 10:15 
Положим, со скоростью компиляции горбатого могила исправит.
"Сравнение производительности C++ компиляторов GCC, Clang..."
Отправлено arisu , 07-Ноя-13 10:21 
> Положим, со скоростью компиляции горбатого могила исправит.

а не спеши ты нас хоронить! :3

"Сравнение производительности C++ компиляторов GCC, Clang..."
Отправлено Vkni , 07-Ноя-13 21:52 
> а не спеши ты нас хоронить! :3

А не спешу, дел действительно много, но скорость, увы, не исправить.

"Сравнение производительности C++ компиляторов GCC, Clang и I..."
Отправлено freehck , 06-Ноя-13 22:59 
Прошу поклонников Шланга и GCC в целях разжигания нового холивора и тыканья пальцем, обратить внимание, что в единственном тесте, где победа осталась за Шлангом:

"Параллельное приложение, написанное с использованием Cilk Plus, было выполнено при компиляции в ICC за 9.98 сек., GCC - 11.28 сек., Clang - 10.96 сек."

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