¿Por qué FreeBSD está despreciando a GCC a favor de Clang / LLVM?


241

Así que estaba navegando por la red y me topé con este artículo . Básicamente establece que FreeBSD , a partir de la Versión 10 y superior, desaprobará GCC a favor de Clang / LLVM .

Por lo que he visto hasta ahora en la red, Clang / LLVM es un proyecto bastante ambicioso, pero en términos de confiabilidad no puede igualar a GCC .

¿Hay alguna razón técnica por la que FreeBSD elige LLVM como su infraestructura de compilación, o todo se reduce a las eternas licencias GNU / GPL vs. BSD?

Esta pregunta tiene (de alguna manera) información relevante sobre el uso de GCC en FreeBSD

Respuestas:


361

Resumen: La razón principal para cambiar de GCC a Clang es la incompatibilidad de la licencia GPL v3 de GCC con los objetivos del proyecto FreeBSD . También hay cuestiones políticas relacionadas con la inversión corporativa, así como los requisitos de la base de usuarios. Finalmente, se esperan ventajas técnicas relacionadas con el cumplimiento de las normas y la facilidad de depuración. Las mejoras en el rendimiento del mundo real en la compilación y ejecución son específicas del código y discutibles; Se pueden hacer casos para ambos compiladores.

FreeBSD y la GPL: FreeBSD tiene una relación incómoda con la GPL. Los defensores de la licencia BSD creen que el software verdaderamente libre no tiene restricciones de uso . Los defensores de GPL creen que las restricciones son necesarias para proteger la libertad del software, y específicamente que la capacidad de crear software no libre a partir de software libre es una forma injusta de poder en lugar de una libertad. El proyecto FreeBSD, cuando sea posible, intenta evitar el uso de la GPL :

Debido a las complejidades adicionales que pueden evolucionar en el uso comercial del software GPL, sin embargo, nos esforzamos por reemplazar dicho software con envíos bajo la licencia más relajada de FreeBSD siempre que sea posible.

FreeBSD y la GPL v3: la GPL v3 prohíbe explícitamente la denominada Tivoización de código, una laguna en la GPL v2 que permitió que las restricciones de hardware impidieran las modificaciones legales de software de los usuarios. Cerrar esta escapatoria fue un paso inaceptable para muchos en la comunidad de FreeBSD:

Los proveedores de dispositivos en particular tienen más que perder si la gran cantidad de software actualmente licenciado bajo GPLv2 hoy migra a la nueva licencia. Ya no tendrán la libertad de usar el software GPLv3 y restringir la modificación del software instalado en su hardware ... En resumen, hay una gran base de consumidores de OpenSource que de repente están muy interesados ​​en comprender alternativas al software con licencia GPL.

Debido al cambio de GCC a la GPL v3, FreeBSD se vio obligado a seguir usando GCC 4.2.1 (GPL v2), que se lanzó en 2007 , y ahora está significativamente desactualizado. El hecho de que FreeBSD no se moviera para usar versiones más modernas de GCC, incluso con los dolores de cabeza de mantenimiento adicionales de ejecutar un compilador antiguo y correcciones de backport, da una idea de la fortaleza del requisito para evitar la GPL v3. El compilador de C es un componente importante de la base de FreeBSD, y " uno de los objetivos (tentativos) para FreeBSD 10 es un sistema de base libre de GPL ".

Inversión corporativa: al igual que muchos proyectos importantes de código abierto, FreeBSD recibe financiación y trabajo de desarrollo de corporaciones. Aunque la medida en que FreeBSD es financiada o desarrollada por Apple no se puede descubrir fácilmente, existe una superposición considerable porque el sistema operativo Darwin de Apple utiliza un código de núcleo sustancial originado en BSD . Además, Clang en sí era originalmente un proyecto interno de Apple, antes de ser de código abierto en 2007 . Dado que los recursos corporativos son un facilitador clave del proyecto FreeBSD, satisfacer las necesidades de los patrocinadores es probablemente un importante motor del mundo real .

Base de usuarios: FreeBSD es una opción atractiva de código abierto para muchas compañías, porque la licencia es simple, no restrictiva y es poco probable que genere demandas. Con la llegada de GPL v3 y las nuevas disposiciones contra la Tivoización , se ha sugerido que existe una tendencia acelerada, impulsada por el proveedor, hacia licencias más permisivas . Dado que la ventaja percibida de FreeBSD para las entidades comerciales radica en su licencia permisiva, existe una creciente presión de la base de usuarios corporativos para alejarse de GCC y de la GPL en general.

