Представляем GNU Compiler Collection (GCC) и виртуальную машину Clang / Low Level (LLVM); сравнение производительности обоих компиляторов C / C ++

Фон

Visual C ++, GNU Compiler Collection (GCC) и Clang / Low Level Virtual Machine (LLVM) - три основных компилятора C / C ++ в отрасли. Visual C ++ предоставляет графический пользовательский интерфейс (GUI) и его легко отлаживать, но он не подходит для платформ Linux. Таким образом, этот документ в основном сравнивает GCC с Clang / LLVM.

GCC - это компилятор языка программ, разработанный GNU. Это набор бесплатного программного обеспечения, выпущенного под Стандартной общественной лицензией GNU (GPL) и Стандартной общественной лицензией ограниченного применения GNU (LGPL). Это официальный компилятор для систем GNU и Linux, а также основной компилятор для компиляции и создания других операционных систем UNIX.

LLVM содержит серию модульных компонентов компилятора и цепочек инструментов. Он может оптимизировать языки программ и ссылки во время компиляции, выполнения и простоя, а также генерировать код. LLVM может служить фоном для компиляторов на нескольких языках. Clang - это компилятор C, C ++, Objective-C или Objective-C ++, который скомпилирован на C ++ на основе LLVM и выпущен под лицензией Apache 2.0. Clang в основном используется для обеспечения более высокой производительности, чем у GCC.

Благодаря долгой разработке и итерациям GCC, Clang и LLVM стали зрелыми компиляторами в отрасли. Тогда какой компилятор лучше? Какой из них мы должны использовать для компиляции и сборки программ и систем?

Значение хорошего компилятора

Все современные процессоры имеют суперскалярные и длинные конвейеры, а также сложные внутренние структуры, и они поддерживают блоки векторного расширения в архитектуре компьютера со сложным набором команд (CISC) или компьютера с сокращенным набором команд (RISC). Для многих программ, содержащих ядра с интенсивными вычислениями, программисты могут использовать команды векторного расширения для значительного повышения производительности программы. Например, в матричных и векторных операциях объединенные команды умножения и сложения используются для повышения производительности и точности. Команды битовой маски используются для обработки ветвей в векторных операциях. Однако для достижения наивысшей производительности программистам и компиляторам по-прежнему необходимо прилагать много усилий для обработки задач со сложными режимами доступа к памяти и нестандартными ядрами.

Кроме того, стандарты современных продвинутых языков постоянно абстрагируются от деталей базового оборудования и структур данных для генерации общего кода, который является более логичным и математическим, вместо конкретных инструкций операций и путей доступа к памяти. Стандарты C ++ становятся все более выразительными и абстрактными. Python популярен, потому что он более читабелен и выразителен даже за счет более низкой скорости работы. Более высокая выразительность увеличивает нагрузку на компилятор по созданию хорошего ассемблерного кода из сложных структур, скомпилированных программистами. Компилятор должен быть умнее и усерднее работать, чтобы максимизировать производительность с помощью кода. Не все компиляторы могут это сделать. При выборе компилятора мы должны сначала подумать, может ли один и тот же сегмент кода генерировать более эффективные команды сборки.

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

Что касается расширения языка, современные вычислительные системы с несколькими ядрами, возможностями векторной обработки и ускорителями предоставляют возможности, превосходящие естественные возможности обычных языков программирования. Таким образом, специальные платформы для высокопроизводительных вычислений (HPC), такие как OpenMP и OpenACC, могут восполнить этот пробел. Эти платформы предоставляют программные интерфейсы приложений (API), которые программисты могут использовать для выражения параллелизма в коде. Компилятор и соответствующая библиотека времени выполнения должны отображать параллельный код в архитектуру процессора. Многие проекты HPC зависят от стандартов OpenMP и OpenACC, которые расширяются разработчиками и производителями оборудования. Следовательно, компиляторы должны идти в ногу с развитием стандартов языковых расширений.

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

История развития GCC

Прежде чем изучать GCC, вам нужно сначала понять проект GNU. Ричард Столмен запустил проект GNU в 1984 году для создания UNIX-подобной системы программного обеспечения с открытым исходным кодом. Операционная система GNU не претерпела значительных изменений с течением времени. Однако он создал множество отличных и полезных программных инструментов с открытым исходным кодом, таких как Make, Sed, Emacs, Glibc, GDB и GCC. Это программное обеспечение с открытым исходным кодом GNU и ядра Linux вместе составляют систему GNU / Linux. Вначале GCC предоставлял стабильные и надежные компиляторы, основанные на языке программирования C, для системы GNU. Его полное название - GNU C Compiler. Позже было поддержано больше языков (таких как Fortran, Obj-C и Ada), а полное имя GCC было изменено на GNU Compiler Collection.

