Clang/FreeBSD bereit zum Testen

Kamikaze

Kamikaze

Warrior of Sunlight
Teammitglied
FreeBSD mit Clang als Compiler ist bereit zum Testen.

Clang ist ein C-Frontend für das LLVM (Low Level Virtual Machine) Compiler Framework.

GCC Versionen nach 4.2 unterliegen der GPLv3, dass heißt sie können nicht mehr in FreeBSD integriert werden, deshalb besteht eine gewisse Dringlichkeit Ersatz zu finden. Clang/LLVM steht unter BSD-Lizenz. LLVM wurde ursprünglich 2000 von Chris Lattner an der University of Illinois entwickelt. Später wurde Lattner von Apple übernommen und LLVM wird dort inzwischen intensiv eingesetzt, unter Anderem im OpenGL Stack und Xcode.

Abgesehen von der Lizenz haben Clang/LLVM eine Menge weiterer Vorteile gegenüber dem GCC, die auf der Homepage recht detailliert erläutert werden.

Quelle:
http://docs.freebsd.org/cgi/mid.cgi?20100416160818.GA69460
http://www.appleinsider.com/articles/08/06/20/apples_other_open_secret_the_llvm_complier.html
 
Zuletzt bearbeitet:
HI,


Wie weit ist das denn schon Produktiv Einsetztbar ?
Und kann ich die Ports damit auch schon builden ?

Ich denke ich werd mal ne VM aufsetzen und testen.
 
Ich mache erst einmal build performance tests. ClangBSD mit gcc bauen, ClangBSD mit clang bauen, das ganze mit und ohne make -j (llvm parallelisiert von sich aus, ich will wissen, was das für einen Unterschied macht).
 
Kamikaze schrieb:
Ich mache erst einmal build performance tests. ClangBSD mit gcc bauen, ClangBSD mit clang bauen, das ganze mit und ohne make -j (llvm parallelisiert von sich aus, ich will wissen, was das für einen Unterschied macht).
Zum Vergrößern anklicken....

Interessant wäre natürlich auch zu sehen wie sich die gebauten Kernel von der Performance her unterscheiden.
Vielleicht ist http://kernel-perf.sourceforge.net/about_tests.php hier ja was interessantes dabei um das mal zu messen.
 
base läuft ja schonmal

Irgendwer noch in der Lage, in dem -current Geraffel den mDNSResponder zu bauen?
Will sich ja irgendwie als Dependency von kde4 reinschleichen...
 
Kamikaze schrieb:
Ich mache erst einmal build performance tests. ClangBSD mit gcc bauen, ClangBSD mit clang bauen, das ganze mit und ohne make -j (llvm parallelisiert von sich aus, ich will wissen, was das für einen Unterschied macht).
Zum Vergrößern anklicken....

Wie sieht es aus? Haben deine Tests schon Erkenntnisse gebracht?
 
Ich hab mal Tests mit Scimark gemacht. Hardware ist ein Athlon II X2 2,8 Ghz.

Code: 
[b]gcc 4.2.1[/b]
Composite Score:          831.71
FFT             Mflops:   744.21    (N=1024)
SOR             Mflops:   652.51    (100 x 100)
MonteCarlo:     Mflops:   348.83
Sparse matmult  Mflops:  1118.48    (N=1000, nz=5000)
LU              Mflops:  1294.54    (M=100, N=100)

[b]clang[/b]
Composite Score:          832.03
FFT             Mflops:   756.82    (N=1024)
SOR             Mflops:   806.05    (100 x 100)
MonteCarlo:     Mflops:   294.93
Sparse matmult  Mflops:  1058.50    (N=1000, nz=5000)
LU              Mflops:  1243.86    (M=100, N=100)

[b]lli[/b]
Composite Score:          865.14
FFT             Mflops:   749.20    (N=1024)
SOR             Mflops:   806.05    (100 x 100)
MonteCarlo:     Mflops:   261.29
Sparse matmult  Mflops:  1149.12    (N=1000, nz=5000)
LU              Mflops:  1360.02    (M=100, N=100)

lli ist der JiT-Compiler von LLVM der Bytecode zur Laufzeit übersetzt.

Kompiliert wurde alles nur mit dem -O3 Flag.
 
Was ja auch schon mal gut ist, um als Ersatz in Frage zu kommen :) Außerdem ist Performance ja nicht das einzige Argument für LLVM ;)
 
Zuletzt bearbeitet:
Hi,

wie sind die lli Ergebnisse denn zu verstehen?
Heißt das, dass der Scimark zu Bytecode gebaut wird und erst zur Laufzeit ausgeführt wird oder betrifft das dann noch weitere Komponenten des Systems?
 
Der Sourcecode wird zu Bytecode "kompiliert" und dann durch einen JiT-Compiler ausgeführt.

Befehle hierfür:
clang -O3 -emit-llvm *.c -c
llvm-link *.o -o scimark.bc
lli -O3 scimark.bc