Problemas con GCC: además de la licencia, el uso de GCC tiene algunos problemas percibidos . GCC no es totalmente compatible con las normas, y tiene muchas extensiones que no se encuentran en la norma ISO C estándar . Con más de 3 millones de líneas de código, también es " uno de los proyectos de software más complejos y gratuitos / de código abierto ". Esta complejidad hace que la modificación del código a nivel de distribución sea una tarea desafiante.

Ventajas técnicas: Clang tiene algunas ventajas técnicas en comparación con GCC . Lo más notable son los mensajes de error mucho más informativos y una API diseñada explícitamente para IDEs, refactorización y herramientas de análisis de código fuente. Aunque el sitio web de Clang presenta gráficos que indican una compilación y un uso de memoria mucho más eficientes, los resultados del mundo real son bastante variables y, en general, están en línea con el rendimiento de GCC. En general, los binarios producidos por Clang se ejecutan más lentamente que los binarios equivalentes de GCC:

Si bien el uso de LLVM es más rápido en el código de construcción que GCC ... en la mayoría de los casos, los binarios construidos con GCC 4.5 tuvieron un mejor desempeño que LLVM-GCC o Clang ... en el resto de las pruebas, el rendimiento fue cercano al de GCC o bien detrás. En algunas pruebas, el rendimiento de los binarios generados por Clang fue simplemente horrible.

Conclusión: es muy poco probable que la eficiencia de la compilación sea un motivador significativo para correr el riesgo sustancial de trasladar un gran proyecto como FreeBSD a una cadena de herramientas de compilación completamente nueva, particularmente cuando falta el rendimiento binario. Sin embargo, la situación no era realmente sostenible. Dada la opción entre 1) ejecutar un GCC desactualizado, 2) Pasar a un GCC moderno y verse obligado a usar una licencia incompatible con los objetivos del proyecto o 3) mudarse a un compilador estable con licencia BSD, la decisión Probablemente era inevitable. Tenga en cuenta que esto solo se aplica al sistema base y al soporte de la distribución; nada impide que un usuario instale y use un GCC moderno en su caja de FreeBSD.


44
El punto de referencia que citó es de una versión anterior de Clang. Los puntos de referencia para versiones recientes parecen ser versiones recientes más cercanas. Mi propia investigación para programas simples puso Clang 3.0 un par de por ciento más rápido que GCC 4.6, pero GCC fue un 20% más rápido en la versión roscada. phoronix.com/scan.php?page=news_item&px=MTA5Nzc es un nuevo punto de referencia de Phoronix.
Sean

66
"GCC no es totalmente compatible con los estándares": ¿No es posible utilizar conmutadores de compilación para exigir el cumplimiento de un estándar determinado?
Giorgio

44
En primer lugar, no lea demasiado en los puntos de referencia de Phoronix, o más bien no los lea en absoluto. En segundo lugar, es cierto que GCC no es totalmente compatible con los estándares de manera predeterminada a menos que especifique explícitamente un estándar; si no lo hace, también tendrá habilitadas las extensiones GNU, pero esta parece ser una razón extraña para usar Clang, ya que ellos también están implementando las extensiones GNU más comúnmente utilizadas porque se esfuerzan por que Clang sea utilizable como una caída en el reemplazo de GCC.
kyrias

1
@Giorgio: No. Vea gcc.gnu.org/c99status.html para ver un ejemplo, y eso es solo C99 (que ahora tiene 14 años). También gcc.gnu.org/onlinedocs/libstdc++/manual/status.html : clang tiene un mejor soporte para ambos (creo que está lleno, y si no, definitivamente es al menos mejor).
Tim Čas

44
@Demizey No estoy defendiendo a Phoronix, pero si vas a descartar algo, al menos deberías proporcionar una razón válida.
Mario

38

Una cosa que vale la pena considerar es que FreeBSD actualmente está usando GCC 4.2.1 como se indica en la respuesta ire_and_curses, por lo que las comparaciones de rendimiento no son de 4.5 o incluso 4.6 no son realmente relevantes para el proyecto. Por lo tanto, las preguntas que debe hacer son:

  1. ¿Cuáles son las ganancias de rendimiento del nuevo Clang frente al GCC anterior que usa el proyecto?

  2. ¿Cómo se comparan los mismos binarios compilados en GCC 4.2.1 con el nuevo Clang?

Debido al cambio de GCC a la GPL v3, FreeBSD se vio obligado a seguir usando GCC 4.2.1 (GPL v2), que se lanzó en 2007, y ahora está significativamente desactualizado.

