Qualität von HotSpot Compilern

Undertaker

Tellerrand schrieb:

Theoretisch kann ein HotSpot Compiler auch manche Methodenaufrufe komplett entfernen/ersetzen, Rücksprünge vermeiden, etc.

naja, das ist ja nichts, wozu ein C++ compiler/linker nicht auch fähig wäre. statische optimierungen eben, zur not erzeugt man mehrere executables für unterschiedliche maschinentypen.

Tellerrand schrieb:

Optimierungen zur Laufzeit bieten halt mehr Möglichkeiten.

richtig. eine hotspot-vm kann sich dynamisch an die momentanen bedingungen anpassen. das ist etwas, was alle unterschätzen, die sagen 'Java ist doch lahm'.

thordk

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.

das heisst nicht, dass java grundsätzlich schneller ist, aber in c++ muss man sich teilweise sehr stark an "regeln" des verwendeten compilers orientieren, um solche ergebnisse zu erreichen. ob ein methoden aufruf polymorph sein muss oder nicht, kann man in c++ "frei" entscheiden (die sind teuer) und ein compiler kann zur compilezeit nicht entscheiden, ob auf polymorphie verzichtet werden kann. ein hotspot compiler kann das. wäre für c++ theoretisch auch möglich, aber da c++ keine virtual machine verwendet, kann sowas halt nicht zur laufzeit entschieden werden (bzw. nur schwerlich)

rüdiger

.filmor schrieb:

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...

Ja? Da spricht doch nichts gegen. Man braucht halt schon ordentlich Erfahrung, um anständigen C++-Code zu erdenken. Der ist dann aber auch mit Sicherheit schneller als das Java-Äquivalent.

Bitte kommt gar nicht erst auf diese Ebene, was wie wo besser ist. Java-Flames hatten wir genug. Beiträge in die Richtung werde ich entfernen oder den Thread zu machen!

.filmor schrieb:

Undertaker schrieb:

rüdiger schrieb:

Wobei C++ Compiler mittlerweile auch optimierende Linker enthalten, die dem Problem teilweise entgegen wirken können.

ja, theoretisch müsste ein C++ compiler es hinbekommen, unnötige polymorphie rauszuschmeissen.

Nein. Wie denn auch? Wenn der Programmierer virtual will, dann bekommt er virtual. Das sagt der Standard. Und der hat Recht.
Es kann schließlich sein, dass in irgendeinem erstmal vom Programm unabhängigen Teil die Polymorphie genutzt wird (zb in einer Modul-DLL).

Der Compiler kann doch durchaus einen virtuellen Aufruf umgehen, wenn er sich sicher sein kann, dass der Aufruf eindeutig ist. Ein Linker könnte auch einen VTable ganz entfernen, wenn er unnötig ist. Das so etwas bei einer DLL nicht gemacht wird, ist dann natürlich klar.

Tellerrand schrieb:

Optimierungen zur Laufzeit bieten halt mehr Möglichkeiten.

Tun sie das? Zum einen verbraten sie Prozessorzeit (was sich natürlich rentieren kann wenn das Programm länger läuft), zum Anderen fallen mir nicht viele Sachen ein, die /nur/ zur Laufzeit möglich sind.

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. Aber dafür kann ein Laufzeit Optimierer wiederum nicht so viel optimieren, da er ja zeitliche Limits hat, in denen die Optimierung statt finden muss.

Artchi

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.

rüdiger

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

Artchi

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

Undertaker

.filmor schrieb:

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...

Ja? Da spricht doch nichts gegen. Man braucht halt schon ordentlich Erfahrung, um anständigen C++-Code zu erdenken. Der ist dann aber auch mit Sicherheit schneller als das Java-Äquivalent.

das will ich ja gar nicht bezweifeln, aber dieses 'Man braucht halt schon ordentlich Erfahrung' ist doch gerade das, was ich immer anprangere in den 'Undertaker gegen C++ threads'.

.filmor schrieb:

Undertaker schrieb:

rüdiger schrieb:

Wobei C++ Compiler mittlerweile auch optimierende Linker enthalten, die dem Problem teilweise entgegen wirken können.

ja, theoretisch müsste ein C++ compiler es hinbekommen, unnötige polymorphie rauszuschmeissen.

Nein. Wie denn auch? Wenn der Programmierer virtual will, dann bekommt er virtual. Das sagt der Standard. Und der hat Recht.

okay, das mag ja so sein, aber wenn der compiler bzw. linker 'erkennt', dass ein echter virtual function call unnötig ist, warum soll er ihn nicht wegoptimieren dürfen?
schliesslich kommt es doch nur darauf an, dass das endprodukt(programm) sich exakt so verhält, wie's vom programmierer gewünscht wird.

.filmor schrieb:

Tellerrand schrieb:

Optimierungen zur Laufzeit bieten halt mehr Möglichkeiten.

Tun sie das? Zum einen verbraten sie Prozessorzeit (was sich natürlich rentieren kann wenn das Programm länger läuft), zum Anderen fallen mir nicht viele Sachen ein, die /nur/ zur Laufzeit möglich sind.

Ich sagte sie bieten mehr Möglichkeiten, das ist Fakt und mehr habe ich nicht gesagt.
Eine Kosten Nutzen Rechnung werde ich hier nicht diskutieren, welche und wie viele Möglichkeiten nun wie gut sind habe ich nicht gesagt

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

Und das ist auch oft eine Frage des Programms.
Eine einfache Variable die an vielen Stellen eines sehr großen Programms verrechnet wird, aber z.B. höchstens alle 6 Monate geändert wird (Z.B. eine Einstellung in der hinterletzten Ecke eines Programms) kann eine Bremse sein. Bei einem kleinem Programm würde man sich um sowas garkeine Gedanken machen.

Artchi

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!

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