Er soll aber im Vergleich mit GCC kleiner und leichter verständlich und außerdem schneller sein.
Ich vermute mal hiermit die die Geschwindigkeit des Compilierens gemeint und nicht die Ausführungsgeschwindigkeit des erzeugten Codes. Kann mir mal jemand erklären, worin hier ein erwähnenswertes Feature steckt? Gibt es kritische Anwendungen, die ein möglichst schnelles Kompilieren erfordern? Mir ist da kein Szenario bekannt, noch kann ich mir da im Moment etwas vorstellen. Aber vielleicht kann hier jemand Licht ins Dunkel bringen
Ich könnte mir vorstellen, dass speziell bei OpenBSD und NetBSD mehr und häufiger "selbst compiliert" wird als anderswo (auch mehr als bei FreeBSD). Quasi wie bei Gentoo im Linux-Umfeld. Und dann schont es möglicherweise die Nerven, wenn der Compiler selbst etwas schneller läuft.
Ports bzw. Pkgsrc bieten immer noch die akt. Programmversionen an, sinnvoll wäre das schon, alleine um den Prozess des Erstellens/Qualitätskontrolle zu verkürzen. Bei NetBSD laufen noch Build-Farms die tägliche ISO-Installer-Images erstellen für alle Ports.
Ok, das ist ein Punkt. Aber dafür gibt es ja auch verschiedene Optimierungseinstellungen bei anderen Compilern. Bei kleinerer Optimierung kompiliert's da ja auch schneller.
BTW: Dürfte Parallelisierung nicht den größten Geschwindigkeitsgewinn bieten? Oder ist das sowieso ein Standardfeature?
Der GCC wird auch deshalb benutzt, weil man eben nicht nur ausführbaren Kode erzeugt, sondern vorher auch noch optimiert. Ich kann mir nicht vorstellen, dass der PCC das Niveau erreicht. Und der GCC ist in der Optimierung dem Intel-Compiler bei weitem nicht ebenbürtig.
Clang wird aktiv von MacOS und FreeBSD vorangetrieben, PCC von OpenBSD und ein versprengten Helfern innerhalb der NetBSD- und Solaris-Community etc. Nebenbei setzt Clang setzt LLVM vorraus und legt seine Prioriäten anders. PCC soll wartbar und portabel sein, also genau das Gegenteil von GCC ;-)
PCC soll wartbar und portabel sein, also genau das Gegenteil von GCC
Wartet mal ab, bis am PCC aktiv so lange entwickelt worden ist, wie am GCC. Desweiteren, mal schauen wie lange die angeblichen GCC-Killer aktiv bleiben. *zurücklehn-und-GCC-weiterbenutz*
> Ziel der freien BSD-Distributionen ist es, die aus ihrer Sicht weniger liberale Lizenz GPL aus dem Basissystem herauszuhalten
Das ist ein bißchen zu grob vereinfacht. Daß der GCC immer unter der GPL2 stand, hat den BSD-Leuten zwar nicht gefallen, aber mangels Alternative war er fester Bestandteil aller BSD-Systeme. Dann wechselten die Entwickler zu GPL3. Diese Lizenz bereitet anscheinend gerade den kommerziellen Nutzern der BSD-Systeme arge Probleme, auch sonst wird sie als zu restriktiv empfunden und es besteht Unsicherheit bzgl. rechtlicher Fallstricke, wenn man so etwas in ein BSD-System integriert. Auch Apple schien davon betroffen, denn sie fingen an, das Konkurrenzprodukt Clang zu fördern - und nun hört man auch gute Neuigkeiten von PCC. Momentan verwenden die BSD-Systeme noch GCC 4.2.1, den letzten mit GPL2; aber der veraltet halt schnell. In der nächsten FreeBSD-Version soll schon Clang der Standardcompiler sein. Die OpenBSD-Entwickler versuchen sogar, ihren gesamten Quellcode compilerunabhängig zu schreiben, so daß man frei wird wählen können.
Wo verursacht bei der kommerziellen Nutzung die GPLv3 Probleme? Der GCC ist doch ein ganz normales Anwendungsprogramm und ich bin sicher, dass noch mehr GPL-Programme mit BSD ausgeliefert werden.
Geht wohl um Optimierungen die der Compiler mit einbaut die eigentlich unter der GPL stehen. Die einen sagen es ist Ok und die anderen sagen was anders.
Nein, nicht die Optimierungen. Die sind frei, ebenso wie alles, was der Compiler ausspuckt. Nur die Verwendung des GCC wird durch die GPL3 eingeschränkt.
Sie verbietet z. B. das Absperren der Hardware, auf der die Software (hier: der GCC) läuft. Sonst dürfte der Benutzer zwar die Software verändern, könnte sie aber auf dem Gerät nicht laufen lassen.
Wenn ein GPL3-Programm DRM-Maßnahmen implementiert, darf jeder diese Maßnahmen straflos "knacken" und den Crack weitergeben. (Das ist wohl für den GCC bedeutungslos.)
Wer ein GPL3-Programm schreibt, gewährt automatisch völlige Patentfreiheit, d. h. er kann diesbezüglich keine Ansprüche geltend machen.
Na, irgendeinen Vorteil muss man doch anführen… jedenfalls für die, die nichts gegen die GPL haben.
Ich könnte mir vorstellen, dass speziell bei OpenBSD und NetBSD mehr und häufiger "selbst compiliert" wird als anderswo (auch mehr als bei FreeBSD). Quasi wie bei Gentoo im Linux-Umfeld. Und dann schont es möglicherweise die Nerven, wenn der Compiler selbst etwas schneller läuft.
Ports bzw. Pkgsrc bieten immer noch die akt. Programmversionen an, sinnvoll wäre das schon, alleine um den Prozess des Erstellens/Qualitätskontrolle zu verkürzen.
Bei NetBSD laufen noch Build-Farms die tägliche ISO-Installer-Images erstellen für alle Ports.
Ich freue mich über jedes bisschen Geschwindigkeit. Wenn man am Entwickeln ist, dann ist eben die Zeit beim kompilieren das nervigste.
Ok, das ist ein Punkt. Aber dafür gibt es ja auch verschiedene Optimierungseinstellungen bei anderen Compilern. Bei kleinerer Optimierung kompiliert's da ja auch schneller.
BTW: Dürfte Parallelisierung nicht den größten Geschwindigkeitsgewinn bieten? Oder ist das sowieso ein Standardfeature?
Parallelisierung im Compiler ergibt eigentlich keinen Sinn. Um Multicores auszunutzen parallelisiert man den Buildprozess (make -j).
Der GCC wird auch deshalb benutzt, weil man eben nicht nur ausführbaren Kode erzeugt, sondern vorher auch noch optimiert. Ich kann mir nicht vorstellen, dass der PCC das Niveau erreicht. Und der GCC ist in der Optimierung dem Intel-Compiler bei weitem nicht ebenbürtig.
der tiny c compiler ist bei meinen tests wesentlich schneller...
was ist mit clang? der ist auch unter bsd?
Clang wird aktiv von MacOS und FreeBSD vorangetrieben, PCC von OpenBSD und ein versprengten Helfern innerhalb der NetBSD- und Solaris-Community etc.
Nebenbei setzt Clang setzt LLVM vorraus und legt seine Prioriäten anders.
PCC soll wartbar und portabel sein, also genau das Gegenteil von GCC ;-)
*zurücklehn-und-GCC-weiterbenutz*
Mist, gilt natürlich auch für CLANG.
Dürfte aber lange dauern, bisher arbeitet nur ein Hauptentwickler dran.
> Ziel der freien BSD-Distributionen ist es, die aus ihrer Sicht weniger liberale Lizenz GPL aus dem Basissystem herauszuhalten
Das ist ein bißchen zu grob vereinfacht. Daß der GCC immer unter der GPL2 stand, hat den BSD-Leuten zwar nicht gefallen, aber mangels Alternative war er fester Bestandteil aller BSD-Systeme. Dann wechselten die Entwickler zu GPL3. Diese Lizenz bereitet anscheinend gerade den kommerziellen Nutzern der BSD-Systeme arge Probleme, auch sonst wird sie als zu restriktiv empfunden und es besteht Unsicherheit bzgl. rechtlicher Fallstricke, wenn man so etwas in ein BSD-System integriert.
Auch Apple schien davon betroffen, denn sie fingen an, das Konkurrenzprodukt Clang zu fördern - und nun hört man auch gute Neuigkeiten von PCC.
Momentan verwenden die BSD-Systeme noch GCC 4.2.1, den letzten mit GPL2; aber der veraltet halt schnell. In der nächsten FreeBSD-Version soll schon Clang der Standardcompiler sein. Die OpenBSD-Entwickler versuchen sogar, ihren gesamten Quellcode compilerunabhängig zu schreiben, so daß man frei wird wählen können.
Wo verursacht bei der kommerziellen Nutzung die GPLv3 Probleme? Der GCC ist doch ein ganz normales Anwendungsprogramm und ich bin sicher, dass noch mehr GPL-Programme mit BSD ausgeliefert werden.
War nicht mal was, GCC infiziert Programme mit der GPLv3 durch das reine übersetzen.
Ich glaube das Problem ist eher die Ablehnung von Softwarepatenten in der GPLv3.
Geht wohl um Optimierungen die der Compiler mit einbaut die eigentlich unter der GPL stehen. Die einen sagen es ist Ok und die anderen sagen was anders.
Nein, nicht die Optimierungen. Die sind frei, ebenso wie alles, was der Compiler ausspuckt. Nur die Verwendung des GCC wird durch die GPL3 eingeschränkt.
Siehe z. B. hier.
Das dürfte auch die Abneigung Apples erklären.