Qualität von HotSpot Compilern

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.

Simon2

Undertaker schrieb:

...

It seems that it's much, much easier to create a well performing program in Java. So, please consider it for a moment before you start recoding your Java program in C++ just to make it faster...

..

Naja, eigentlich müsste es heißen:

Es ist für Java-Programmierer sehr viel leichter, in C++ unperformanten Code zu schreiben.

So Zeug wie unnötige Heap-Verwendung, falsche Stringverwendung oder "hash_map == map" passiert doch C++ern gar nicht.

Gruß,

Simon2.

Simon2 schrieb:

So Zeug wie unnötige Heap-Verwendung, falsche Stringverwendung oder "hash_map == map" passiert doch C++ern gar nicht.

genau die sind alle perfekt.

hustbaer

Jester schrieb:

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.

Schön dass du weisst dass ich das weiss

Und wo auf der einen Seite Leute 130MB aufn Stack legen wollen, gibt's auf der anderen Seite genug Leute die 4 Byte vom Heap holen

Simon2

zweipunktnull schrieb:

Simon2 schrieb:

So Zeug wie unnötige Heap-Verwendung, falsche Stringverwendung oder "hash_map == map" passiert doch C++ern gar nicht.

genau die sind alle perfekt.

Top Diskussionsbeitrag !!
maximale Emotions- und minimaler Informationsgehalt !