Also von der Art her ähnlich wie Java, nur das hier kein eigenes Speichermanagement vorhanden ist.
 
Zuletzt bearbeitet:
Hmm... habe schon von beidem gehoert. Ist der Unterschied signifikant? Leider habe ich unterm Semester keine Zeit damit herum zu experimentieren

Da er C99 konform ist, könnte man ihn zumindest bzgl. C doch tatsächlich vollständig als Ersatz verwenden, oder?

Woran happerts eigentlich noch überall? (ich meine bzgl. GCC raus, LLVM rein)
- Plattformsupport
- C++-Support
- Tools rundherum?

Wäre nett, wenn ihr ein wenig eurer Erfahrung mit mir teilt. :)

Mfg
 
vimix schrieb:
Da er C99 konform ist, könnte man ihn zumindest bzgl. C doch tatsächlich vollständig als Ersatz verwenden, oder?
Zum Vergrößern anklicken....

Naja ich sehe bei den sachen mit "Standard Konform" immer das problem, das vilee programmierer eine Art misch code schreiben, die halt noch bissl an alten sachen hängen, oder mal es nicht so mit dem Standard haben und da auch man sachen die GNU C sind drin laden. Da würde ich mir bei den ports sorgen machen ob er da auch überall zum einsatz kommen kann oder es da erstmal probleme geben kann. ( Ähnliches ist ja auch bei den Webbrowsern, das problem ist mehr die entwicklung des teils der erkennt, was der nutzer meint, wenn er nicht standard konform arbeitet)
 
Naja, das ändert erstmal nichts daran, dass der Compiler das erstmal sein muss.

Zum Misch-Code sage ich mal nichts außer, dass für mich persönlich 100%ig Std-konformer Code ein Qualitätsmerkmal ist, auf den ich immer achte. Dass das mit der Realität nichts zu tun hat, weiß ich :).
 
C++ Support ist noch Alpha (jedoch kann clang schon sich selbst und LLVM übersetzen -> 500000 Zeilen C++ Code). Aber LLVM ist recht simples C++ (soll ja einfach sein) und deswegen geht es schon. "Krankes Zeug" wie Boost geht halt noch nicht.

Weiterhin werden viele GCC-Erweiterungen noch nicht unterstützt, weshalb man es nicht so direkt für alles nehmen kann. Viele GNU-Programme setzen halt den GCC voraus. Dies sind meist Compiler-Makros. Auch gibt's hier und da natürlich diverse Bugs, dass das Programm zwar sauber kompiliert, aber im Endeffekt nicht funktioniert.

Aber man arbeitet aktiv daran. C und Objective-C sind schon als "Produktiv" gekennzeichnet.
 
Ich würde sagen, die Plattformen. Und sehr viele Ports funktionieren nicht damit. Bei ioquake3 werden bestimmte Dinge zum Beispiel einfach nicht gerendert.
 
Kamikaze schrieb:
Ich würde sagen, die Plattformen. Und sehr viele Ports funktionieren nicht damit.
Zum Vergrößern anklicken....


Würde es nicht reichen, wenn das basis System erstmal komplett und sauber mit Clang übersetzbar wird und dann in den ports wieder die GNU compiler zum einsatz kommen? Bzw. das der Clang compiler in der lage ist, den C compiler aus dem GCC zu bootstrappen, um dann in ports ohne den ärger leben kann, das man jeden port drauf anpassen muss dass er mit clang zusammen arbeitet?
 
Das geht schon. Aber eben nur unter amd64/i386. Das reicht natürlich nicht.
 
Kamikaze schrieb:
Das geht schon. Aber eben nur unter amd64/i386. Das reicht natürlich nicht.
Zum Vergrößern anklicken....

Jetzt mal nur so gesponnen.... würde es nicht rein theoretisch reichen die LLVM maschine zu portieren und die dann das System ausführen zu lassen? ( Ich bin nicht so eine von der Hardware nahen ecke um das selber beantworten zu können)
 
Theoretisch ja (bis auf Kernel, Treiber usw.), aber praktisch ist es (noch) nicht umsetzbar, da halt vieles noch nicht kompiliert und man alle Build- und Init-Skripte komplett neu schreiben müsste ;)

Wie gesagt, clang ist noch recht neu, aber schon verdammt weit. Da gibt's noch massenhaft Bugs die gefunden und behoben werden müssen.

LLVM bietet einerseits die Ausführung des Codes per JiT-Compiler, aber andererseits auch die spätere Kompilierung auf die Zielplattform. D.h. man bräuchte nur einen "richtig kompilierten" Kernel und dann überlässt man den Rest LLVM.

Da aber bisher weder LLVM noch FreeBSD (+Projekte) soweit sind, ist das alles noch wunschdenken und wird in nächster Zeit auch nicht umgesetzt. Das wäre aber mal ein schönes Forschungsprojekt. Ähnlich JNode (Betriebssystem fast komplett in Java geschrieben)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben