Qualität von HotSpot Compilern

rüdiger

Artchi schrieb:

Auch der GCC 3.3.1 20030930 der in dem oben genannten Benchmark benutzt wurde?

AFAIK kann der das seit der 3.0er Serie. Aber was bringt das, wenn der Typ das (inklusive anderer Optimierungen) nicht nutzt?

Artchi schrieb:

Das macht man dann, wenn man eine Release-Version baut. Und selbst wenn das täglich ist, sowas wird (hoffentlich) automatisiert auf einem Build-Server gebaut. Was sollte ich dadurch "verlieren"? Netter Versuch!

Und ich dachte wir reden hier über Optimierungen zur Laufzeit

Undertaker

rüdiger schrieb:

Artchi schrieb:

http://msdn2.microsoft.com/en-us/library/Aa289170.aspx
http://www.intel.com/cd/software/products/asmo-na/eng/278834.htm#pgo
Muss man halt mal nen vernünftigen Compiler benutzen.
Wenn ich nen schlechten Hotspot habe, komme ich auch nicht weit.

Das hat der GCC auch

dass irgend ein GCC das erstere kann (PGO), will ich mal bezweifeln.

rüdiger

Undertaker schrieb:

rüdiger schrieb:

Artchi schrieb:

http://msdn2.microsoft.com/en-us/library/Aa289170.aspx
http://www.intel.com/cd/software/products/asmo-na/eng/278834.htm#pgo
Muss man halt mal nen vernünftigen Compiler benutzen.
Wenn ich nen schlechten Hotspot habe, komme ich auch nicht weit.

Das hat der GCC auch

dass irgend ein GCC das erstere kann (PGO), will ich mal bezweifeln.

Schau doch einfach in der Dokumentation nach oder gib bei Google GCC PGO ein.

hustbaer

Artchi schrieb:

Tellerrand schrieb:

Natürlich ist das immer eine Entscheidung aus verschiedenen Fakten:
- wieviel verliert man durchs monitoring
- wieviel verliert man durchs kompilieren
- wieviel gewinnt man durch die Optimierung
- wann ist die Optimierung wieder dahin

Das macht man dann, wenn man eine Release-Version baut. Und selbst wenn das täglich ist, sowas wird (hoffentlich) automatisiert auf einem Build-Server gebaut. Was sollte ich dadurch "verlieren"? Netter Versuch!

Nö, da hast du was falsch verstanden.

Es geht hier um Optimierungen *zur Laufzeit* die ein JIT Compiler selbst macht.
Release-Versionen und Build-Server haben damit rein garnichts zu tun.

Und klar kostet das auch Zeit, denn die VM muss ja irgendwie Kandidaten ermitteln (Funktionen, Schleifen, allgemein Codestellen) die unter den aktuellen oder erwarteten Bedingungen neu optimiert & übersetzt werden sollen, dann müssen sie neu übersetzt werden etc. Wie gesagt: Laufzeit, nix Buildserver.

Solche Optimierungen kann man z.B. mit PGO für genau 1 Szenario machen, bzw. einen "Mix" aus mehreren Szenarien, die aber vor dem 2. PGO Compilerlauf feststehen müssen. Das Resultat bleibt statisch und wird daher ein Kompromiss sein. Eine VM mit JIT Compiler und dynamic-recompilation kann die aktuelle Situation erfassen (das ist z.B. das was er mit Monitoring meint), und den Code zur Laufzeit anpassen. -> weniger Kompromisse, dafür mehr Overhead.

Badestrand

rüdiger schrieb:

Gibt ja mittlerweile auch bei vielen C++ Compilern die Möglichkeit das Projekt so zu kompilieren, dass das Programm Laufzeit Informationen sammelt, die man beim optimierten kompilieren dann nutzen kann. Das ist natürlich entsprechend aufwendig.

Hast du da was konkretes? Oder gibts da beim VS irgendein Tool?

hustbaer

VS *ist* das Tool. Profile Guided Optimization heisst das, und das ist es was die Leute hier mit PGO meinen.

Keine Ahnung ob das in der Express Version mit drin ist, aber die normale Professional hat das.
Ganz im Gegensatz zum Profiler der ja der Team Foundation Dings Version vorbehalten ist *grrr*.

Artchi

Hast du da was konkretes? Oder gibts da beim VS irgendein Tool?

Habe doch die zwei Links gepostet zu den PGO-Infos.

Artchi

Tellerrand schrieb:

Artchi schrieb:

Das macht man dann, wenn man eine Release-Version baut. Und selbst wenn das täglich ist, sowas wird (hoffentlich) automatisiert auf einem Build-Server gebaut. Was sollte ich dadurch "verlieren"? Netter Versuch!

Und ich dachte wir reden hier über Optimierungen zur Laufzeit

Sorry, habe gedacht du beziehst dich auf PGO.

thordk schrieb:

java verwendet eine sehr viel rigidere syntax als c++. das sorgt dafür, dass ein java "compiler" stärke annahmen darüber treffen kann, was wegoptimiert werden kann und was nicht.

Mir wollten sie was anderes erzählen, dass das nix mit der Syntax zu tun hat usw...
http://www.c-plusplus.net/forum/viewtopic-var-p-is-1332096.html#1332096
Was stimmt denn nun?

rüdiger

btw. llvm will ich hier nicht unerwähnt lassen, da es bereits Link-Time-Optimierungen ermöglichst und auch JIT-Kompilierung (und das für alle Sprachen des verwendeten GCC-Frontends) und es ist in aktiver Benutzung, ua. von Apple (die wohl viel Geld in llvm stecken)) und Adobe. Derzeit werden aber leider noch keine C++-Exceptions unterstützt, was sich wohl mit llvm 2.1 (angekündigt für sept 07) ändern wird.