GCC-1.0 был выпущен Ричардом Столлманом в 1987 году, более тридцати лет назад. С точки зрения программного обеспечения он очень старый. Кто-то собрал записи о разработке GCC за период с 1989 по 2012 год и выпустил 30-минутное анимированное видео (история разработки GNU Compiler Collection 1989–2012), интуитивно демонстрирующее процесс разработки GCC. Об истории развития GCC мы можем узнать из его версий:

  • GCC-1.0: выпущен Ричардом Столлманом в 1987 году.
  • GCC-2.0: выпущен в 1992 году и поддерживает C ++. Позже сообщество GCC раскололось, потому что Ричард Столлман определил GCC как надежный компилятор C системы GNU и подумал, что GCC в то время был достаточен для системы GNU и фокус разработки следует перенести с GCC на саму систему GNU. Другие крупные разработчики надеялись продолжить совершенствование GCC и внести более радикальные изменения и улучшения в различных аспектах. Эти активные разработчики покинули сообщество GCC в 1997 году и разработали вилку EGCS.
  • GCC-3.0: Очевидно, что у разработчиков было сильное желание иметь хорошие компиляторы. Форк EGCS плавно развивался и получил признание все большего числа разработчиков. В конце концов, EGCS был использован в качестве новой магистрали GCC, и в 2001 году был выпущен GCC-3.0. Разделившееся сообщество было снова объединено, но влияние Ричарда Столлмана было в определенной степени ослаблено. Кроме того, Промышленный комитет GCC начал определять направление развития GCC.
  • GCC-4.0: выпущен в 2005 году. Эта версия была интегрирована в Tree Serial Storage Architecture (SSA), и GCC превратился в современный компилятор.
  • GCC-5.0: выпущен в 2015 году. Позже политика версий GCC была скорректирована, и каждый год выпускалась основная версия. Неожиданным преимуществом является то, что номер версии соответствует году. Например, GCC-7 был выпущен в 2017 году, а GCC-9 - в 2019 году.

Теперь разработка GCC вошла в «современную летопись». Столкнувшись с давлением конкуренции со стороны LLVM, сообщество GCC активно внесло множество изменений, таких как ускорение компиляции и улучшение информации о предупреждениях компиляции. За последние 30 лет GCC превратился из конкурента в индустрии компиляторов в основной компилятор для систем Linux и теперь сталкивается с проблемой LLVM. К счастью, сообщество GCC вносит коррективы, чтобы ускорить разработку GCC. Можно ожидать, что конкуренция между двумя технологиями компиляции продолжит обеспечивать разработчиков программного обеспечения лучшими компиляторами.

История развития Clang и LLVM

LLVM

LLVM возник в результате исследования Криса Латтнера UUIC в 2000 году. Крис Латтнер хотел создать технологию динамической компиляции для всех статических и динамических языков. LLVM - это тип программного обеспечения с открытым исходным кодом, разработанного по лицензии BSD. Первоначальная версия 1.0 была выпущена в 2003 году. В 2005 году Apple Inc. наняла Криса Латтнера и его команду для разработки языков программирования и компиляторов для компьютеров Apple, после чего разработка LLVM вошла в быстрый путь. Начиная с LLVM 2.5, ежегодно выпускались две второстепенные версии LLVM (обычно в марте и сентябре). В ноябре 2011 года был выпущен LLVM 3.0, который стал компилятором XCode по умолчанию. XCode 5 по умолчанию начал использовать Clang и LLVM 5.0. Политика версий была скорректирована для LLVM 5.0 и более поздних версий, и ежегодно выпускаются две основные версии. Текущая стабильная версия - 8.0.

Название LLVM было впервые сокращено от Low Level Virtual Machine. Поскольку этот проект не ограничивается созданием виртуальной машины, аббревиатура LLVM часто ставится под сомнение. После того, как LLVM был разработан, он стал собирательным термином для многих инструментов компиляции и низкоуровневых инструментальных технологий, что сделало название менее подходящим. Разработчики решили отказаться от значения этой аббревиатуры. Теперь LLVM стал официальным брендом, применимым ко всем проектам в рамках LLVM, включая промежуточное представление LLVM (LLVM IR), инструменты отладки LLVM и стандартные библиотеки LLVM C ++. LLVM можно использовать как традиционный компилятор, JIT-компилятор, ассемблер, отладчик, инструмент статического анализа и для других функций, связанных с языками программирования.

