The OpenNET Project / Index page

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

Сравнение производительности GCC, LLVM-GCC, DragonEgg, Clang

08.11.2010 17:29

Ресурс Phoronix представил результаты тестирования производительности GCC (4.2.1, 4.3.0, 4.4.0, 4.5.1, 4.6-20101030) и основанных на LLVM 2.8 проектов LLVM-GCC, DragonEgg и Clang. По сравнению с GCC проекты на основе LLVM показали более высокую скорость компиляции, оказавшись впереди в оценивающих скорость сборки тестах (сборка apache и ImageMagic).

В 8 тестах (Apache benchmark, Gcrypt, OpenSSL, Himeno, MAFFT, 7-Zip, LAME MP3, x264), оценивающих производительность различных приложений, расхождения в показателях были незначительными, хотя собранный в GCC код как правило продемонстрировал немного более высокую скорость работы. Значительный провал в производительности Clang и LLVM-GCC наблюдался в тестах John The Ripper Blowfish (отставание 40%), HMMer (10-18%), GraphicsMagick (20-50%). В тесте C-Ray Clang и LLVM-GCC оказались быстрее GCC на 10-20%.

  1. Главная ссылка к новости (http://www.phoronix.com/scan.p...)
  2. OpenNews: Релиз GCC-плагина DragonEgg 2.8
  3. OpenNews: Новая версия набора компиляторов LLVM 2.8
  4. OpenNews: Библиотека Qt успешно собрана компилятором Clang
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/28569-gcc
Ключевые слова: gcc, llvm, test, benchmark
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (49) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 17:48, 08/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Бессмысленный тест. Тут главное не скорость компиляции, а качество полученного кода и качество поддержки спецификаций языка.
    Лучше бы они попробовали этими компиляторами собрать скажем debian репозиторий и написали сколько пакетов завалилось.
     
     
  • 2.3, pavlinux (ok), 17:56, 08/11/2010 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Читаем снова:

    >хотя собранный в GCC код как правило продемонстрировал немного более высокую скорость
    > работы. Значительный провал в производительности Clang и LLVM-GCC наблюдался в тестах
    > John The Ripper Blowfish (отставание 40%), HMMer (10-18%), GraphicsMagick (20-50%).
    > В тесте C-Ray Clang и LLVM-GCC оказались быстрее GCC на 10-20%.
     
     
  • 3.5, Аноним (1), 18:32, 08/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Читаем снова:

    >качество поддержки спецификаций языка.
    >Лучше бы они попробовали этими компиляторами собрать скажем debian репозиторий и написали сколько пакетов завалилось.

     
     
  • 4.7, simpler (?), 19:51, 08/11/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да уж. Лишнее подтверждение тому, что большинство потребителей сделанного кем-то для них ПО ни о чем кроме скорости думать не могут.

    И даже когда прочитают, просто ничего друго не воспринимают. И не могут себе представить, как можно о чем-то, кроме скорости, думать.

     
     
  • 5.10, User294 (ok), 21:51, 08/11/2010 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Да, давайте подумаем еще о чем-нибудь. Например, о том что некоторые тесты вообще шлангом не собрались (точнее, если уж не собирается  то как правило всеми LLVM-based сразу). О чем в новости почему-то стыдливенько заскипано. Среди не скомпилившихся шлангом тестов кроме всего прочего был и x264, например. Очень уж это все напоминает "зато мы делаем ракеты и перекрыли Енисей" в свете недавних трублений про сборку ядра линуха :). Ради справедливости замечу что девеловской веткой гцц x264 тоже не собрался, но там хотя-бы честно указано что оно девел ;)

    Также как-то стыдливо заскипан аццкий слив, местами почти в три (!!!) раза в графикc магике. Интересно, как получается "20-50% отставание" при 53 попугаях максимум у LLVM-based vs 138 попугаев у GCC? Ну ладно, пусть 131 попугае - для последней релизной версии гцц. Ну-ка расскажите, математики, это как? Автору новости 2 балла - за неумение пользоваться калькулятором, или того хуже "гетзефаксы".

     
     
  • 6.12, cdome (ok), 22:10, 08/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ну со сливом в ImageMagic то же понятно. LLVM до сих пор не поддерживает OpenMP, который во всю использует ImageMagic
     
  • 6.13, cdome (ok), 22:19, 08/11/2010 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Единственное, что привлекло мое внимание в этом тесте,  так это Himeno Benchmark. Когда на интеле gcc и clang идут практически вровень, но на AMD Opteron - clang в два раза быстрее gcc и вообще быстрее core i7.
    Не происки ли это инженеров интела, которые сейчас занимаются gcc в плотную. Надо попробывать повторить и зафайлить баг репорт в gcc.

     
  • 6.14, simpler (?), 22:31, 08/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Да, давайте подумаем еще о чем-нибудь.

    Ну хотя бы уже что-то.

    > Например, о том что некоторые тесты вообще шлангом не собрались (точнее, если уж не собирается  то как правило всеми LLVM-based сразу).

    Т.е. вы хотите, чтобы clang сразу моментально был похож на gcc один в один.
    Не смотря на общую динамику развития.

    Просто разработчики сосредоточились на выявлении конкретных несовместимостей при сборке конкретного ПО. А не просто на тестах ради тестов.

    Кроме того, те фичи, допустим в Линукс-ядре, которые собираются ценой уродства архитектуры gcc - можно выкинуть из самого (например) Линукса, а не пытаться портить новый компилятор ради поддержки дурных решений.

    Просто многоие поклонники этих gcc-ориентированных убогостей из-за шаблонности своего мышления не догадываются, что у разработчиков компиляторов всегда есть такой ход, как не поддерживать те фичи, которые им не нравятся. Что неминуемо повлечет за собой переделку самого софта, который подобные угробищные фичи поддерживает. А вовсе не допиливания самого компилятора в целях соответствия какому-то очередному убожетсву.

     
     
  • 7.15, ананим (?), 22:55, 08/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Кроме того, те фичи, допустим в Линукс-ядре, которые собираются ценой уродства архитектуры gcc - можно выкинуть из самого (например) Линукса, а не пытаться портить новый компилятор ради поддержки дурных решений.

    опа. тонкий намёк на "правьте свой линух под шланг".
    а оно кому нужно то?

     
     
  • 8.19, simpler (?), 23:22, 08/11/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    То есть вы только сейчас поняли, что такой вариант возможен и даже более вероят... текст свёрнут, показать
     
     
  • 9.21, ананим (?), 01:27, 09/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    неа не понял D вот когда весь будет собираться, тогда смело напишем - собирае... текст свёрнут, показать
     
     
  • 10.22, ананим (?), 01:30, 09/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    зы во фантазёр прям аш зависть берёт D всё завтра сношу линух и ставлю оси... текст свёрнут, показать
     
     
  • 11.39, анонимус (??), 21:06, 09/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Вообще, правильные вещи говорит человек Нефига писать непереносимый код Левые ... текст свёрнут, показать
     
     
  • 12.41, simpler (?), 22:52, 09/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Я вообще-то как раз переносинмость саму по себе в виду не имел Поскольку перено... текст свёрнут, показать
     
     
  • 13.43, pavel_simple (ok), 23:20, 09/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    ты считал в каком месте бОльшая ... текст свёрнут, показать
     
     
  • 14.44, simpler (?), 23:51, 09/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    http www opennet ru opennews art shtml num 28418 Я не считал Может даже и не ... текст свёрнут, показать
     
     
  • 15.45, pavel_simple (ok), 16:18, 10/11/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    так и запишем -- фантазёр... текст свёрнут, показать
     
     
  • 16.46, simpler (?), 03:38, 11/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Так и запишем - для вас важнее количество строк кода и показатели скорости, неже... текст свёрнут, показать
     
     
  • 17.47, pavel_simple (ok), 07:05, 11/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    для меня важно -- чтобы всякие мимопролетающие трололо сливали за пизд Wничем не... текст свёрнут, показать
     
     
  • 18.48, simpler (?), 10:41, 11/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ну конечно По-вашему получается, что содержимое всех новостей о си-ланге - тоже... текст свёрнут, показать
     
  • 7.26, Аноним (1), 04:48, 09/11/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >уродства архитектуры gcc
    >gcc-ориентированных убогостей
    >подобные угробищные фичи поддерживает.
    >соответствия какому-то очередному убожетсву.

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

     
     
  • 8.27, simpler (?), 05:17, 09/11/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    То, что вам нечего возразить - это понятно Собственную адекватность вы считаете... текст свёрнут, показать
     
     
  • 9.34, Unforgiven (??), 14:43, 09/11/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Человек адекватен, если не доказано обратное Своим постом вы доказали свою неад... текст свёрнут, показать
     
     
  • 10.36, simpler (?), 16:40, 09/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Тем, кому в свое время с большим трудом удалось чему-то с грехом пополам научить... текст свёрнут, показать
     
  • 7.31, User294 (ok), 14:27, 09/11/2010 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Ну, вообще, я почему-то нескромно считаю что если проводится бенчмарк - было бы ... большой текст свёрнут, показать
     
     
  • 8.35, simpler (?), 16:27, 09/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А в моем понимании в подобных вопросах надо смотреть на качество конкретного код... большой текст свёрнут, показать
     
     
  • 9.40, User294 (ok), 22:45, 09/11/2010 [^] [^^] [^^^] [ответить]  
  • –4 +/
    А четкие критерии качества - можно в студию Кстати да, для кодека требование ... большой текст свёрнут, показать
     
     
  • 10.42, simpler (?), 23:12, 09/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Сюдя по всему, вы все-таки осознали реальность того, что под clang начнут собира... текст свёрнут, показать
     

  • 1.2, Иван Иванович Иванов (?), 17:50, 08/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    GCC 4.6.x заруливает - Intel'ы не зря старались.
     
  • 1.4, Аноним (-), 18:04, 08/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    >7-Zip, LAME MP3, x264
    >расхождения в показателях были незначительны

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

     
     
  • 2.11, User294 (ok), 21:55, 08/11/2010 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Для начала - x264 вообще LLVM-based не собрался. Сравнения вообще не вышло. А мерять компилятор на них вполне можно - кроме асмовых вставок роялит все-таки и остальной код. Меньше, но все-таки. Сами понимаете - весь H.264 на гольном асме выписывать вы "немного" устанете :)
     

  • 1.6, анон (?), 18:42, 08/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В заголовке туманно улавливается ...Phoronix... В теле новости: и правда - он. :)
     
     
  • 2.8, Толстый (ok), 20:29, 08/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    в чем проблема, проведи и опубликуй свои тесты лучше них, анон.
     
  • 2.16, User294 (ok), 23:16, 08/11/2010 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Ну, фороникс. А чем их набор тестов плох в данном случае? И, наверное, вы тогда можете предложить какие-то тесты лучше?
     
     
  • 3.18, Кодир (?), 23:21, 08/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Просто Фороникс что-то типа Радуловой - пёрнет в лужу, а потом тысячи леммингов обсуждают. Тесты прежде всего должны быть профессиональными, подтверждёнными сотнями программеров. А просто вылезти из болота и посчитать факториал - это любой м__к может!
     
  • 3.20, Sylvia (ok), 00:24, 09/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    то что они сделали тесты - хорошо, но плохо что они берут .0 версии компиляторов,
    нужно брать текущие релизы в каждой ветке - 4.1.2 , 4.2.4 , 4.3.5 , 4.4.5 , 4.5.1, последний снапшот 4.6.0-prerelease

    если комментировать результаты , то странно что они все LLVM записали в одну кучу
    по времени сборки apache у них dragonegg оказался быстрее GCC 4.5.0 , на котором он собственно как плагин и работает, у меня получалось что медленнее

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

     
     
  • 4.25, Sylvia (ok), 02:43, 09/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    у меня вот что получилось по диаграмме на 7 странице (сборка Apache на время):

    Apache 2.2.17 ./configure --with-included-apr
    Gentoo ~x86, Core2Duo 3.00 Ghz


    GCC 4.1.2-27 REDHAT
    real    0m30.206s
    user    0m40.791s
    sys     0m5.012s

    GCC 4.2.4
    real    0m32.142s
    user    0m44.680s
    sys     0m4.634s


    GCC 4.3.5
    real    0m31.798s
    user    0m43.355s
    sys     0m4.993s

    GCC 4.4.5
    real    0m32.667s
    user    0m44.385s
    sys     0m5.178s

    GCC 4.5.2-pre20101105
    real    0m34.554s
    user    0m47.673s
    sys     0m5.210s

    GCC 4.6-prerelease-20101007
    real    0m46.991s
    user    1m8.754s
    sys     0m5.250s

    Intel C v11.1
    real    0m31.523s
    user    0m40.798s
    sys     0m6.867s

    clang 2.8
    real    0m27.711s
    user    0m36.800s
    sys     0m4.584s

    llvm-gcc (llvm 2.8)
    real    0m29.369s
    user    0m39.399s
    sys     0m5.179s

    dragonegg 2.8 @ GCC 4.5.2-pre20101105
    real    0m30.172s
    user    0m39.898s
    sys     0m5.792s

    хотела опровергнуть вороникс ) а получилось практически также

     
     
  • 5.33, User294 (ok), 14:40, 09/11/2010 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Попробую угадать: у вас наверное гента или что-то подобное. Потому что только гентушников время компиляции волнует больше чем все остальные параметры компилера, типа качества кодогенерации.
     
     
  • 6.37, Sylvia (ok), 17:31, 09/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    в плане дистрибутива угадали,
    но волнует не столько скорость сборки, сколько отношение скорости сборки к получаемой производительности скомпилированой программы, если компилятор скушал на 40% больше времени при сборке, а код получился такой же по скорости, то "зачем платить больше, если не видно разницы ?" (tm)

     
     
  • 7.38, Sylvia (ok), 17:35, 09/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    PS: по производительности получаемого кода тесты в целом сложнее,
    тут с флагами стоит поразбираться, учесть возможную нестабильность в случае экстремальных флажков, наличие inline asm оптимизаций и много чего еще, Clang же в общем случае вполне уже наступает GCC на пятки ;)
     

  • 1.9, Zenitur (?), 20:32, 08/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А где же компилятор от Intel? Да, он несвободен - но всё же он один такой, можно было бы и протестировать.
     
     
  • 2.23, анонимус (??), 01:41, 09/11/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Почему один ? Есть еще pathscaleовский path64, который только недавно стал свободным. Кстати, по некоторым вещам здорово уделывает icc.
     

  • 1.17, Kodir (?), 23:19, 08/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Какова бы ни была скорость, ставку надо делать на ИЗНАЧАЛЬНО ПРОДУМАННЫЙ llvm. Впоследствии все гццшные трюки можно точно так же перенести в clang, так что проблем со скоростью не будет.
    Надо уметь отметать старое, пока старое как снежный ком не смяло вас самих (см. историю Линукс).
     
     
  • 2.24, ананим (?), 01:52, 09/11/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    вот-вот! даёшь релиз gcc 4.6!
     

  • 1.28, Аноним (-), 09:30, 09/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    не нашел какие были оптимизации

    А в реальности надо просто убрать С/С++ (с его инклудами и разделением на заголовок и реализацию) и заменить на более быстрый для компиляции язык более подверженный оптимизации.

     
  • 1.29, Аноним (-), 09:40, 09/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    дополнение. И переписать на новый язык Фришку и Линукс
     
  • 1.30, cdome (ok), 10:34, 09/11/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Люди!

    Кто пользуеться LLVM, скажите как у него с поддержкой Windows?

     
     
  • 2.32, Аноним (-), 14:37, 09/11/2010 [^] [^^] [^^^] [ответить]  
  • +/
    o_O

    а у GCC как с поддержкой виндоус? Только не надо всякие cygwin, mingw и т.д.

     
     
  • 3.50, анонимус (??), 19:34, 17/02/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Чем mingw не угодил? Всяк уж получше MSVC по качеству компиляции.
     

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



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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