hier ist ein Vortrag über llvm 2.0

.filmor

C++-Exceptions werden schon unterstützt (zumindest kompiliert ein Programm von mir mit Exceptions problemlos), im Vortrag ist aber die Rede von "Zero Cost Exception Handling", was auch immer das heißen mag.

Aber irgendwie ist der Coding-Stil von llvm suspekt. Viel zu viele Zeiger.

rüdiger

.filmor schrieb:

C++-Exceptions werden schon unterstützt (zumindest kompiliert ein Programm von mir mit Exceptions problemlos), im Vortrag ist aber die Rede von "Zero Cost Exception Handling", was auch immer das heißen mag.

Aber irgendwie ist der Coding-Stil von llvm suspekt. Viel zu viele Zeiger.

Er spricht ja auch von DWARF. Also dem Debugging-Format. Naja, was genau dahinter steckt weiß ich nicht. Ich habe mich aber auch mit LLVM noch nicht sonderlich auseinander gesetzt.

@rüdiger LLVM sieht sehr interessant aus! Jetzt habe ich erstmal zusammen mit GCC PGO erstmal zwei neue Spielwiesen gefunden.

BTW: Ich habe nochmal eine C++ bezogene Frage zu der Benchmark. Bei dem methcall Beispiel wurde bei dieser Implementierung aus den Objekten auf dem Heap, Objekte auf dem Stack gemacht (auf denen letztendlich die Aufrufe stattfinden). Ist der Perfromanceunterschied so drastisch zwischen Objekten auf dem Stack und Heap? Ich dachte immer das beides identisches wäre. Oder habe ich die Veränderung(en) an dem Source Code nicht verstanden?

rüdiger

Ben 04 schrieb:

BTW: Ich habe nochmal eine C++ bezogene Frage zu der Benchmark. Bei dem methcall Beispiel wurde bei dieser Implementierung aus den Objekten auf dem Heap, Objekte auf dem Stack gemacht (auf denen letztendlich die Aufrufe stattfinden). Ist der Perfromanceunterschied so drastisch zwischen Objekten auf dem Stack und Heap? Ich dachte immer das beides identisches wäre. Oder habe ich die Veränderung(en) an dem Source Code nicht verstanden?

Theoretisch gibt es keinen Unterschied, außer bei der Erstellung/Löschung. Aber andererseits sorgen Pointer dafür, dass viele Optimierungen nicht durchgeführt werden können.

siehe zB http://www.cellperformance.com/mike_acton/2006/06/understanding_strict_aliasing.html

Artchi

@ben04! Ja, es macht einen Unterschied. Bei Stack-Objekten muß halt die Speicherverwatung nicht "einspringen". Bei Heap-Objekten muß im Normalfall das Betriebssystem einspringen und einen Speicherbereich "suchen" und deinem new diesen zuweisen. Also, die Arbeit beim Anlegen und Zerstören von Objekten auf dem Heap ist aufwändiger. Beim Stack ist es praktisch kostenlos.

Du kannst new dann schneller machen, wenn du einen anderen Allokator benutzt, speziell für deine Anwendungsfälle. Das geht ja zum Glück bei C++. Die meisten C++-Std-Libs haben aber logischwerweise einen allgemeingültigen Allokator implementiert.

DEvent

rüdiger schrieb:

Ben 04 schrieb:

BTW: Ich habe nochmal eine C++ bezogene Frage zu der Benchmark. Bei dem methcall Beispiel wurde bei dieser Implementierung aus den Objekten auf dem Heap, Objekte auf dem Stack gemacht (auf denen letztendlich die Aufrufe stattfinden). Ist der Perfromanceunterschied so drastisch zwischen Objekten auf dem Stack und Heap? Ich dachte immer das beides identisches wäre. Oder habe ich die Veränderung(en) an dem Source Code nicht verstanden?

Theoretisch gibt es keinen Unterschied, außer bei der Erstellung/Löschung. Aber andererseits sorgen Pointer dafür, dass viele Optimierungen nicht durchgeführt werden können.

siehe zB http://www.cellperformance.com/mike_acton/2006/06/understanding_strict_aliasing.html

Die Erstellen/Loeschung ist ja ueberhaupt das was den Stack von dem Heap unterscheidet

hustbaer

Pointer Aliasing wurde schon erwähnt, das betrifft nicht nur Heap Objekte sondern Stack Objekte genauso. Sobald mal irgendwo die Adresse des Stack Objektes "rausgegangen ist" (an eine Funktion übergeben die der Compiler nicht analysieren kann oder will) muss er annehmen dass auch andere Zeiger auf das Objekt existieren.

Der Hauptunterschied ist für mich aber immernoch dass man bei Stack Objekten eben den Heap nicht bemühen muss - denn der Heap ist halt langsam. Speziell unter Windows mit MSVC

Kennt C++ etwa kein restrict?

Jester

hustbaer schrieb:

Der Hauptunterschied ist für mich aber immernoch dass man bei Stack Objekten eben den Heap nicht bemühen muss - denn der Heap ist halt langsam. Speziell unter Windows mit MSVC

Du meinst sicherlich die Allokation auf dem Heap, die ist langsam. Der Zugriff ist ja letztlich immer gleich schnell, egal ob Stack oder Heap.
Und ja, ich weiß dass Du das auch weißt... trotzdem haben wir immer wieder Threads, wo Leute aus Performance-Gründen ihre 130MB-Arrays auf den Stack legen wollen, weil's schneller ist.