В 2012 году LLVM выиграла награду за программное обеспечение Ассоциации вычислительной техники (ACM) вместе с такими традиционными системами, как UNIX, WWW, TCP / IP, TeX и Java. LLVM значительно упрощает реализацию новых цепочек инструментов языка программирования. В последние годы многие новые языки программирования, такие как Swift, Rust и Julia, использовали LLVM в качестве среды компиляции. Кроме того, LLVM стал компилятором по умолчанию для систем Mac OS X, iOS, FreeBSD и Android.

Лязг

Clang разработан, чтобы предоставить компилятор внешнего интерфейса, который может заменить GCC. Apple Inc. (включая NeXT позже) использовала GCC в качестве официального компилятора. GCC всегда хорошо работал в качестве стандартного компилятора в сообществе разработчиков ПО с открытым исходным кодом. Однако у Apple Inc. есть свои требования к инструментам компиляции. С одной стороны, Apple Inc. добавила много новых функций для языка Objective-C (или даже, позже, языка C). Однако разработчики GCC не приняли эти функции и присвоили поддержку этим функциям низкий приоритет. Позже они были просто разделены на две ветви для отдельной разработки, и, следовательно, версия GCC, выпущенная Apple Inc., намного раньше официальной версии. С другой стороны, код GCC сильно связан и его сложно разрабатывать отдельно. Кроме того, в более поздних версиях качество кода продолжает снижаться. Однако многие функции, требуемые Apple Inc. (например, поддержка улучшенной интегрированной среды разработки (IDE)), должны вызывать GCC как модуль, но GCC никогда не предоставляет такую ​​поддержку. Более того, исключение из библиотеки времени выполнения GCC фундаментально ограничивает разработку LLVM GCC. Также ограниченная лицензией, Apple Inc. не может использовать LLVM для дальнейшего улучшения качества генерации кода на основе GCC. Поэтому Apple Inc. решила написать интерфейс Clang языков C, C ++ и Objective-C с нуля, чтобы полностью заменить GCC.

Как следует из названия, Clang поддерживает только C, C ++ и Objective-C. Разработка началась в 2007 году, и компилятор C. Облако Clang для Objective-C будет полностью использовано в производственной среде в 2009 году. Поддержка C ++ также быстро прогрессировала. Clang 3.3 полностью поддерживал C ++ 11, Clang 3.4 полностью поддерживал C ++ 14, а Clang 5 полностью поддерживал C ++ 17, и все они в то время значительно опережали GCC.

Сообщество Clang / LLVM и GCC

Сообщество GCC

Как и в других сообществах программного обеспечения с открытым исходным кодом, в сообществе GCC доминируют энтузиасты свободного программного обеспечения и хакеры. В процессе развития сегодня постепенно формируются механизмы управления и участия сообщества GCC. В настоящее время сообщество GCC представляет собой относительно стабильное и четко определенное общество знакомств, в котором у каждого человека есть четкие роли и обязанности:

  • Ричард Столмен и Фонд свободного программного обеспечения (FSF): Хотя Ричард Столмен и FSF редко участвуют в управлении сообществом GCC, они все еще разобщены в лицензионных и юридических вопросах.
  • Промышленный комитет GCC: он управляет делами сообщества GCC, независимыми от технологий темами разработки GCC, а также назначением и объявлением рецензентов и сопровождающих. В настоящее время в нем 13 членов.
  • Глобальные сопровождающие: они доминируют в разработке GCC. В какой-то степени они определяют направление развития GCC. В настоящее время существует 13 глобальных специалистов по сопровождению, не все из которых занимают должности в Промышленном комитете GCC.
  • Сопровождающие внешнего, среднего и внутреннего интерфейса: они поддерживают внешний интерфейс, серверную часть и другие модули. Они отвечают за код соответствующего модуля GCC, и многие из них являются основными участниками кода модуля. Стоит отметить, что рецензенты обычно попадают в эту группу. Разница в том, что рецензенты не могут утвердить свой собственный патч, в то время как сопровождающие могут вносить свои собственные модификации в пределах своей ответственности без одобрения рецензентов.
  • Соавторы: это самые обширные группы разработчиков в сообществе GCC. После подписания соглашения об авторских правах любой разработчик может подать заявку на разрешение «Запись после утверждения» от сообщества, а затем самостоятельно отправить код.

