Qualität von HotSpot Compilern

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

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