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

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

rapso

meiner erfahrung nach sind java/vb/c# gute sprachen um quick&dirty was zu erreichen. Damit bekommt man gut 75% quality. Das ist nicht anders als wenn man SQL nutzt vs was eigenes.

Am ende ist die frage ob die 75% reichen oder nicht. Wenn du ein rennspiel, einen shooter, ein jump&run oder ein 2d fighting game machst, dann brauchst du wirklich stabile und gute framerate bei gleichzeitig gute graphik. spieler schreien foren voll zZ weil batman auf pc nur locked 30Hz laeuft und wenn man schnell reist, dass streaming zu sehen ist.
MC auf der anderen seite laeuft recht slow, popt an vielen stellen, ruckelt mal oefters etc etc. aber fuer casual gamer die mit bloecken ihre burg bauen wollen ist es ausreichend gut.
ich hatte eher aus versehen von anfang an den MC blog gelesen (und damals mit Notch gemailt) und neben dem entwickeln des spiels mit taeglich releases, neben den taeglichen videos, taeglichen blog eintraegen hatte er nocht zeit mit mir und hunderten anderen zu mailen.
MC ist so wie es ist, weil Notch sehr effizient arbeitet, vielleicht waere es das nicht ohne java geworden, aber zur gleichen zeit ist java wirklich nur ein puzzlestueck vom MC erfolg, den sogar die meisten die MC clonen brauchen viel viel laenger es zu entwickeln und machen nicht noch nebenbei die 100 dinge die Notch machte.

hustbaer

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.

Hm.
Das klingt jetzt so als meintest du dass der Java-Programmierer 3-5x produktiver ist beim Schreiben von eigenem Code als der C++ Programmierer. Was ich für Quatsch halte.
Er ist bloss schneller weil er viele Dinge bereits fertig im Framework oder Library XYZ drin hat. Und da sind Forumlierungen wie "3-5x" dann komisch, da man die Zeitersparnis kaum als Faktor ausdrücken kann. Kommt halt total drauf wie viele Sachen man braucht die es fergig gibt und wie viel Zeit man bei Java bzw. C++ damit verbringt diese zu suchen bzw. im Notfall selbst zu schreiben.

Davon abgesehen halte ich Java für ne halbwegs plumpe Sprache. Viele Dinge nerven da einfach nur, die man in C++ "einfach so macht". C# ist da schon wesentlich besser. Aber selbst C# nervt bei vielen Dingen einfach nur. Speziell was Resource-Management angeht. Was du in C++ mit shared_ptr hast kannst du z.B. weder in C# noch in Java vernünftig lösen: deterministische aber quasi vollautomatische Verwaltung von Resourcen.