Как и в других сообществах с открытым исходным кодом, в зрелом сообществе GCC больше не доминируют хакеры. Коммерческие компании начали играть важную роль в сообществе, например, нанимать разработчиков и спонсировать встречи разработчиков. В настоящее время в сообществе GCC преобладают следующие типы коммерческих компаний:

  • Поставщики систем, в основном RedHat и SUSE.
  • Поставщики микросхем, в основном Intel, ARM, AMD и IBM (PowerPC).
  • Специализированные поставщики, такие как CodeSourcery, и поставщики услуг цепочки инструментов, такие как AdaCore, основанные на языке Ada. CodeSourcery имел блестящую историю и нанял многих известных разработчиков, но отказался от него после того, как его купил Mentor.

В нынешнем сообществе GCC поставщики микросхем доминируют в разработке серверной части, в то время как поставщики систем руководят другими областями разработки. Что касается разработки сообщества, код GCC в настоящее время размещен на собственном сервере SVN. Предоставляется Git API для облегчения разработки и отправки. Обзор исправлений аналогичен обзору в сообществе ядра Linux и использует форму списка рассылки. Как упоминалось выше, сообщество GCC - относительно стабильное (или закрытое) общество знакомств. Сообщество в основном насчитывает от 150 до 200 активных участников каждый год и ежегодно в сентябре проводит конференции разработчиков. В сентябре 2019 года конференция разработчиков пройдет в Монреале, Канада.

Сообщество LLVM

Сообщество LLVM - это сообщество компиляторов, дружелюбное к новичкам. Он быстро отвечает на вопросы новых пользователей и отзывы о патчах. Это также является основой и источником для последующих обсуждений в LLVM Foundation и принятия Кодекса поведения сообщества LLVM, а также вызывает серию политически корректных дискуссий.

Все проекты и проблемы LLVM обсуждаются через список рассылки DevExpress, а отправка кода уведомляется через список рассылки коммитов. Все ошибки и модификации функций отслеживаются через список ошибок. Представленные патчи рекомендуются для основных веток. Стиль соответствует стандартам кодирования LLVM, а проверка кода выполняется через Phabricator. В настоящее время репозиторий кода LLVM перенесен на GitHub.

В отличие от сообщества GCC, сообщество LLVM имеет только LLVM Foundation. В LLVM Foundation восемь членов. Помимо управления делами сообщества LLVM, каждый член LLVM Foundation должен руководить вопросами разработки LLVM, связанными с технологиями. В настоящее время президентом является Таня Латтнер, жена Криса Латтнера. Сам Крис Латтнер также является членом фонда и строго контролирует сообщество LLVM и направление развития LLVM.

Политика проверки кода в сообществе LLVM в основном такая же, как и в сообществе GCC. Разница в том, что из-за быстрой разработки LLVM многие участники не имеют разрешения на доступ к фиксации и должны отправлять свой код через сопровождающих. В настоящее время сообщества Clang и LLVM ежегодно вносят более 1000 участников. Как правило, конференции разработчиков проводятся ежегодно в апреле и октябре. Конференция разработчиков в октябре 2019 года пройдет в Сан-Хосе, США.

Лицензия LLVM изменена с лицензии UIUC на лицензию Apache 2.0 с исключениями LLVM. В основном он используется для решения проблемы, заключающейся в том, что библиотека времени выполнения LLVM основана на лицензии MIT, а патентное разрешение, требуемое для проекта, является слишком обширным. В соответствии с этой лицензией LLVM позволяет любому создавать коммерческие продукты из LLVM без каких-либо ограничений и не требует, чтобы какие-либо производные предоставляли открытый исходный код, что способствует широкому использованию LLVM, в том числе:

  1. Загрузка или использование LLVM полностью или частично в личных, внутренних или коммерческих целях. Возможность изменять код LLVM, не внося его обратно в проект.
  2. Создание пакета или версии выпуска, содержащей LLVM. Связь LLVM с кодом, разрешенным всеми другими основными лицензиями с открытым исходным кодом (включая BSD, MIT, GPLv2 и GPLv3).
  3. При повторном распространении LLVM вы должны сохранить уведомление об авторских правах. Вы не можете удалить или заменить заголовок об авторских правах. Бинарный файл, содержащий LLVM, должен содержать уведомление об авторских правах.

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

Тестовый сервер

