Um wie viel langsamer ist die Verwendung von Java anstatt C++ bei einer Anwendung, die OpenGL nutzen soll?

Gibt es da ungefähre Erfahrungswerte oder Schätzwerte, die einem das in Prozent vorstellen lassen?

Minecraft verwendet z.B. die Lightweight Java Game Library (JWJGL). Diese ermöglicht es, eine native OpenGL Implementierung von Java aus zu nutzen.

Wie groß ist hier aber der Overhead?
Wie viel Performance in Prozent hätte man gewonnen, wenn Minecraft direkt in C++ implementiert worden wäre?

Wenn man via Java sowieso die 3d Beschleunigungsfunktionen von OpenGL nutzt, hat das dann eigentlich überhaupt noch irgendeine Bedeutung, also vom Performanceverlust her oder kann man sagen, dass der Overhead völlig vernachlässigbar ist?

Eine große Hilfe wäre hier, gibt es vielleicht irgendwelche Benchmarks, die das direkt vergleichen?

Also eine 3d Szene, die OpenGL verwendet, einmal in C++ realisiert und einmal in Java mit jwjgl?

Dann noch eine weitere Frage.

Ist Rust schon ready um damit OpenGL Anwendungen zu entwickeln?
Rust hätte den Vorteil, dass kein GC im Weg wäre.

Und dann noch eine wichtige Frage.

Ist der GC eigentlich überhaupt noch ein großes Problem, auf Mehrkern CPUs?

volkard

Performancefrage schrieb:

Ist der GC eigentlich überhaupt noch ein großes Problem, auf Mehrkern CPUs?

2000% bleiben 2000%. Oder haste das Gefühl, die Grafik von Minecraft sei einigermaßen aktuell oder der Rechner würde sich dabei langweilen?

volkard schrieb:

Performancefrage schrieb:

Ist der GC eigentlich überhaupt noch ein großes Problem, auf Mehrkern CPUs?

2000% bleiben 2000%. Oder haste das Gefühl, die Grafik von Minecraft sei einigermaßen aktuell oder der Rechner würde sich dabei langweilen?

MC verwendet AFAIK noch displayLists, keine VBOs.

Wenn der Vergleich fair sein soll, dann muss man das also berücksichtigen.
Außerdem limitiert bei MC hauptsächlich die GPU.

DocJunioR

öhm ööhh..
Also ehrlich, mir ist keine reine java-implementierung von openGL bekannt. Das sind am Ende alles wrapper die am Ende doch wieder auf den binärimplementierungen des Betriebssystems sitzen. Das Programm sagt, hier sind deine Vertize, hier deine Matritzen und nun mach was draus. Der Rest ist eine DLL oder .so und eine Grafikkarte..
Der Flaschenhals ist da ganz und gar nicht das bisschen Interpretationsarbeit der VM. Wenn da eine Abweichung ist, liegt die maximal im einstelligen Prozentbereich.

dot

Kann man so allgemein nicht sagen, es hängt stark davon ab, was genau du vorhast. Aus persönlicher Erfahrung kann ich von der Verwendung von Sprachen wie Java und C# für OpenGL/Direct3D Anwendungen allerdings nur abraten. Auch wenn die Performance in einfachen Anwendungen oft noch OK ist, so macht die Garbage Collection in diesen Sprachen das Ressourcenmanagement zur Hölle. Ich würds jedenfalls nie wieder tun...

hustbaer

DocJunioR schrieb:

Das Programm sagt, hier sind deine Vertize, hier deine Matritzen und nun mach was draus. Der Rest ist eine DLL oder .so und eine Grafikkarte..
Der Flaschenhals ist da ganz und gar nicht das bisschen Interpretationsarbeit der VM. Wenn da eine Abweichung ist, liegt die maximal im einstelligen Prozentbereich.

