The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Сравнение производительности C++ компиляторов GCC, Clang и ICC

05.11.2013 11:05

Представлены результаты оценки производительности компиляторов 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 оказалась примерно на одном уровне (ICC - тестовая программа выполнилась за 10.98 сек., GCC - 10.51 сек). Параллельное приложение, написанное с использованием Cilk Plus, было выполнено при компиляции в ICC за 9.98 сек., GCC - 11.28 сек., Clang - 10.96 сек.

  1. Главная ссылка к новости (http://slashdot.org/topic/bi/s...)
  2. OpenNews: Сравнение производительности GCC и Clang во FreeBSD 9.1
  3. OpenNews: Тестирование современных версий Clang и GCC
  4. OpenNews: Оценка производительности Clang/LLVM и GCC при сборке во FreeBSD 10.0-CURRENT
  5. OpenNews: Сравнение производительности GCC и LLVM-Clang
  6. OpenNews: Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang
Лицензия: CC-BY
Тип: Обобщение
Ключевые слова: gcc, clang, icc
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (63) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.2, Аноним (-), 11:30, 05/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Мне кажется Intel стоит приложиться для улучшения оптимизации кода для их платформ в GCC/CLang, чем дальше развивать свой компилятор
     
     
  • 2.7, Аноним (-), 11:56, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Они продают свой компилятор. Стоит ли особо упорствовать в разработке конкурента?
     
     
  • 3.9, ананим (?), 12:25, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не поверишь, они ещё и процессоры продают.
     
  • 3.26, Аноним (-), 15:50, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вообще-то интел извествен в основном продажами своих процессоров. А компилятор для них - сильно побочная хрень. Так что они известны и тем что например gcc допиливали под свои процессоры.
     
     
  • 4.35, pavlinux (ok), 17:01, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • –3 +/
    причём насильно, заставляя майнтенеров gcc и glibc вкуячивать свой код.
     
     
  • 5.47, Аноним (-), 19:21, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > причём насильно, заставляя майнтенеров gcc и glibc вкуячивать свой код.

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

     
  • 2.58, nagual (ok), 15:42, 06/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Мне кажется Intel стоит приложиться для улучшения оптимизации кода для их платформ
    > в GCC/CLang, чем дальше развивать свой компилятор

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

     

  • 1.3, IMHO (?), 11:32, 05/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    зачес нам скорость ? Сравните качество кода
     
     
  • 2.22, arisu (ok), 14:46, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > зачес нам скорость ?

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

     
  • 2.29, Аноним (-), 16:28, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Какой код вы имеете ввиду?
     
     
  • 3.31, IMHO (?), 16:35, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    машинный
     

  • 1.4, Аноним (-), 11:42, 05/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Это всё равно что сравнивать 32-битные и 64-битные приложения по размерам бинарников. Почему нет сравнения скорости работы самих приложений?
     
     
  • 2.6, Аноним (-), 11:46, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    А последние цифры - это что?
     
     
  • 3.14, all_glory_to_the_hypnotoad (ok), 12:56, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    цифр как-то мало. Я лично вижу стабильное отставание clang на процентов 10 и выше от gcc
     
     
  • 4.24, Аноним (-), 15:27, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    гугл с яблоком не хотят, чтобы вы это видели.
    поэтому они очень заинтерисованы в проведении подобных сравнений с сильно подчёркнутым первенством цланга.
     
     
  • 5.37, all_glory_to_the_hypnotoad (ok), 17:05, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    гуглу то какая пичаль до шланга? В таких сравнениях заинтересованы разве что больные на голову BSDшники.
     
  • 3.15, Аноним (-), 12:56, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Oh my God! Аж одна какая-то тестовая программка! Ура! Ну теперь я валю с GCC
     
  • 3.16, all_glory_to_the_hypnotoad (ok), 12:57, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    кстати, последние цифры это тоже скорость компиляции
     
  • 2.27, Аноним (-), 16:22, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А зачем? Размер то один и внутри только единички и нули))
     
     
  • 3.36, pavlinux (ok), 17:05, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > А зачем? Размер то один и внутри только единички и нули))

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

     
     
  • 4.48, Аноним (-), 19:23, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Всего то 2^64 * 8329! вариантов.  (! - факториал.)

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

     
     
  • 5.51, AlexAT (ok), 22:26, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Плюсую.

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

     

  • 1.10, Аноним (10), 12:29, 05/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +8 +/
    интел по традиции в бинарник, пихает две нити кода. Одну быструю, для своих процессоров, и вторую огромную и тормозную, для всех остальных.
     
     
  • 2.11, BratSinot (ok), 12:35, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Ну в принципе логично, так оно хотяб на остальных работать будет.
     
  • 2.12, annulen (ok), 12:42, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >интел по традиции в бинарник, пихает две нити кода.

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

     
     
  • 3.28, Аноним (-), 16:23, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Куда посмотреть, прости?
     
     
  • 4.32, annulen (ok), 16:37, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Куда посмотреть, прости?

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

     
     
  • 5.33, annulen (ok), 16:37, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Куда посмотреть, прости?
    > Собери файл с -S и убедись, что там нет никакой "второй нити"
     
  • 5.34, Inome (ok), 16:41, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Тот вывод, что даёт флаг -S совершенно отличается от того, что выдает мне бинарник в дизассемблере или objdump -S ./elf. В это случаи у gcc самый лучший вывод, хотя и в нем мусора хватает.
     
     
  • 6.38, pavlinux (ok), 17:22, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Тот вывод, что даёт флаг -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 регистры, которые обычные дизасмы не ловят. Самомодифицирующийся код...

     
     
  • 7.40, Crazy Alex (ok), 17:57, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Угу. А заодно они сотрудничают с инопланетянами. Прими таблетки уже, а то паранойя больше тебя.
     
  • 7.52, AlexAT (ok), 22:31, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>> Самомодифицирующийся код...

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

     
     
  • 8.61, annulen (ok), 20:39, 06/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Я бы не стал называть такой код самомодифицирующимся , так как в JIT создается ... текст свёрнут, показать
     
     
  • 9.62, AlexAT (ok), 20:45, 06/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    В целом да, но есть такая категория JIT-компиляторов pre-JIT, я бы сказал , как... текст свёрнут, показать
     
  • 6.60, annulen (ok), 20:37, 06/11/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Тот вывод, что даёт флаг -S совершенно отличается от того, что выдает
    > мне бинарник в дизассемблере или objdump -S ./elf.

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

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

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

     

  • 1.13, Аноним (-), 12:54, 05/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    > Лидером по скорости процесса сборки

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

     
     
  • 2.18, NikolayV81 (ok), 13:40, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Наверное всех так отладка в проектах с большими бинарниками достала ;)
     
     
  • 3.19, Аноним (-), 13:54, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Может лучше использовать другие инструменты для сборки или научиться самому писать makefile, а не пересобирать весь проект при изменении одного файла, в котором не меняется API.
     
     
  • 4.20, NikolayV81 (ok), 14:22, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Может лучше использовать другие инструменты для сборки или научиться самому писать makefile,
    > а не пересобирать весь проект при изменении одного файла, в котором
    > не меняется API.

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

     
     
  • 5.43, Аноним (43), 18:18, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Ну да, некогда точить, пилить надо.
     
  • 5.46, Аноним (-), 19:20, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Может быть не знаю, на это тоже время тратить надо ;)

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

     
  • 2.30, Аноним (-), 16:31, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Проекты выросли, поэтому. В сборке того же Chromium CLang делает GCC как по времени так и по потребляемой памяти при сборке. Там больше 8 ГБ рама нужно, если ничего не путаю. С ростом проектов, разница во времени сборки и потребляемой памяти будет всё более ощутимой.
     
     
  • 3.41, Crazy Alex (ok), 18:04, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Путаешь, наверное. Во всяком случае, с 4-мя гигами рамы и полутора свопа собирается.
     
  • 3.44, all_glory_to_the_hypnotoad (ok), 18:28, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    память в таких проектах при сборке жрут ar и ld, особенно если собирать с отладочными данными. Именно на линкове вылетают сборки при недостаточном кол-ве ram, своп при этом не помогает.
     
     
  • 4.45, Crazy Alex (ok), 19:17, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Чего это ради он не будет помогать? Помогает, еще и как. И да, линковка - самый прожорливый этап, а если с LTO - вообще весело.
     
     
  • 5.49, all_glory_to_the_hypnotoad (ok), 20:41, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    а хз почему так. Как только rss у ar/ld доходит до предела свободной памяти сразу падает, в своп не уходит. Мб это какие-то мои локальные особенности
     
     
  • 6.50, Crazy Alex (ok), 21:33, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Наверное. Я гентушник, и у меня сборка хрома и файрфокса лечилась именно включеним свопа.
     
     
  • 7.53, all_glory_to_the_hypnotoad (ok), 01:13, 06/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    о, я тоже. Сборка pypy валится как раз на ar/ld и своп не юзает. А с ff никогда проблем таких не было. С вебкитом такая же фигня если собирать с дебаг символами.
     
     
  • 8.59, Crazy Alex (ok), 20:33, 06/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Звучит так, как будто свопа мало просто pypy, помнится, отличался какими-то сов... текст свёрнут, показать
     

  • 1.17, anonymous (??), 13:10, 05/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    А я могу печатать со скоростью 600 знаков в минуту. Правда, такая фигня получается.
     
  • 1.21, Аноним (-), 14:33, 05/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    пфф...  есть g++ и не нужно более для счастья, т.к. оптимальноидеален.
     
  • 1.23, Аноним (-), 15:01, 05/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    slashdot обнаглел и редиректит с https на http, у меня из-за httpseverywhere вкладка ушла в бесконечный редирект
     
     
  • 2.39, Аноним (-), 17:28, 05/11/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Нет там никаких редиректов. Проверьте, не устраивает ли вам СОРМ MITM.
     

  • 1.25, Anonymouse (?), 15:49, 05/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    >I won’t post the code here because bla-bla-bla

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

     
  • 1.42, Sylvia (ok), 18:18, 05/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    лучше бы они соревнования по поеданию хотдогов устраивали,
    3 секунды, очень показательно... ни о чём

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

     
  • 1.54, Adblog (ok), 13:01, 06/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Странные люди. Какая разница сколько компилируется, главное - каков результат. Как по мне пусть лучше сам компилятор будет тормозным, но на выходе дает быстрый код, чем наоборот ...
     
     
  • 2.55, arisu (ok), 13:41, 06/11/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    я понял: это из-за таких, как ты, в gcc 4.8 появилась идиотская каретка, включеная по умолчанию!
     
     
  • 3.56, Adblog (ok), 14:17, 06/11/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > я понял: это из-за таких, как ты, в gcc 4.8 появилась идиотская
    > каретка, включеная по умолчанию!

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

     
     
  • 4.57, arisu (ok), 14:20, 06/11/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > А причем тут каретка-то?

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

     
     
  • 5.64, Vkni (ok), 10:15, 07/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Положим, со скоростью компиляции горбатого могила исправит.
     
     
  • 6.65, arisu (ok), 10:21, 07/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Положим, со скоростью компиляции горбатого могила исправит.

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

     
     
  • 7.66, Vkni (ok), 21:52, 07/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > а не спеши ты нас хоронить! :3

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

     

  • 1.63, freehck (ok), 22:59, 06/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Прошу поклонников Шланга и GCC в целях разжигания нового холивора и тыканья пальцем, обратить внимание, что в единственном тесте, где победа осталась за Шлангом:

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

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

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    MIRhosting
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру