gibts doch schon ... such mal das Paket "gcc4" im aktuellen Fedora Core 3. Ist bislang allerdings optional (also noch nicht so ganz wie die gcc 2.96-Geschichte)
Um so später um so besser. Besonders bei einem Compiler sollte man lieber ein Vierteljahr länger testen, schließlich hängt davon wirklich das gesamte System ab. Wenn man sich vorstellt, was da der kleinste Fehler für Auswirkungen haben kann, kann einem Himmel Angst werden.
Habe mal einen Performancetest mit c++ gemacht: Wenn man alle Kompiliereinheiten separat übersetzt, also zum Schluss lauter .o Dateien verlinken muss, dann geht die Performance in den Keller, weil der Compiler nicht mehr inlinen kann - er müsste ja den binären Methodencode aus der Objektdatei extrahieren. Definiert man die Methoden direkt in der Klasse (vor allem bei getter und setter Methoden), dann erreicht man ein vielfaches an Performance, weil der Compiler tatsächlich inlinen kann und bei der Ausführung schließlich keine Funktionsaufrufe machen muss. In rechenintensive Algoithmen habe ich so die Laufzeit schon gedrittelt.
Hat jemand eine Ahnung, ob der neue gcc so etwas besser meistert? Gibt es überhaupt Compiler, die das können?
Im Kernel geht man dem umgekehrten Weg: Funktionen, die früher inline waren, sind es jetzt nicht mehr, zumindest größere Funktionen. Dadurch wird der Kernel kleiner, es paßt mehr davon in den Prozessorcache und die Gesamtperformance steigt, weil etwas weniger Cachelines zu ersetzen sind.
Andererseits ist klar, daß Inlining eine Menge Möglichkeiten für weitere Optimierungen bietet, daher dürfte bei Einzeilern Inlining fast immer sinnvoll sein.
Von Christoph Bartoschek am Mi, 16. März 2005 um 10:14 #
Es gibt schon Compiler, die das können.
In der Linuxwelt existiert da zunächst Intels icc. Gibt man beim Kompilieren die Option -ipo an wird Intermediate Code erzeugt, der dann beim Linken optimiert wird. Erst danach wird Maschinencode erzeugt. IBM's xlc müsste das auch können. Den habe ich bisher aber nur auf AIX damit ausprobiert. Die werden das aber aus der PowerPC Version für Linux bestimmt nicht rausgenommen haben.
Der GCC selbst kann das auf absehbare Zeit noch nicht, aber es gibt ein interessantes Projekt, dass sich jeder mal anschauen sollte. The LLVM Compiler Infrastructure basiert auf einem neueren GCC Frontend und kompiliert C/C++ Code in Bytecode, der dann in einer VM ausgeführt werden kann. Den Bytecode kann man jederzeit optimieren lassen: Beim Kompilieren, beim Linken, zur Laufzeit des Programms oder zwischen den Ausführungen unterstützt durch Ergebnisse eines Profilings. Der Bytecode kann jederzeit in echten Maschinencode kompiliert werden, so dass man keine Einbuße durch die VM hinnehmen muss. Ich habe jedoch in meinen Tests festgestellt, dass der Lauf in der VM nicht besonders viel Laufzeit kostet. Insgesamt konnte ich oft feststellen, dass das Ergebnis schneller war als das GCC-Kompilat.
Darum verwenden auch einige größere Projekte eine Buildmodus, in dem zuerst alle .cpp Dateien zu einer zusammengefasst werden (zumindest verzeichnisweise) und dann kompiliert werden. Bei configure heißt diese Option unter anderem --enable-final
Wie ist das denn dann mit der Kompatibilitaet. Wenn ich z.B. ein Projekt habe und auf meine Homepage vorkompilierte RPM/DEB-Files legen will, kann ich die mit gcc4 kompilieren und gehen die dann auch unter SuSE9.0 / Debian 3.0?
Bislang muss ich dann alles nochmal auf der Distrie durch den Compiler jagen,....
Kann da mal jemand etwas dazu sagen? Mache ich da immer was falsch?
Also soweit ich das bis jetzt sehe, ist das ABI stabil geblieben zu Version 3. Das soll aber nicht heißen, dass es bei größeren Projekten nicht doch Probleme geben kann.
Kann man nicht so pauschal sagen...... Ja klar Aber was kann sich der Laie darunter vorstellen?
Wird das gesamte Linuxsystem schneller laufen (und wie viel schneller?)? Werden einfache Anwendungen (100000 mal Hello World) davon profieren? Laufen Microcontroller schneller (interessiert mich besonders!)?
Ich bin zwar auch kein Experte, kann dir aber schon mal sagen, dass ein "hello world"-Programm dadurch nichts schneller wird. Was aber ein Compiler optimiert, lässt sich auch immer in Trivialbeispielen festhalten, die dann keine sonderlich großen Programme sind. So z.B. das entrollen von Schleifen (-funroll-loops) als ganz primitives Beispiel. Ob jetzt ein bestimmtes Optimierungsverfahren etwas bringt, hängt dann immer vom Programm und den darin verwendeten Algorithmen zusammen. So pauschal kann man das also nicht sagen. Vielleicht schreibt aber schon jemand mit mehr Ahnung noch etwas dazu.
http://gcc.gnu.org/c99status.html
SCNR
troll*an_red_hats_gcc-2.96/3.0-denkend*
Beim ersten Versuch gab es erhebliche Schwierigkeiten mit Qt, die aber nun behoben sind.
mfg: Jochen Schmitt
Du bist nah dran mit der bemerkung, Fedora Core 4 wird gcc4-basiert sein.
Nächstes Jahr, dieses ....
Thx
bei gentoo ist immer noch der 3.3.5 der "stabile"
Bei ~x86 ist es 3.4.3
Der ultimativ Test wird u. a. bei FC4-Devel durchgeführt, die die ganze Distributation auf den gcc4 umgestellt wird.
mfg: Jochen Schmitt
ftp://ftp.fu-berlin.de/unix/languages/gcc/snapshots/4.0-20050312
Hat jemand eine Ahnung, ob der neue gcc so etwas besser meistert? Gibt es überhaupt Compiler, die das können?
Grüße Boris
Andererseits ist klar, daß Inlining eine Menge Möglichkeiten für weitere Optimierungen bietet, daher dürfte bei Einzeilern Inlining fast immer sinnvoll sein.
Ja der Intel-Compiler kann dieses.
In der Linuxwelt existiert da zunächst Intels icc. Gibt man beim Kompilieren die Option -ipo an wird Intermediate Code erzeugt, der dann beim Linken optimiert wird. Erst danach wird Maschinencode erzeugt. IBM's xlc müsste das auch können. Den habe ich bisher aber nur auf AIX damit ausprobiert. Die werden das aber aus der PowerPC Version für Linux bestimmt nicht rausgenommen haben.
Der GCC selbst kann das auf absehbare Zeit noch nicht, aber es gibt ein interessantes Projekt, dass sich jeder mal anschauen sollte. The LLVM Compiler Infrastructure basiert auf einem neueren GCC Frontend und kompiliert C/C++ Code in Bytecode, der dann in einer VM ausgeführt werden kann. Den Bytecode kann man jederzeit optimieren lassen: Beim Kompilieren, beim Linken, zur Laufzeit des Programms oder zwischen den Ausführungen unterstützt durch Ergebnisse eines Profilings. Der Bytecode kann jederzeit in echten Maschinencode kompiliert werden, so dass man keine Einbuße durch die VM hinnehmen muss. Ich habe jedoch in meinen Tests festgestellt, dass der Lauf in der VM nicht besonders viel Laufzeit kostet. Insgesamt konnte ich oft feststellen, dass das Ergebnis schneller war als das GCC-Kompilat.
Bei configure heißt diese Option unter anderem --enable-final
Projekt habe und auf meine Homepage vorkompilierte RPM/DEB-Files
legen will, kann ich die mit gcc4 kompilieren und gehen die
dann auch unter SuSE9.0 / Debian 3.0?
Bislang muss ich dann alles nochmal auf der Distrie durch den
Compiler jagen,....
Kann da mal jemand etwas dazu sagen? Mache ich da immer was
falsch?
Ich meine, so flags wie
GLIBCPP_3.2 ...
oder
GLIBCPP_3.2
CXXABI_1.2
...
Danke fuer eine Info
Ja klar
Wird das gesamte Linuxsystem schneller laufen (und wie viel schneller?)?
Werden einfache Anwendungen (100000 mal Hello World) davon profieren?
Laufen Microcontroller schneller (interessiert mich besonders!)?
Schon mal danke für Eure Antworten
Mark
NikN