Kommt drauf an wie oft das Programm sagt "hier sind deine Vertices" etc.
Wenn das einige zigtausend mal pro Frame passiert, dann kann das schon reinhauen.
Aktuelle Spieleentwickler beschweren sich ja auch dass DX selbst so einen grossen Overhead macht, aus native Programmen raus aufgerufen.

hustbaer

Performancefrage schrieb:

Ist der GC eigentlich überhaupt noch ein großes Problem, auf Mehrkern CPUs?

Grundsätzlich ja.
Jede mir bekannte GC Implementierung hat immer noch eine "stop the world" Phase. Und wenn der GC Heap gross genug ist, dann kann diese auch ordentlich lange dauern - auch gerne mal ne Sekunde oder mehr.

hustbaer

Performancefrage schrieb:

Außerdem limitiert bei MC hauptsächlich die GPU.

Möglich.
Aber warum erwähnst du das? Was willst du damit sagen?
Ich kann dir jedes Spiel so umschreiben dass es GPU limitiert ist. Dazu reicht es sämtliche Shaderprogramme unnötig kompliziert zu machen und vielleicht noch ein paar nette Optimierungen rauszuwerfen.
Was jetzt nicht heissen soll dass ich Minecraft für schlecht optimiert halte. Ich meine damit nur: nur weil es ein Spiel gibt das GPU limitiert ist, heisst das ja nicht dass der Teil der auf der CPU stattfindet für jedes Spiel unkritisch wäre.

DocJunioR schrieb:

öhm ööhh..
Also ehrlich, mir ist keine reine java-implementierung von openGL bekannt.

Du bist auch völlig am Thema vorbei. Von einer Implementierung von OpenGL in Java war nirgends die Rede.

hustbaer schrieb:

Performancefrage schrieb:

Ist der GC eigentlich überhaupt noch ein großes Problem, auf Mehrkern CPUs?

Grundsätzlich ja.
Jede mir bekannte GC Implementierung hat immer noch eine "stop the world" Phase. Und wenn der GC Heap gross genug ist, dann kann diese auch ordentlich lange dauern - auch gerne mal ne Sekunde oder mehr.

Danke für die Antwort.

Welche Möglichkeiten gibt es, den GC von Java zu beeinflussen bzw. die Auswirkungen des GC gering zu halten?

hustbaer schrieb:

Performancefrage schrieb:

Außerdem limitiert bei MC hauptsächlich die GPU.

Möglich.
Aber warum erwähnst du das? Was willst du damit sagen?
Ich kann dir jedes Spiel so umschreiben dass es GPU limitiert ist.

Wenn die GPU limitiert, dann ist die Programmiersprache nicht das Problem.
Die Programmiersprache arbeitet auf der CPU und schiebt der GPU die Daten rüber.
Die GPU macht ihr Zeugs, nativ, da ist keine JVM im Spiel.

Ich meine damit nur: nur weil es ein Spiel gibt das GPU limitiert ist, heisst das ja nicht dass der Teil der auf der CPU stattfindet für jedes Spiel unkritisch wäre.

Ja, das ist schon klar.

So weit ich das jetzt aus diversen Quellen rausgelesen habe, ist Java okay, wenn das Spiel GPU lastig, aber nicht CPU lastig ist.
Braucht man aber viel CPU Leistung, dann ist C++ meist die bessere Wahl.

TyRoXx

Java ist erfunden worden, damit mittelmäßige Programmierer einfache Probleme eigenständig lösen können. Dass am Ende überhaupt etwas herauskommt, ist für langweilige Unternehmensanwendungen wichtiger als Effizienz.

Grafisch anspruchsvolle Spiele sind schwierig und werden von eher guten Programmierern umgesetzt. Wenn die Performance zu schlecht ist oder das Spiel etwas schlechter aussieht als die Konkurrenz, wird es in der Lust zerrissen.

hustbaer

Grundsätzlich: GC Heap klein halten (MB, das was nach der Collection übrig bleibt) und möglichst wenig Müll erzeugen (MB/s).
Das dumme dabei ist, dass dich diese Optimierungen zwingen unsauber zu programmieren.
Dazu gibt es aber sicher einige Artikel im Internet.

