The OpenNET Project / Index page

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

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

21.04.2010 10:37

Экспериментаторы с ресурса Phoronix дополнили опубликованное в понедельник сравнение производительности компиляторов GCC (4.3, 4.4, 4.5) и опубликовали более полный отчет, в котором отражены результаты измерения производительности Clang и LLVM-GCC. Напомню, что в рамках проекта LLVM ведется разработка GCC совместимого инструментария (компиляторы, оптимизаторы и генераторы кода), компилирующего программы в промежуточный байткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизации). Сгенерированный платформонезависимый псевдокод может быть преобразован при помощи JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы.

Результаты тестирования:

  • Тесты на время сборки: LLVM-GCC и Clang выполнили операцию сборки Apache на 20% быстрее GCC. Сборка PHP была выполнена LLVM-GCC на 25% быстрее, но при использовании Clang возникли проблемы со сборкой. При сборке ImageMagic проблемы с компиляцией возникли в LLVM-GCC, а Clang завершил процесс сборки на несколько процентов медленнее GCC.
  • При измерении производительности Apache, собранного разными компиляторами, производительность LLVM-GCC оказалась примерно на уровне GCC, но clang-сборка продемонстрировала повышение производительности на 9%.
  • При измерении скорости сжатия утилитой 7-zip, clang показал результаты на уровне GCC, а LLVM-GCC продемонстрировал десятикратный провал производительности. При кодировании MP3 паком LAME, Clang оказался медленнее GCC на 12%, а LLVM-GCC медленнее на 7%.
  • Скорость прохождения тестов Gcrypt и C-Ray оказалась примерно одинаковой для GCC и LLVM-GCC. Clang не смог выполнить тест Gcrypt и оказался на 4% медленее в тесте C-Ray;
  • В тесте BYTE Unix Benchmark (Dhrystone 2) возможности LLVM-GCC и Clang проявились в полной мере: LLVM-GCC обогнал GCC на 43%, а Clang на 28%.
  • В тесте GraphicsMagick Clang отстал от GCC на 18%, а LLVM-GCC наоборот обогнал GCC на 8%;
  • В тесте Himeno LLVM-GCC оказался на уровне GCC, а Clang отстал на 60%.
  • В тесте John The Ripper LLVM-GCC отстал от GCC на 60%, а Clang вообще не смог выполнить тест;
  • В тесте HMMer LLVM-GCC и Clang оказались на 23% медленнее GCC.

В целом LLVM / Clang не оправдали возложенные на них ожидания, но эти проекты находятся в активной стадии разработки и не исключено, что уже в ближайшем будущем ситуация может кардинально измениться. Постепенно открытые проекты начинают обращать внимание на Clang и тестировать свой код на совместимость, например большая работа в направлении улучшения поддержки и выявления ошибок ведется в настоящее время разработчиками FreeBSD, которым уже удалось добиться полной пересборки ядра, базовой системы и большого числа популярных портов.

