Dabei bin ich unter anderem auf diese Benchmark gestossen: http://www.kano.net/javabench/

Ich will bewusst nicht auf die unterschiedlichen gemessenen Werte eingehen (Flamewars gibs genug), sondern habe nur eine Verständnisfrage nach dem ich die Tests selber durchprobiert habe. Warum ist die Java Server VM so extrem viel schneller bei Methodenaufrufen (methcall Beispiel) als hochoptimierter C++ Code? Ich habe das C++ Beispiel mit sämtlichen GCC Konstellationen kompiliert und der Unterschied ist wirklich drastisch! Der G++ ist nun nicht der beste C++ Compiler, daher würden mich vorallem ICC und MS VC++ Ergebnisse auch mal interessieren.

Wie geht das, der HotSpotter kann doch auch nur Maschinencode für eine Architektur erzeugen? Ich denke ja, dass die VM einen Trick verwendet und den würde ich gerne in Erfahrung bringen. (Ab Eingabegrößen von 1000000000 wird es deutlich, bei zu kleinen Laufzeiten fällt der VM Start zu sehr ins Gewicht und der HotSpotter hat keine Chance zu optimieren)

Übrigens ist auf der Seite fairerweise auch das hier verklinkt.

Beim virtuellen Funktionsaufrufen kann ein HotSpot Compiler aber besser optimieren, da er den kompletten Code kennt. Wobei C++ Compiler mittlerweile auch optimierende Linker enthalten, die dem Problem teilweise entgegen wirken können.

Wie geht das, der HotSpotter kann doch auch nur Maschinencode für eine Architektur erzeugen?

http://java.sun.com/javase/technologies/hotspot/

.filmor schrieb:

Übrigens ist auf der Seite fairerweise auch das hier verklinkt.

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

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.

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

Optimierungen zur Laufzeit bieten halt mehr Möglichkeiten.

"Wie geht das, der HotSpotter kann doch auch nur Maschinencode für eine Architektur erzeugen?"

Theoretisch kann man dem ganz andere Dinge beibringen, z.B. könnte man ihn einen else if Block nach häufigkeit neu ordnen lassen. Also das die Bedingung die am häufigsten zutrifft an erster Stelle steht.
Kleine Schleifen kann man entfernen lassen ... usw.

Nunja, Möglichkeiten gibt es viele, wenn du wissen willst welche Sinn machen und welche die Java VM verwendet, oder weshalb es genau hier zutrifft, dann kann ich dir auch nicht helfen.

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.

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

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.

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

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)

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.

Muss man halt mal nen vernünftigen Compiler benutzen.

Wenn ich nen schlechten Hotspot habe, komme ich auch nicht weit.

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

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.

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.

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!

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?

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

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

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.

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?

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

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

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

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.

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?

hier ist ein Vortrag über llvm 2.0