Auf die schnelle mal 'was was ich z.T. Minecraft gefunden habe:
http://www.reddit.com/r/programming/comments/2jsrif/optifine_dev_minecraft_18_has_so_many_performance/

hustbaer

@Performancefrage
Naja, wie sehr ein Spiel CPU-lastig ist hängt z.T. auch damit zusammen wie viel oder wenig es versucht die GPU zu entlasten.
In C++ hast du da einfach mehr Spielraum, d.h. wenn du siehst dass du GPU-bound bist, kannst du zumindest mal gucken ob es Verfahren gäbe mit denen du die GPU entlasten kannst. z.B. besseres Occlusion Culling.

Ich würde generell kein Spiel in Java schreiben wollen. Ich sehe zwar durchaus einige Teile wo ich eine Sprache wie Java oder C# praktisch fände (speziell wegen der umfangreichen Library). Aber was man sich damit langfristig für Performance-Probleme einhandelt sieht man ja an Beispielen wie Minecraft.

Aber gut, man muss das halt immer abwägen. Time-to-Market ist oft ein wesentlicher Faktor. Bzw. auch der Gesamtaufwand in Personentagen den man sich für ein Projekt bis zum 1. Release leisten kann. Und da können Java & Co. natürlich punkten.

Java scheint mit Java 10 Value Types und List<int> zu bekommen, das dürfte bei einigen Anwendungsfällen für einen deutlichen Performanceboost sorgen.
Siehe z.B. auch hier:
http://literatejava.com/java-language/value-types-list-int-coming-java-10/

Vielleicht kommen Value Types auch schon in Java 9. Die Newsmeldungen sind da widersprüchlich, allerdings sind die, die sagen, das Value Types in Java 9 reinkommen aktueller.
Bei der generischen Liste mit primitiven Datentypen weiß ich es nicht.

Aber das hört sich doch schon einmal gut an, denn Value Types landen auf dem Stack und nicht auf dem Heap. Das dürfte den GC deutlich entlasten.

hustbaer schrieb:

Aber gut, man muss das halt immer abwägen. Time-to-Market ist oft ein wesentlicher Faktor. Bzw. auch der Gesamtaufwand in Personentagen den man sich für ein Projekt bis zum 1. Release leisten kann. Und da können Java & Co. natürlich punkten.

Das ist der Punkt, der meiner Meinung nach für Java spricht. Denn bezüglich dem Zeitaufwand den man in den Code reinstecken muss, ist man da im Schnitt 3-5 mal effizienter.
Dagegen sprich halt, das ein Teil der Zeitersparnis wieder fürs Memory Management drauf geht, also das man so programmiert, dass der GC nicht so stark stört.

Hier gibt's noch ein paar weitere Infos zu dem Thema:

https://en.wikipedia.org/wiki/Project_Valhalla_(Java_language)

Mechanics

Performancefrage schrieb:

Das ist der Punkt, der meiner Meinung nach für Java spricht. Denn bezüglich dem Zeitaufwand den man in den Code reinstecken muss, ist man da im Schnitt 3-5 mal effizienter.

Würde ich nicht behaupten. Ich bin jetzt nicht unbedingt der Java Experte, aber ich hab an paar Java Projekten mitgearbeitet und noch an keinem wirklich erfolgreichen. Das waren zwar J2EE Projekte und keine Spiele, aber ständig war irgendwas, was nicht so funktioniert hat, wie wir wollten und wo wir ewig suchen oder viel umbauen mussten. Und mit der Performance gabs auch paar mal Probleme, wo wir was umbauen mussten.
Und Java ist mehr oder weniger prädestiniert für J2EE (oder wie auch immer das mittlerweile heißt) Business Anwendungen, bei Spielen seh ich überhaupt keinen Vorteil gegenüber C++.