"Runtime Overhead" durch Virtuele Maschinen (Java/.net) in Zeiten von Just in Time Compilern und modernen CPUs

[Runtime Overhead]

Was ist dran an dem Thema?

Lohnt es sich heute noch eine komplexe große Endanwendersoftware (z.b. ein CAD Programm) in einer nativ kompilierenden Sprache, wie z.B. C++ zu schreiben
oder sind die Computer und VMs inzwischen so weit, daß kein bedeutender Runtime Overhead mehr besteht, der eine Entwicklung eines komplett neuen Projekts in einer kompilierenden Sprache rechtfertigt?

Dazu auch folgendes Kommentar: (es ist nicht von mir, ich hab's nur gefunden)

Die "Runtime Overhead" wird heutzutage etwas überbewertet. Schon vor
einigen Jahren hatte die c't durch Versuche nachgewiesen, dass
Managed Code Java/C# nicht signifikant langsamer ist als un-managed
code C++. Die heutige Hardware vermindert zudem die "Runtime
Overhead" Problematik immer weiter.
Die Diskussion ähnelt der Diskussion von vor 20 Jahren, als es darum
ging, ob Compiler performanteren Code erstellen können, als nativ
ASM-Programmierer.

http://www.heise.de/newsticker/foren/S-Runtime-Overhead/forum-191821/msg-19657061/read/

[Runtime Overhead]

Hab was vergessen.
Sollte heißen:

"in einer nativ kompilierenden Sprache rechtfertigt? "

[__--]

Runtime Overhead schrieb:

Die Diskussion ähnelt der Diskussion von vor 20 Jahren, als es darum ging, ob Compiler performanteren Code erstellen können, als nativ ASM-Programmierer.

und damals wie heute lautet die antwort: NEIN!

[__--]

und es geht doch dabei nicht nur um performance... es geht um möglichkeiten und größe. für mich ist java/c# wie sex mit gummi.

[gastantwort]

Runtime Overhead schrieb:

Lohnt es sich heute noch eine komplexe große Endanwendersoftware (z.b. ein CAD Programm) in einer nativ kompilierenden Sprache, wie z.B. C++ zu schreiben

Nein. Endegelände.

[__--]

gastantwort schrieb:

Runtime Overhead schrieb:

Lohnt es sich heute noch eine komplexe große Endanwendersoftware (z.b. ein CAD Programm) in einer nativ kompilierenden Sprache, wie z.B. C++ zu schreiben

Nein. Endegelände.

LOL, so ein bullshit!

[llllllllllllooooooooooool]

C++ vs. Java/C#, das hatten wir ja schon mindestens 1 Woche nicht mehr. Gähn.

[Compet]

Also ich hab' grade ein mehrwöchiges Duell mit einem guten Freund, es geht uns
dabei um die Entwicklung einer UCI Schach-Engine.
Mein Freund wird für seine Engine ein stark objektorientiertes Design + JAVA
verwenden,
während ich zeitgleich eine (antiquierte, nativ-kompilierte) C-Engine bastle
(die zu allem Überdruss auch nicht sonderlich objektorientert ist).
Er wird dann versuchen, mit seiner OOP-JAVA-JIT Engine meine altbackene C-Engine
in einem mehrrundigen Blitz-(5 min.)-Wettkampf zu besiegen.
Natürlich haben wir gleichzeitig mit der Programmierung (Ende Dezember) begonnen, Deadend wäre der 1.März 2011.

Werde mich gerne im März wieder melden, um vom Ausgang unseres kleinen Wettstreits:

-----------------------------
OOP+JAVA+JIT
vs.
Prozedural+C+Nativ-Kompiliert
-----------------------------
Thema: (UCI-)Schach-Engine
-----------------------------

zu berichten.

Wetten/Prognosen auf den mutmaßlichen Sieger werden ab sofort angenommen !

(Wie auch immer es ausgehen wird - wir geben beide unser Bestes!
Inwieweit man dann daraus die richtigen Rückschlüsse auf die Über-/Unterlegenheit des JAVA-JIT-Compilers gegenüber dem nativen C-Compiler
ziehen wird können, wissen wohl nur die Experten ...)

[__--]

Compet schrieb:

(Wie auch immer es ausgehen wird - wir geben beide unser Bestes!
Inwieweit man dann daraus die richtigen Rückschlüsse auf die Über-/Unterlegenheit des JAVA-JIT-Compilers gegenüber dem nativen C-Compiler
ziehen wird können, wissen wohl nur die Experten ...)

wennst dich zocken lässt, hack ich dir die finger ab

[geben Sie einen Benu]

Compet schrieb:

Also ich hab' grade ein mehrwöchiges Duell mit einem guten Freund, es geht uns
dabei um die Entwicklung einer UCI Schach-Engine.
Mein Freund wird für seine Engine ein stark objektorientiertes Design + JAVA
verwenden,
während ich zeitgleich eine (antiquierte, nativ-kompilierte) C-Engine bastle
(die zu allem Überdruss auch nicht sonderlich objektorientert ist).
Er wird dann versuchen, mit seiner OOP-JAVA-JIT Engine meine altbackene C-Engine
in einem mehrrundigen Blitz-(5 min.)-Wettkampf zu besiegen.
Natürlich haben wir gleichzeitig mit der Programmierung (Ende Dezember) begonnen, Deadend wäre der 1.März 2011.

Werde mich gerne im März wieder melden, um vom Ausgang unseres kleinen Wettstreits:

-----------------------------
OOP+JAVA+JIT
vs.
Prozedural+C+Nativ-Kompiliert
-----------------------------
Thema: (UCI-)Schach-Engine
-----------------------------

zu berichten.

Wie spielen die gegeneinander?

[Compet]

-> Mit der GUI von Fritz 11 (Dort kann man UCI-Engines gegeneinander spielen
lassen)

[krümelkacker]

Vorweg: Ich kenne beide Seiten, habe 7 Jahre lang hauptsächlich Java programmiert und dann für meine jetzten "number chrunching"-Anwendungen auf C++ gewechselt (seit 3 Jahren).

Das mit den JIT-Compilern ist schon toll. Aber das relativ hohe Abstraktionsniveau der Virtual Machine und all das "definierte Verhalten" dürfte sich immer noch negativ auf die Performance auswirken. Da gibt es zum einen speicherfressende Eigenschaften, um Dinge wie Reflection zu ermöglichen, auch wenn man so etwas in einem konkreten Fall gar nicht braucht. Und zum anderen gibt es Bremsen wie Nullzeiger-Checks, Array-Index-Checks, Erzwungenes Late-Binding (gut, das lässt sich größtenteils durch "final" reduzieren) und die Tatsache, dass man eben alle Objekte dynamisch anlegen muss und sich dabei kaum um Dinge wie Cache-Lokalität kümmern kann.

In C++ bist Du einfach näher an der Maschine - JIT hin oder her.

[loks]

Compet schrieb:

Wetten/Prognosen auf den mutmaßlichen Sieger werden ab sofort angenommen !

Die Wette geht an den besseren Programmierer... Nach meiner Erfahrung hat die Wetware immer noch den größten Einfluß auf das Ergebnis. Oder anders formuliert: Man kann auch in C langsame Programme schreiben...

[knivil]

Wenn OpenGl z.B. fuer CAD-Software benutzt wird, dann wuerde ich eine compilierte Sprache vorziehen. Im besonderen Fall von Java mache ich mich zusaetzlich von Oracle abhaengig, vielleicht bekommt man spaeter nur die Jit-Engine beim Kauf einer Lizenz. Das waere schlecht. Weiterhin bekommt man Jit meist nur fuer x86-Plattformen, will man fuer etwas anderes entwickeln, so wird es schwierig.

[Muahaha]

Compet schrieb:

Also ich hab' grade ein mehrwöchiges Duell mit einem guten Freund, es geht uns
dabei um die Entwicklung einer UCI Schach-Engine.
Mein Freund wird für seine Engine ein stark objektorientiertes Design + JAVA
verwenden,
während ich zeitgleich eine (antiquierte, nativ-kompilierte) C-Engine bastle
(die zu allem Überdruss auch nicht sonderlich objektorientert ist).
Er wird dann versuchen, mit seiner OOP-JAVA-JIT Engine meine altbackene C-Engine
in einem mehrrundigen Blitz-(5 min.)-Wettkampf zu besiegen.
Natürlich haben wir gleichzeitig mit der Programmierung (Ende Dezember) begonnen, Deadend wäre der 1.März 2011.

Werde mich gerne im März wieder melden, um vom Ausgang unseres kleinen Wettstreits:

-----------------------------
OOP+JAVA+JIT
vs.
Prozedural+C+Nativ-Kompiliert
-----------------------------
Thema: (UCI-)Schach-Engine
-----------------------------

zu berichten.

Wetten/Prognosen auf den mutmaßlichen Sieger werden ab sofort angenommen !

(Wie auch immer es ausgehen wird - wir geben beide unser Bestes!
Inwieweit man dann daraus die richtigen Rückschlüsse auf die Über-/Unterlegenheit des JAVA-JIT-Compilers gegenüber dem nativen C-Compiler
ziehen wird können, wissen wohl nur die Experten ...)

Was fürn Quatsch.

Wer gewinnt wird doch nicht durch die Programmiersprache entschieden, sondern nur durch die KI Algorithmen. D.h. wer den besseren Gegner schreibt.

Vergleichbar wird das doch nur, wenn der Gegner genau gleich gut implementiert wird, aber dann die Denkzeiten zur Entscheidungsfindung für die Spielzüge der begrenzende Rahmen sind.

DANN kommt es nämlich wirklich darauf an, welche Sprache schneller die letzten endes richtige Entscheidung findet, bevor die Zugzeit abgelaufen ist.

[Experte65]

Mein Tipp:
Bei so rechen-intensiven Anwendungen wie Schach spielen Dinge wie kluges
Caching, 64-Bit-Bitboard Operationen u.ä. eine derart vordergründige Rolle,
dass Dein Java-Freund auch bei noch so exzellenter, objektorientierter
Programmierung gegen eine 'reine', nativ kompilierte C Engine (die auch
weitestgehend die selben Algorithmen implementieren müsste (um überhaupt
vergleichbar zu sein!)) keine Chance haben dürfte und idR nicht annähernd an
die üblichen Suchtiefen eines C/C++ Schachprogramms herankommen wird.
Allgemein vermute ich, dass bei so rechenintensiven Problemstellungen
wie Schach (aber-trillionen mögliche Folgestellungen schon nach wenigen
Zügen) wohl auch C++ wegen dem Overhead mit den Containern nicht gut brauchbar
ist und erheblich schlechter als C abschneiden dürfte.
Bei solchen hochperformanten Sachen führt wohl einfach kein Weg an C vorbei,
weil damit kann man dann auch noch jede Schleife manuell entrollen usw.
um auch wirklich noch die allerletzte Nano-Sekunde an Performance rauszuholen.
Wünsche trotzdem Euch beiden viel Glück mit Euren Projekten
Und vielleicht könnt ihr die Resultate dann ja auch zum Ausprobieren ins Netz
stellen (am besten mit Quell-Code).
mfg

[blubbb]

Experte65 schrieb:

Mein Tipp:
Bei so rechen-intensiven Anwendungen wie Schach spielen Dinge wie kluges
Caching, 64-Bit-Bitboard Operationen u.ä. eine derart vordergründige Rolle,
dass Dein Java-Freund auch bei noch so exzellenter, objektorientierter
Programmierung gegen eine 'reine', nativ kompilierte C Engine (die auch
weitestgehend die selben Algorithmen implementieren müsste (um überhaupt
vergleichbar zu sein!)) keine Chance haben dürfte und idR nicht annähernd an
die üblichen Suchtiefen eines C/C++ Schachprogramms herankommen wird.
Allgemein vermute ich, dass bei so rechenintensiven Problemstellungen
wie Schach (aber-trillionen mögliche Folgestellungen schon nach wenigen
Zügen) wohl auch C++ wegen dem Overhead mit den Containern nicht gut brauchbar
ist und erheblich schlechter als C abschneiden dürfte.
Bei solchen hochperformanten Sachen führt wohl einfach kein Weg an C vorbei,
weil damit kann man dann auch noch jede Schleife manuell entrollen usw.
um auch wirklich noch die allerletzte Nano-Sekunde an Performance rauszuholen.
Wünsche trotzdem Euch beiden viel Glück mit Euren Projekten
Und vielleicht könnt ihr die Resultate dann ja auch zum Ausprobieren ins Netz
stellen (am besten mit Quell-Code).
mfg

Tja, die Nanosekunden bringen halt garnix, sondern nur der bessere Algorithmus gewinnt.

[Marc++us]

Experte65 schrieb:

wohl auch C++ wegen dem Overhead mit den Containern nicht gut brauchbar ist und erheblich schlechter als C abschneiden dürfte.

Kannst Du das mit dem Overhead der Container etwas ausführen?

[KuhTee]

Experte65 schrieb:

Mein Tipp:
[...]blabla[...]

Sorry, aber im grossen und ganzen ist das bullshit. Ist nicht persönlich gemeint, einfach nur fakt.

[Gregor]

@Threadersteller:

Java ist inzwischen bei vielen Dingen wirklich schnell, es gibt aber auch Aufgaben, in denen Java schnell mal um einen Faktor 10 langsamer als C++ ist. Das liegt aber nicht an einem "Runtime Overhead", sondern an anderen Aspekten der Sprache und ihrer Umsetzung.

Wenn man sich bewusst ist, an welchen Stellen die Sprache Schwachstellen bezüglich der Erzeugung performanten Codes hat, dann kann man damit definitiv auch relativ schnellen Code schreiben. Wenn man das nicht weiß, dann tappt man aber schnell in so eine Performancefalle und das Programm wird lahm.

Das betrifft übrigens nicht nur Java, sondern auch jede andere Sprache.

C++ hat auch derartige Performancefallen, in die man tappen kann. Aber dort ist es oft leichter, diese Fallen zu umgehen. Deshalb ist C++ Code weiterhin tendenziell schneller. Ich würde schätzen, im Schnitt um einen Faktor 1,5 oder so. Wenn dieser Faktor irrelevant ist, dann kann man ein Programm von diesem Gesichtspunkt her in beiden Sprachen schreiben. Es gibt aber auch Programme, die einfach so schnell wie möglich sein müssen.