Также отмечается, что в исследовании рассмотрен лишь вопрос производительности, без акцентирования внимания на такие преимущества LLVM, как возможность компиляции программы в переносимый между разными платформами универсальный байткод. С другой стороны, GCC имеет фронтэнды для большего числа языков программирования (например, Java и Fortran отсутствуют в LLVM), поддерживает значительно более широкий спектр аппаратных платформ и задействует больше механизмов оптимизаций, привязанных к этим платформам. Кроме того, поддержка C++ в GCC реализована более полно, по сравнению с CLang.

  1. Главная ссылка к новости (http://www.phoronix.com/scan.p...)
  2. OpenNews: Оценка производительности GCC 4.5.0
  3. OpenNews: Сравнение производительности компиляторов GCC и LLVM-GCC
  4. OpenNews: Новая версия набора компиляторов LLVM Compiler 2.6
  5. OpenNews: Компилятор Clang преодолел барьер собственной пересборки
  6. OpenNews: Тестирование варианта FreeBSD, переведенного на компилятор Clang
Лицензия: CC-BY
Тип: К сведению
Ключевые слова: gcc, llvm
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (56) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Аноним (1), 11:16, 21/04/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ну и к чему все эти баяны, когда gcc по прежнему быстр, поддерживает больший спектр аппаратных платформ и более полно поддерживает спецификации языков?
     
     
  • 2.2, Dimez (??), 11:26, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Он под некошерной, по мнению BSD-сообщества, лицензией.
     
     
  • 3.5, QuAzI (??), 11:48, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • –10 +/
    А что вы понимаете под кошерностью?
     
     
  • 4.6, аноним (?), 11:54, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • +9 +/
    BSD-сообщество занимается подготовкой кода, предназначенного для включения в проприетарные проекты. Поэтому кошерность = возможность не открывать сорцы.
     
     
  • 5.9, zazik (ok), 11:57, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Очень тонко, браво!
     
  • 5.31, Аноним (-), 16:33, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ну по сравнению с сообществои GPL которое занимается подготовкой среды для выполнения бинарных блобов от больших корпораций - мы таки просто ангелы :)

    PS: Ещё более тонко ...

     
     
  • 6.46, Аноним (-), 20:05, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ещё более тонко ...
     
  • 6.55, User294 (ok), 07:15, 22/04/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >мы таки просто ангелы :)

    Только местом обитания таких "ангелов" являются почему-то ... пещеры, сами "ангелы" как правило толстоваты, любят покушать, нимба нет а в руках почему-то дубинка. Вот такие вот хреновые нынче ангелы... :P

    p.s. что минусуете, пещерные? Правда глаза колет? А может нимб жмет? :)

     
  • 2.3, Timka (??), 11:31, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ну да, зачем нужны 16-ядерные оптероны, когда на моем компе и 4-ядерный не загружен...
    сlang еще в стадии развития, что будет после того, как он проживет хотя бы 1/10 от gcc - еще вопрос.
     
     
  • 3.7, Аноним (1), 11:54, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Clang начали пилить с 2005го судя по wiki. Так что ему уже 5 лет, а gcc - 25.
     
  • 3.29, sHaggY_caT (ok), 15:27, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >ну да, зачем нужны 16-ядерные оптероны

    Таких пока нет. В 6100 series(Magny-Cours) максимум 12 ядер.

     

  • 1.4, JL2001 (ok), 11:47, 21/04/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    зачем же делают LLVM-GCC если "тоже самое" на жаве-JIT "тормозит в 3 раза" ? может и в жаве не "язык кривой" а программисты пишут не задумываясь ?
     
     
  • 2.10, DJa (?), 11:58, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >на жаве-JIT "тормозит в 3 раза"

    _Большинство_ пишут не задумываясь из-за автоматического управления памяти. Вот это автомат в яве и тормозит. Такия вот "безопасные" языки выращивают безответственных программеров.

     
     
  • 3.12, sluge (ok), 12:11, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    автоматическое распределение памяти и были придумано чтобы избежать ошибок при работе с ней. наобщать наобещали а для той же жавы по нормальному так и не сделали. вот и приходится самому следить за памятью.
     
     
  • 4.56, User294 (ok), 07:27, 22/04/2010 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >автоматическое распределение памяти и были придумано чтобы избежать ошибок при работе с
    >ней.

    Ну, стали течь объекты которые забыли освободить вместо массивов памяти. В итоге сильно лучше не стало, а к ошибкам в программе добавились ошибки в 100-меговом рантайме (коих как грязи в такой массе кода). В том числе и куча по части секурити, если уж на то пошло. Вон например запускач явы из веба позволял запускать вообще что попало с правами текущего юзера. Безопаснее некуда, ага. Вообще, есть такое подозрение что как безбашенных дебилов не строй - а они всегда найдут где облажаться. Ну вон веб приложения. Ну, нет там управления памяти. Что, стало лучше? А вот и хрен вам. То инклуды левых файлов, то sql-иньекции, то XSS... и в итоге как-то никто не стал чувствовать себя сильно защищеннее, а вопли хомячков вида "гугл взломали" уже начинают становиться привычными, чтоли. Может быть отстоен не язык а криворукие программисты, а? При том криворуких которые юзают си/си++  к счастью осталось немного, криворукие сбежали на явы, дельфи и прочие дотнеты за быстрым баблом клепать г-нецо бизнесу :)

     
     
  • 5.60, sluge (ok), 11:34, 22/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    ты что сказать то хотел?
    я писал про то что раз обещали сделать автоматическую сборку мусора-сделайте качественно или вообще уберите ее
     
  • 3.17, Denis Ivanchik (?), 12:50, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Мне кажется Вы не компетентны в том, о чем говорите.
     
     
  • 4.61, qpq (ok), 23:56, 22/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    +1 но спорить с ними бесполезно..
     
  • 3.19, JL2001 (ok), 14:27, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >_Большинство_ пишут не задумываясь из-за автоматического управления памяти. Вот это автомат в
    >яве и тормозит. Такия вот "безопасные" языки выращивают безответственных программеров.

    мне кажется что из-за того что в жаве легко программировать верхними представлениями не особо зная что кроется внутри и не особо представляя на сколько они оптимальны и оверхедны для задач программиста и получается торможение
    вероятно компилятор и JIT не на столько круты чтоб выкидывать всё неиспользуемое в программе этого прогера

     
     
  • 4.20, mike lee (?), 14:31, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    т.е. если идиот пишет на жаве то все тормозит, а если на другом языке то нет?
     
     
  • 5.21, pavlinux (ok), 14:52, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    По пробуй на ADA замутить глючную прогу :)
     
     
  • 6.32, Аноним (-), 16:44, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Погугли про Ариан-5 и как его завалила малюсенькая программка на языке который прям таки не позволяет ваять глючгый код ... :)
     
     
  • 7.34, pavlinux (ok), 17:01, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Ути пуси! :) Ыксперты жгутЪ!(С)
    >
    >Погугли про Ариан-5 и как его завалила малюсенькая программка
    > на языке который прям таки не позволяет ваять глючгый код ... :)

    :)
    Мы говорили про идиотов, а не про слепых программистов, путающих "." и ","

     
     
  • 8.47, Warhead Wardick (?), 20:16, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А какая разница на чём пишет идиот Результат по любому на 100 предсказуем Ну... текст свёрнут, показать
     
  • 5.28, JL2001 (ok), 15:26, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >т.е. если идиот пишет на жаве то все тормозит, а если на другом языке то нет?

    если идиот пишет на Сях то пока он сможет запустить свою программу - вероятно он чему-то научится )) или его программа работать будет как 4.0 кеды :)

     
     
  • 6.33, Аноним (-), 16:59, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да пофиг не чём написано! Главное кем и как.
    Есть "в одном высокогорном селении Простоквашино" Гор. СЭС для которой в ~1993 году старший детёнок главбуха написал какую то автоматизацию ... не за деньги даже, а за то что ночью ему давался доступ с писюку. Так вот - у них давно уже свой IT отдел, и все они хором заявляют что это единственная прога которая "просто работает" и пережила DOS->Win3.*->Win9?->WinNT4->Win200 ...

    Так вот - оно на MS GW-BASIC! Ога - на том самом, с "кошмарными goto" ;-)

     
     
  • 7.36, pavlinux (ok), 17:09, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > ... ~1993 году старший детёнок главбуха написал какую то автоматизацию ...
    > и все они хором заявляют что это единственная прога которая "просто работает"

    Кстати, трехколесный велосипед "Малыш", тоже средство передвижения.


     
     
  • 8.48, Diogene the Open Source programmer (?), 20:20, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Хе-хе Кстати с точки зрения ребятёнка на нём рассекающего - абсолютно так ... текст свёрнут, показать
     

  • 1.11, sluge (ok), 12:09, 21/04/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Реальный тест-если собрать всю сисетму каждым из компалеров и поработать в ней некоторое время
     
  • 1.13, Proger (ok), 12:15, 21/04/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Отчёт какой-то бестолковый. "В тесте флипфлопхрюп 432.65.7 clang оказался медленнее gcc" - НУ И ЧТО? В чём смысл теста-то? Интересно увидеть конкретные тестируемые фичи - плавающую точку, создание объектов, вызовы функций... Заодно будет видно, что подкрутить в clang. Мне кажется, за clang будущее, т.к. он более модульный и современный, просто ещё не очень отполированный. Заодно это создаёт платформу для переноса других языков (а не прикручивать их сбоку как в gcc).
     
     
  • 2.58, azure (ok), 10:22, 22/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Фороникс же..
     

  • 1.14, Аноним (-), 12:17, 21/04/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    а более внятные сообщения об ошибках уже не преимущество clang? LTO, впрочем, он есть в gcc45 и llvm-gcc. Да и phoronix как всегда троллит:

    > GCC 4.5 is taking more time to compile programs *likely* due to the LTO support and other new features,

    likely? т.е. они даже не знают включили ли он его? clang и llvm-gcc тоже, наверное, компилят без LTO. Fail.

    Ах да, лучше бы сравнивали XZ (Си) вместо 7zip (Си++). Си-код лучше оптимизируется.

     
     
  • 2.22, pavlinux (ok), 14:55, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Ах да, лучше бы сравнивали XZ (Си) вместо 7zip (Си++). Си-код лучше оптимизируется.

    Хороший Cи-код вообще не оптимизируется :)

     
     
  • 3.30, Aesthetus Animus (ok), 15:58, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Даже хороший код оптимизируется, но на более низком уровне. Естесственно, кривую архитектуру программы никакой компилятор не соптимизирует и не исправит ;)
     
  • 3.40, Andrey Mitrofanov (?), 18:01, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Хороший Cи-код вообще не оптимизируется :)

    На оптимирацию "хорошего сишного" потрачены минуты и часы жизни программиста, а на оптимизацию "не-хорошего" -- секунды-минуты компилятора. "А если не видно разницы..."

     
     
  • 4.43, pavlinux (ok), 18:36, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>Хороший Cи-код вообще не оптимизируется :)
    >
    >На оптимирацию "хорошего сишного" потрачены минуты и часы жизни программиста, а на
    >оптимизацию "не-хорошего" -- секунды-минуты компилятора.
    > "А если не видно разницы..."

    То PHP и .Net правит миром. (по закону - ошибки не суммируются, а умножаются)

     
  • 4.53, XoRe (ok), 00:59, 22/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>Хороший Cи-код вообще не оптимизируется :)
    >
    >На оптимирацию "хорошего сишного" потрачены минуты и часы жизни программиста, а на
    >оптимизацию "не-хорошего" -- секунды-минуты компилятора. "А если не видно разницы..."

    Компилятор не может оптимизировать логические ляпы.
    Например:

    for (охренительный цикл)
    {
      инициализация одних и тех же переменных;

      вычисление;
    }

    Когда инициализацию нужно выносить ДО for.

     
     
  • 5.57, Andrey Mitrofanov (?), 10:18, 22/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Компилятор не может оптимизировать логические ляпы.

    Исправление ошибок и оптимизация -- таки разные вещи, совсем. Начитайте оптимизировать свою логическую ошибку. Не при всех же ж, pls%%%

     
  • 5.59, Andrey Mitrofanov (?), 10:22, 22/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Например:
    >for (охренительный цикл)
    >{
    >  инициализация одних и тех же переменных;
    >  вычисление;
    >}
    >Когда инициализацию нужно выносить ДО for.

    И да, компиляторы это давно делают, я полагаю............

     
  • 2.24, Гость (?), 15:06, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > а более внятные сообщения об ошибках уже не преимущество clang?

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

    > Ах да, лучше бы сравнивали XZ (Си) вместо 7zip (Си++). Си-код лучше оптимизируется.

    Код не оптимизируется, оптимизируется промежуточное представление.

     
     
  • 3.39, pavlinux (ok), 17:56, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >> а более внятные сообщения об ошибках уже не преимущество clang?
    >Ну они там сказали, что не все отличия между компиляторами можно выразить
    >числами.
    >> Ах да, лучше бы сравнивали XZ (Си) вместо 7zip (Си++). Си-код лучше оптимизируется.
    >Код не оптимизируется, оптимизируется промежуточное представление.

    Не придирайся, имеется в виду те фишки, которые доступны на процессоре,
    типа разворачивание циклов, векторизация, оптимизация условных переходов - likely()/unlikely(),
    с флотами/даблами - непроверка на переполнения и div/0, всякие предсказания,
    сache-hits, inline/uninline и т.п.

    Собственно, никто не мешает всё это провернуть в ручную.

     

  • 1.18, Nirnroot (?), 14:07, 21/04/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    >В целом LLVM / Clang не оправдали возложенные на них ожидания

    Кем возложенные? Какие ожидания?
    Сравните количество людей, которые работают над gcc и clang, и время, которое они развивались.

     
     
  • 2.23, Анонима (?), 14:58, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    поддерживаю, странное заявление
     
  • 2.25, Aleksey (??), 15:11, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Создателями конечно. Например, "Fast compiles and Low Memory Use"
    http://clang.llvm.org/features.html#enduser
     
     
  • 3.37, аноним (?), 17:20, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ну эти-то он оправдал.
     
  • 3.52, Pilat (ok), 23:28, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Создателями конечно. Например, "Fast compiles and Low Memory Use"
    >http://clang.llvm.org/features.html#enduser

    Ну да, сейчас памяти просто не хватает... а 12-ядерные процессоры не могут откомпилировать "hello world" за приемлемое время.

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

     
     
  • 4.54, Ян Злобин (ok), 02:57, 22/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Сравнивать надо скорость и качество получившихся программ, а не компиляторов.

    Именно так!

     
  • 2.26, exp. (?), 15:25, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Apple
     
  • 2.27, Аноним (-), 15:25, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ну это Фороникс+Опеннет высказывание, кто там чего ожидал не ясно.
    Кому-то просто очень стало больно в попе от антипиара gcc.
     

  • 1.35, Аноним (-), 17:06, 21/04/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Ага - опять скорость измерялась количеством FPS в запущенной в паралель игрухе?
    форониксы же! :)
     
  • 1.38, anonymous (??), 17:49, 21/04/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Интересно, а бойцам из фороникса вводный курс 'обработка экспериментальных данных' никто не предлагал прочитать?
     
  • 1.41, eugeni (?), 18:12, 21/04/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Хотел бы ,где-нибудь, увидеть структуру "виртуального процессора" от GCC и Clang.
    А так непонятно вчем новизна ?
    В общем : если Clang более эффективен, буду компилировать Linux в Сlang.
    Линцензии дома меня не волнуют.
     
     
  • 2.49, Diogene the Open Source programmer (?), 20:23, 21/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >В общем : если Clang более эффективен, буду компилировать Linux в Сlang.

    FreeBSD-шнеги делают. Даже ядро и мир им собранные уже бутятся :)

     

  • 1.50, eugeni (?), 20:38, 21/04/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    FreeBSD-шнеги делают. Даже ядро и мир им собранные ужо бутятся :)
    Большое спасибо. Но пока сбегаю на Debian качнуть KFREEBSD.
    Вроде есть 3d-поддержка к древнему Mach64 (очень актуально).
    А там видно будет.
     
  • 1.51, Lockal (??), 21:05, 21/04/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Они видимо решили забить на все float-ы в программах и стандарте C99, улучшение поддержки которого сильно замедлило компиляцию таких программ. Компилировали бы с -fexcess-precision=fast -- получили бы ускорение в компиляции.
     
     
  • 2.62, mirsev (ok), 14:18, 23/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А -fexcess-precision=fast только компиляцию ускоряет или выполнение кода -- тоже?
     

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



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

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