Архитектура: x86_64
Процессор: Intel (R) Xeon (R) Platinum 8163 CPU @ 2,50 ГГц
Кэш данных L1: 32 КБ
Кэш L2: 1024 КБ
Кэш L3: 33 792 КБ
Память: 800 ГБ
Операционная система: Alibaba Group Enterprise Linux Server, выпуск 7.2 (Paladin)
Ядро: 4.9.151–015.ali3000.alios7.x86_64
Компилятор: Clang / LLVM 8.0 GCC8.3.1

Контрольный показатель

SPEC CPU 2017 - это набор инструментов тестирования подсистемы ЦП для тестирования ЦП, кеша, памяти и компилятора. Он содержит 43 теста четырех категорий, в том числе SPECspeed 2017 INT и FP, которые проверяют скорость целочисленного числа и скорость операций с плавающей запятой, и SPECrate 2017 INT и FP, которые проверяют скорость целочисленного параллелизма и скорость параллелизма с плавающей запятой. Clang не поддерживает язык Fortran. Поэтому в этом примере программы C / C ++ в наборе тестов SPEC Speed ​​используются для проверки разницы в производительности одноядерных программ между бинарными программами, созданными Clang и GCC. В следующей таблице перечислены наборы SPEC CPU2017 C и C ++:

CINT2017 SpeedCFP2017 Speed600.perlbench_s619.lbm_s602.gcc_s644.nab_s605.mcf_s620.omnetpp_s623.xalancbmk_s625.x264_s631.deepsjeng_s641.leela_s657.xz_s

Методы испытаний

Среда автоматизации LLVM-lnt используется для проведения теста и сравнения производительности. Он работает так же, как runcpu процессора SPEC. Перед запуском LLVM-lnt кеш (echo 3 ›/ proc / sys / vm / drop_caches) очищается, а затем запускается тестовый набор данных. Затем набор данных ref запускается три раза. Среднее значение результатов трех эталонных испытаний используется в качестве окончательного результата. Чтобы уменьшить колебания производительности, вызванные миграцией ЦП или переключением контекста, процессы, выполняемые в наборе тестовых данных и наборе данных ref, привязываются к ядру ЦП с помощью инструмента сопоставления ЦП. Для теста времени компиляции этот метод использует поток 1 для построения тестовой программы и сравнения элементов теста, которые были скомпилированы в течение длительного времени. Время компиляции не включает время выполнения компоновщика. Он включает только время, когда были созданы все исходные файлы во всех тестовых программах.

Сравнение производительности компиляции

Процесс компиляции GCC выглядит следующим образом: прочитать исходный файл, предварительно обработать исходный файл, преобразовать его в IR, оптимизировать и сгенерировать файл сборки. Затем ассемблер генерирует объектный файл. Clang и LLVM не полагаются на независимые компиляторы, но интегрируют самостоятельно реализованные компиляторы на бэкэнде. Процесс создания файлов сборки опускается в процессе создания объектных файлов. Объектный файл создается непосредственно из IR. Кроме того, по сравнению с GCC IR структура данных LLVM IR более лаконична. Он занимает меньше памяти во время компиляции и поддерживает более быстрый обход. Следовательно, Clang и LLVM имеют преимущество с точки зрения времени компиляции, что подтверждается данными, полученными при компиляции SPEC, как показано на рисунке ниже. Clang сокращает время однопоточной компиляции на 5-10% по сравнению с GCC. Поэтому Clang предлагает больше преимуществ при строительстве крупных проектов.

Сравнение времени компиляции SPEC

Сравнение производительности исполнения

Большинство облачных рабочих нагрузок требуют, чтобы приложения могли работать в разных кластерах. При создании этих приложений не указывайте параметры, относящиеся к машине. Чтобы адаптироваться к быстрой итерации, вызванной изменением спроса, внешние рабочие нагрузки также должны быть отлаживаемыми. Следовательно, помимо некоторых стабильных и распространенных библиотек, которые обеспечивают высокие уровни оптимизации компиляции, сама рабочая нагрузка имеет низкий уровень компиляции и оптимизации (O2 или ниже). Чтобы удовлетворить это требование, в этом документе сравнивается производительность различных компиляторов на уровнях оптимизации O2 и O3 для программ INT Speed, как показано на следующем рисунке:

Сравнение производительности SPEC CPU2017 INT Speed

