Почему FreeBSD отказывается от GCC в пользу Clang / LLVM?

241

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

Из того, что я видел в сети, Clang / LLVM - довольно амбициозный проект, но с точки зрения надежности он не может соответствовать GCC .

Существуют ли какие-либо технические причины, по которым FreeBSD выбирает LLVM в качестве инфраструктуры компилятора, или все сводится к вечным лицензиям GNU / GPL и BSD?

Этот вопрос имеет (как-то) соответствующую информацию об использовании GCC во FreeBSD

NlightNFotis
источник

Ответы:

361

Описание: Основной причиной перехода с GCC на Clang является несовместимость лицензии GCC GPL v3 с целями проекта FreeBSD . Есть также политические проблемы, связанные с корпоративными инвестициями, а также требования к пользовательской базе. Наконец, ожидаемые технические преимущества связаны с соответствием стандартам и простотой отладки. Реальные улучшения производительности при компиляции и выполнении зависят от кода и являются предметом дискуссий; случаи могут быть сделаны для обоих компиляторов.

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

Однако из-за дополнительных сложностей, которые могут возникнуть при коммерческом использовании программного обеспечения GPL, мы, тем не менее, стремимся заменять такое программное обеспечение представлениями по более свободной лицензии FreeBSD, когда это возможно.

FreeBSD и GPL v3: GPL v3 явно запрещает так называемый тивоизация кода, лазейку в v2 GPL , что позволило аппаратные ограничения , чтобы запретить в противном случае правовые изменения программного обеспечения пользователей. Закрытие этой лазейки было неприемлемым шагом для многих в сообществе FreeBSD:

В частности, поставщики устройств могут потерять больше всего, если большая часть программного обеспечения, лицензируемая в настоящее время в соответствии с GPLv2, сегодня перейдет на новую лицензию. У них больше не будет свободы использовать программное обеспечение GPLv3 и ограничивать модификацию программного обеспечения, установленного на их оборудовании ... Короче говоря, существует большая база потребителей OpenSource, которые внезапно очень заинтересованы в понимании альтернатив лицензионному программному обеспечению GPL.

Из-за перехода GCC на GPL v3 FreeBSD была вынуждена продолжать использовать GCC 4.2.1 (GPL v2), выпущенную еще в 2007 году , и в настоящее время значительно устарела. Тот факт, что FreeBSD не перешел на использование более современных версий GCC, даже с дополнительными трудностями, связанными с обслуживанием старого компилятора и исправлениями бэкпортинга, дает некоторое представление о силе требования избегать GPL v3. Компилятор C является основным компонентом базы FreeBSD, и « одна из (предварительных) целей для FreeBSD 10 - базовая система без GPL ».

Корпоративные инвестиции. Как и многие крупные проекты с открытым исходным кодом, FreeBSD получает финансирование и разработку от корпораций. Хотя степень, в которой FreeBSD финансируется или разрабатывается Apple, не так легко обнаружить, существует значительное совпадение, потому что Apple Darwin OS использует существенный код ядра BSD . Кроме того, сам Clang изначально был собственным проектом Apple, до того как был открыт в 2007 году . Поскольку корпоративные ресурсы являются ключевым фактором реализации проекта FreeBSD, удовлетворение потребностей спонсоров, вероятно, является существенным движущим фактором в реальной жизни .

База пользователей: FreeBSD является привлекательным вариантом с открытым исходным кодом для многих компаний, потому что лицензирование является простым, неограниченным и вряд ли приведет к судебным процессам. С появлением GPL v3 и новыми положениями , направленными против Tivoisation , было высказано предположение о том, что существует тенденция ускорения, ориентированная на поставщиков, в направлении более разрешительных лицензий . Так как очевидное преимущество FreeBSD для коммерческих организаций заключается в его разрешительной лицензии, все больше пользователей вынуждены уходить от GCC и GPL в целом.