Si Clang va a la zaga del CCG actual, pero todavía está a años luz del CCG implementado en el proyecto, entonces su decisión de evolucionar está bien justificada y verdaderamente inspirada.


19

Aunque GCC es GPLv3, los binarios resultantes producidos por GCC nunca tuvieron ninguna restricción de licencia. En claro, puede usar GCC para crear software que se encuentre bajo la licencia que desee. Incluso la biblioteca C que viene con GCC y que está incluida en el binario no tiene licencia. http://www.gnu.org/licenses/gcc-exception-faq.html

Sección 2 de la GNU GPLv3:

Tiene permiso para propagar un trabajo de Código de destino formado mediante la combinación de la Biblioteca de tiempo de ejecución con módulos independientes, incluso si dicha propagación violaría los términos de GPLv3, siempre que todo el Código de destino fuera generado por Procesos de compilación elegibles. Luego puede transmitir dicha combinación bajo los términos que elija , de acuerdo con la licencia de los Módulos Independientes.

"Elegible" significa que la compilación no incluye software incompatible con GCC ni con GPL. Eso no es una restricción: el software con licencia BSD se puede utilizar en el proceso de compilación que involucra GNU GCC.

Como puede ver, al contrario de lo que se ha dicho anteriormente, no existe una razón REAL relacionada con la licencia para alejarse de GCC ya que no hay incompatibilidad con el uso de GCC dentro de FreeBSD.

La verdadera razón detrás de este cambio es política y oportunista:

  • BSD tiene su propia licencia que filosóficamente compite con la licencia pública GNU (como * ire_and_curses * explicado anteriormente),
  • CLANG es un nuevo compilador no GPL iniciado por un patrocinador de FreeBSD que parece ser técnicamente equivalente al GCC con licencia GPL (como se describe anteriormente por * ire_and_curses *).

Estos hechos crean una oportunidad para que FreeBSD se aleje de GCC y se deshaga de él: en realidad no están legalmente obligados a hacerlo, ya que bien podrían usar GCC para construir software gratuito o con licencia BSD, pero quieren apegarse a filosofía de "todo el software con licencia BSD".


55
Lo siento, tuve que votar por esto. Desafortunadamente, su falta de familiaridad con los BSD y los bajos de software se muestran. Solo para que conste, fue una decisión política, no técnica, lo que llevó a los BSD a cambiar de su tradicional compilador portátil C (PCC) a GCC a principios de los noventa. Clang es un proyecto de Apple! Como alguien que usa GCC diariamente para vivir en OpenBSD que está tratando de regresar a PCC, está equivocado en todas las cuentas.
Predrag Punosevac

55
No se trata de los binarios resultantes, se trata del hecho de que gcc es parte de FreeBSD, por lo tanto, las restricciones de licencia son importantes.
sstn

3
Si la religión del proyecto dice "No GPLv3", los aspectos técnicos se desvanecen; imagínese que estaban utilizando, por ejemplo, un compilador de Microsoft.
Thorbjørn Ravn Andersen

3
Esta es la única respuesta que señala correctamente eso license of compiler != license of end product. Las quejas sobre una licencia del compilador no pueden ser relevantes a menos que el usuario no entienda la licencia.
Brandin

66
No se trata de si los archivos binarios producidos se incluyen en GPLv3, sino de si los cambios en el compilador requieren el cumplimiento de GPLv3. Los proveedores de hardware a menudo modifican el compilador de stock para que funcione mejor con su hardware o aprovechen el hardware de forma patentada. Eliminar el riesgo de que sus cambios personalizados deben cumplir con GPLv3 o de que exista una acción legal de riesgo es un gran problema para tales organizaciones. Realmente es la licencia del compilador lo que importa aquí.
David Harks

7

No soy un experto, pero entiendo que Clang / LLVM usa menos recursos que GCC y es más rápido.

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

Si está ejecutando un entorno donde necesita construir muchas cosas, muchas veces, ese rendimiento puede convertirse en un ahorro real en costos de energía y tiempo. Si es real


Menor .. y no hay herramientas para reducir los tiempos de compilación más repetitivas - ccache.samba.org No importa las posibilidades obvias para la compilación parrallel (ver distcc), los tiempos de enlace tienden a ser más difíciles de resolver en grandes proyectos
Rob11311

Sí, muy bien, pero el código binario resultante es más lento; p
rustyx

1
¡@rustyx no se compara con gcc 4.2!
Miles Rout
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.