GCC имеет преимущество в производительности от 1% до 4% по сравнению с Clang и LLVM для большинства программ на уровнях O2 и O3 и в среднем имеет примерно 3% преимущество в производительности для SPEC CPU2017 INT Speed. Что касается 600.perlbench_s и 602.gcc_s / O2, GCC имеет большое преимущество в производительности (более 10%). Эти два элемента теста не имеют выдающихся горячих точек и могут отражать всесторонний эффект оптимизации компилятора. Результаты тестов показывают, что GCC всегда дает преимущество в оптимизации производительности. Однако для двух программ, связанных с ИИ, включая 631.deepsjeng_s и 641.leela_s, которые недавно добавлены в тест SPEC, Clang и LLVM улучшают производительность более чем на 3% по сравнению с GCC. Это также отражает быстрый прогресс LLVM с точки зрения оптимизации. Для оптимизации O2 625. x264_s LLVM повышает производительность на 40%, поскольку точка доступа кейса соответствует векторизованным правилам. Но Clang и LLVM оптимизируют векторы на уровне O2, тогда как GCC оптимизирует векторы на уровне O3. За исключением векторизованных программ, GCC не сильно улучшает производительность на уровне O3 по сравнению с производительностью на уровне O2. Другими словами, программы не чувствительны к оптимизации GCC O3. Напротив, Clang и LLVM значительно улучшают производительность некоторых программ (например, 600. perlbench_s и 602. gcc_s) на уровне O3.

Программы HPC, такие как FP Speed, обычно работают на высокопроизводительных серверах. Они имеют стабильные базовые алгоритмы, высокие требования к векторизации и параллелизму, связанные с производительностью, и обеспечивают высокий уровень оптимизации (O3 или выше). Поэтому в этом документе сравнивается производительность на уровне оптимизации O3 + march = native (skylake-avx512), как показано ниже:

Сравнение производительности SPEC CPU2017 FP Speed

Для двух программ FP GCC также может улучшить производительность примерно на 3%. Clang и LLVM консервативны в оптимизации цикла и, следовательно, не имеют преимуществ в производительности. Однако подпроект Polly Clang и LLVM предоставляет высокоуровневый оптимизатор циклов и локализации данных, который широко применяется в машинном обучении, высокопроизводительных вычислениях и оптимизации гетерогенных вычислений. Я считаю, что Polly может значительно улучшить производительность программ, содержащих петли горячих точек, соответствующих правилам векторизации и параллелизма. Я также проанализирую производительность Polly в серии тестов и рабочих нагрузок.

Заключительные замечания

Из приведенных выше тестов производительности мы видим, что Clang предлагает больше преимуществ для создания крупных проектов, в то время как GCC всегда дает преимущество в оптимизации производительности. Bla зависит от вашего конкретного приложения

Помимо сравнения производительности, я хотел бы поделиться преимуществами и недостатками GCC, Clang и LLVM:

Преимущества GCC

  • GCC поддерживает более традиционные языки, чем Clang и LLVM, такие как Ada, Fortran и Go.
  • GCC поддерживает менее популярные архитектуры и поддерживает RISC-V раньше, чем Clang и LLVM.
  • GCC поддерживает больше языковых расширений и больше функций языка ассемблера, чем Clang и LLVM. GCC по-прежнему остается единственным вариантом для компиляции ядра Linux. Хотя исследования компиляции ядра с использованием Clang и LLVM также сообщаются в отрасли, ядро ​​не может быть скомпилировано без изменения исходного кода и параметров компиляции.

Преимущества Clang и LLVM

  • Новые языки используют фреймворки LLVM, такие как Swift, Rust, Julia и Ruby.
  • Clang и LLVM более строго соответствуют стандартам C и C ++, чем GCC. GNU Inline и другие проблемы при обновлении GCC не возникают.
  • Clang также поддерживает некоторые расширения, такие как атрибуты для проверки безопасности потоков.
  • Clang предоставляет дополнительные полезные инструменты, такие как статический анализатор scan-build и clang для статического анализа, clang-format и clang-tidy для синтаксического анализа, а также подключаемый модуль редактора Clangd.
  • Clang предоставляет более точную и понятную диагностическую информацию и выделяет сообщения об ошибках, строки ошибок, подсказки строк ошибок и предложения по исправлению. Clang рассматривает диагностическую информацию как особенность. Диагностическая информация стала улучшаться только с GCC 5.0, а стала зрелой в GCC 8.

(Оригинальная статья Ма Джун 马骏)

Alibaba Tech

Подробная информация о новейших технологиях Alibaba из первых рук → Facebook: Alibaba Tech. Twitter: « AlibabaTech ».