Проблемы с GCC: Помимо лицензии, использование GCC имеет некоторые предполагаемые проблемы . GCC не полностью соответствует стандартам, и имеет множество расширений , которых нет в стандарте ISO C . Более 3 миллионов строк кода - это также « один из самых сложных и бесплатных программных проектов с открытым исходным кодом ». Эта сложность делает модификацию кода на уровне дистрибутива сложной задачей.

Технические преимущества: Clang имеет некоторые технические преимущества по сравнению с GCC . Наиболее заметными являются гораздо более информативные сообщения об ошибках и явно разработанный API для IDE, инструментов рефакторинга и анализа исходного кода. Хотя на веб-сайте Clang представлены графики, показывающие гораздо более эффективную компиляцию и использование памяти, результаты в реальном мире весьма разнообразны и в целом соответствуют производительности GCC. В общем случае исполняемые Clang двоичные файлы работают медленнее, чем эквивалентные двоичные файлы GCC:

Хотя использование LLVM быстрее при создании кода, чем GCC ... в большинстве случаев встроенные двоичные файлы GCC 4.5 работали лучше, чем LLVM-GCC или Clang ... в остальных тестах производительность была либо близка к производительности GCC, либо хорошо позади. В некоторых тестах производительность генерируемых Clang двоичных файлов была просто ужасной.

Вывод: Маловероятно, что эффективность компиляции станет существенным стимулом для принятия существенного риска на перенос большого проекта, такого как FreeBSD, на совершенно новый набор инструментов компилятора, особенно когда не хватает бинарной производительности. Однако ситуация не была действительно устойчивой. Учитывая выбор между: 1) использованием устаревшей GCC, 2) переходом на современный GCC и вынуждением использовать лицензию, несовместимую с целями проекта, или 3) переходом на стабильный компилятор с лицензией BSD, решение было, вероятно, неизбежно. Имейте в виду, что это относится только к базовой системе и поддержке со стороны дистрибутива; ничто не мешает пользователю установить и использовать современный GCC на своей коробке FreeBSD.

ire_and_curses
источник
4
Указанный вами эталонный тест взят из старой версии Clang. Тесты для последних версий, кажется, последние версии ближе. Мои собственные исследования простых программ показали, что Clang 3.0 на пару процентов быстрее, чем GCC 4.6, но GCC на многопоточной версии был на 20% быстрее. phoronix.com/scan.php?page=news_item&px=MTA5Nzc - это более новый тест Phoronix.
Шон
6
«GCC не полностью совместим со стандартами»: нельзя ли использовать переключатели компилятора для обеспечения соответствия данному стандарту?
Джорджио
4
Прежде всего, не читайте слишком много в тестах Phoronix, или, скорее, не читайте их вообще. Во-вторых, верно, что GCC не полностью соответствует стандартам по умолчанию, если вы явно не укажете стандарт, если вы этого не сделаете, у него также будут включены расширения GNU, но это может показаться странной причиной для использования Clang вместо этого, так как они также реализуют наиболее часто используемые расширения GNU, потому что они стремятся к тому, чтобы Clang был пригоден для использования в качестве замены GCC.
Кириас
1
@ Джорджио: Нет. См. Пример gcc.gnu.org/c99status.html - это всего лишь C99 (которому сейчас 14 лет). Также gcc.gnu.org/onlinedocs/libstdc++/manual/status.html - clang имеет лучшую поддержку для обоих (я думаю, что она полная - и если нет, то она определенно, по крайней мере, лучше).
Тим Час
4
@Demizey Я не защищаю Фороникс, но если вы собираетесь что-то отклонить, вы должны хотя бы указать вескую причину.
Марио
38

Стоит учесть, что FreeBSD в настоящее время использует GCC 4.2.1, как отмечено в ответе ire_and_curses, поэтому сравнение производительности не составляет 4.5 или даже 4.6 и не имеет никакого отношения к проекту. Поэтому вопросы, которые вы должны задавать:

  1. Каковы прирост производительности нового Clang по сравнению со старым GCC, который использует проект?

  2. Как сравнить те же самые двоичные файлы, скомпилированные в GCC 4.2.1, с новым Clang?

Из-за перехода GCC на GPL v3 FreeBSD была вынуждена продолжать использовать GCC 4.2.1 (GPL v2), выпущенную еще в 2007 году, и в настоящее время значительно устарела.

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

