LLVM ist das nächste große Ding. Nach all den Jahren, wo man es hingenommen hat, dass der gcc so ist, wie er ist und man heimlich denkt, dass der Microsoft Visual C++ Compiler doch irgendwie besser war, taucht plötzlich LLVM mit clang im Gespann auf und schickt sich an die Welt zu erobern.
Wer von LLVM noch nie etwas gehört hat, dem kann ich einen ganz wunderbaren Podcast empfehlen. Kurz gesagt: die Low Level Virtual Machine ist eine Compiler Infrastruktur, ein Compiler-Baukasten. Es gibt verschiedene Frontends, die aus unterschiedlichen Eingabesprachen (z.B. C, Objective C, Fortran, in Ansätzen auch C++ ) einen Bytecode generieren. Dieser Bytecode wird optimiert und im letzten Schritt mittels eines Backends in nativen Maschinencode für eine konkrete Architektur übersetzt.
Diese Verarbeitung ist nicht etwa tief im Compiler verborgen, sondern kann ganz praktisch mittels Pipes zusammengebaut werden:
$ clang-cc file.c -emit-llvm -o - | llvm-as \ | opt -std-compile-opts | llc > file.s |
Neben dem Satz an Standard-Optimierungen kann man sich noch mehrere Dutzend Spezial-Optimierungen die heraussuchen, wenn man denkt, dass das eigene Programm die nötig hat. Optimierungen kosten natürlich Zeit und so ist man eher geneigt während der Entwicklung wenige Optimierungen zugunsten schneller Compilerzeiten zu wählen, während man im Release-Stadium mehr Optimierungen wählt um die Performance zu optimieren.
Natürlich möchte man nicht in all seine Makefiles jetzt auf solche Pipe-Orgien umstellen. Es gibt zum Glück ein „drop in replacement“ für den gcc: clang. Man muss nur noch an einer Stelle im Makefile die gcc-Definition durch clang ersetzen – fertig. Alle Parameter werden verstanden, Compiler-Parameter übernommen – so unkompliziert, dass man nur noch staunen kann:
# CC=gcc CC=clang $(CC) -o binary source.c $(CFLAGS) $(IFLAGS) |
Seit dem Podcast zu LLVM nagt in meinem Kopf die Idee, das ganze im aktuellen Projekt zu testen. In den beiden letzten Mobile Macs Sendungen war clang ebenfalls Thema, was dazu führte, dass heute das LLVM-Virus bei mir ausgebrochen ist 😉
Ich habe also das aktuelle Projekt (365.000-Zeilen C-Code) genommen und genau eine Zeile im Makefile geändert. Und es lief ohne Probleme. Ok, ich habe noch einen Fehler in unserem Makefile gefunden, aber dafür kann ja clang nichts. Die absolut problemlose Umstellung hat mich schon überrascht.
Aber warum sollte man dem gcc untreu werden, was bringt einem clang konkret? Da wären zunächst aussagekräftige Warnungen. Ich liebe Warnungen und predige bei jeder Gelegenheit wie wichtig es ist, auf die Warnungen vom Compiler zu hören. Das ist immer der Moment, in dem die Kollegen plötzlich etwas wichtigeres zu tun haben … 😉 clang spuckt Warnungen aus, mit denen man wirklich etwas anfangen kann:
src/source.c:457:15: warning: pointer types point to integer types with different sign passing 'unsigned char *', expected 'char const *restrict' [-Wpointer-sign]
fputs(pbuffer, stdout);
^~~~~~~ |
Dagegen die Meldung vom gcc:
src/source.c:457: warning: pointer targets in passing argument 1 of ‘fputs’ differ in signedness |
Dann wäre noch das Thema Performance. Es gibt Aussagen wie „OpenSSL wird 10% schneller“ (letzte MM-Sendung). Das macht schon neugierig und ich werde in der nächsten Woche auf jeden Fall ein paar Benchmarks durchführen um dem auf den Grund zu gehen. Jede Anwendung ist anders und bei unserem Projekt muss man erstmal sehen, was es wirklich bringt.
Wenn man aber „einfach so“ mehr Performance erhält, ist das ein hoch interessantes Thema. Ein Kunde von uns lastet mit unserer Anwendung eine 8-Core Maschine voll aus. Aufgrund gesteigerter Datenmengen wird diese Maschine bald zu klein sein. Wenn wir ihm sagen können „behalte Deinen Hobel, wir haben noch ordentlich etwas rausgeholt“ ist das für den Kunden natürlich ein Gewinn. Er kann die Hardware länger nutzen und spart Mirgrationskosten. Für uns ist das eher schlecht, weil wir am Lizenzupgrade nichts verdienen … aber ich bin Techniker und kein Verkäufer 😉