Микель Кинг
источник
19

Несмотря на то, что GCC является GPLv3, полученные двоичные файлы, созданные GCC, никогда не имели каких-либо лицензионных ограничений. Ясно, что вы можете использовать GCC для создания программного обеспечения, которое подпадает под лицензию, которую вы хотите. Даже библиотека C, которая поставляется с GCC и включена в двоичный файл, не требует лицензий. http://www.gnu.org/licenses/gcc-exception-faq.html

Раздел 2 GNU GPLv3:

У вас есть разрешение на распространение произведения целевого кода, созданного путем объединения библиотеки времени выполнения с независимыми модулями, даже если такое распространение в противном случае нарушило бы условия GPLv3, при условии, что весь целевой код был сгенерирован с помощью допустимых процессов компиляции. Затем вы можете передать такую ​​комбинацию на условиях по вашему выбору , в соответствии с лицензированием независимых модулей.

«Приемлемый» означает, что компиляция не включает как GCC, так и GPL-несовместимое программное обеспечение. Это не ограничение: лицензионное программное обеспечение BSD может использоваться в процессе сборки с использованием GNU GCC.

Как вы можете видеть, вопреки сказанному выше, нет РЕАЛЬНОЙ причины, связанной с лицензией, отойти от GCC, поскольку нет несовместимости с использованием GCC во FreeBSD.

Настоящая причина этого изменения - политическая и оппортунистическая:

  • BSD имеет свое собственное лицензирование, которое философски конкурирует с публичной лицензией GNU (как объяснено выше * ire_and_curses *),
  • CLANG - это новый не-GPL-компилятор, инициированный спонсором FreeBSD, который, по-видимому, технически эквивалентен GCC, лицензированному под GPL (как описано выше в * ire_and_curses *).

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

Эрик
источник
5
Извините, я должен был проголосовать за это. К сожалению, ваше незнание BSD и программного обеспечения показывает. Просто для протокола, это было политическое, а не техническое решение, которое привело BSD от перехода от традиционного Portable C Compiler (PCC) к GCC в начале девяностых. Clang - это проект Apple! Как человек, который ежедневно использует GCC для жизни на OpenBSD и пытается вернуться на PCC, вы просто ошибаетесь во всех учетных записях.
Предраг Пуносевац
5
Речь идет не о конечных двоичных файлах, а о том, что gcc является частью FreeBSD - поэтому лицензионные ограничения имеют значение.
Сстн
3
Если религия проекта говорит: «Нет GPLv3», то технические аспекты исчезают - просто представьте, что они используют, например, компилятор Microsoft.
Турбьёрн Равн Андерсен
3
Это единственный ответ, который правильно указывает на это license of compiler != license of end product. Жалобы на лицензию компилятора не могут быть релевантными, если пользователь не понимает лицензию.
Брандин
6
Дело не в том, подпадают ли созданные двоичные файлы под GPLv3, а в том, требуют ли изменения самого компилятора соответствия GPLv3. Поставщики оборудования часто модифицируют стандартный компилятор, чтобы лучше работать со своим оборудованием или использовать преимущества аппаратного обеспечения проприетарными способами. Устранение риска того, что ваши пользовательские изменения должны соответствовать GPLv3 или риску судебного иска, является большой проблемой для таких организаций. Здесь действительно важна лицензия компилятора.
Дэвид Харкс
7

Я не эксперт, но я понимаю, что Clang / LLVM использует меньше ресурсов, чем GCC, и работает быстрее.

http://clang.llvm.org/features.html#performance

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

EightBitTony
источник
Незначительно ... и есть инструменты для дальнейшего сокращения времени повторяющейся компиляции - ccache.samba.org Не берите в голову очевидные возможности параллельной компиляции (см. Distcc), время компоновки, как правило, труднее решать в больших проектах
Rob11311
Да, очень хорошо, но получающийся двоичный код медленнее; p
rustyx
1
@rustyx не сравнивается с gcc 4.2!
Майлз Рут