3D-Performance C/OpenGL - Java3D



  • Hallo,

    Weiss jemand von euch, wie es um die Performance von Java3D steht? Java kann sich ja vielfach nicht gerade mit hoher Geschwindigkeit rühmen (vor allem im Bereich GUI), aber wie siehts mit Java3D aus? Ist das wesentlich langsamer als ein C++/OpenGL-Programm? Gibts da irgendwo ein direkter Vergleich?



  • durito schrieb:

    Hallo,

    Weiss jemand von euch, wie es um die Performance von Java3D steht? Java kann sich ja vielfach nicht gerade mit hoher Geschwindigkeit rühmen (vor allem im Bereich GUI), aber wie siehts mit Java3D aus? Ist das wesentlich langsamer als ein C++/OpenGL-Programm? Gibts da irgendwo ein direkter Vergleich?

    Wenn Du das von Sun "nachgeschobene" meinst, das wird AFAIK nicht mehr weiterentwickelt und ist noch völlig unterentwickelt (zumindest war's das zur eChess-Zeit vor ca. 1 Jahr, wo wir es eigentlich nutzen wollten).
    Auf Linux / Solaris und Co. steuerte es OpenGL an, auf Windows war GL und DX möglich, beides mit Pros und Cons.
    IMHHHO nicht besonders empfehlenswert. 👎

    Allerdings gibt es OpenGL-Bindings für Java.
    Zitat aus dem 3D-Center-Forum:

    Ich würde die OpenGL-Bindings für Java nicht so pauschal (vor-)verurteilen. Hier sind ein paar Links zu entsprechenden Foren, falls du dir einen Überblick verschaffen möchtest:

    http://www.javagaming.org/cgi-bin/J....cgi?board=jogl

    http://www.javagaming.org/cgi-bin/J...cgi?board=LWJGL

    Ich selber verwende LWJGL und habe da bisher eigentlich nichts vermisst (jedenfalls nicht was OpenGL angeht). Das Auslagern der rechenintensiven Prozesse ist sicher eine Option, aber ich würde weder Java noch C# vorschnell als "zu langsam" abtun. Ich kann z.B. in Java mit LWJGL wunderbar durch Level mit der Komplexität von Quake3 rennen und da ist auch durchaus noch mehr drin.

    IIRC sollte eins der beiden von Sun dann auch als "offizieller" Java3D-Ersatz mal übernommen werden, weil die genannten Bindings schon weit fortgeschrittener waren / sind.

    Alle Angaben natürlich weder mit Gewehr noch mit Gewähr... 🤡





  • Danke für die Links!
    Also ginge es eben doch auch mit Java..
    Existieren irgendwo Geschwindigkeits-Vergleiche zu OpenGL-Lösungen?



  • durito schrieb:

    Java kann sich ja vielfach nicht gerade mit hoher Geschwindigkeit rühmen

    Daraufhin wurde Java ja auch nicht entworfen...

    durito schrieb:

    Existieren irgendwo Geschwindigkeits-Vergleiche zu OpenGL-Lösungen?

    Öhhh... die Bindings SIND OPENGL-Lösungen...!! 😕



  • Sgt. Nukem schrieb:

    durito schrieb:

    Java kann sich ja vielfach nicht gerade mit hoher Geschwindigkeit rühmen

    Daraufhin wurde Java ja auch nicht entworfen...

    durito schrieb:

    Existieren irgendwo Geschwindigkeits-Vergleiche zu OpenGL-Lösungen?

    Öhhh... die Bindings SIND OPENGL-Lösungen...!! 😕

    Jup, ich mein C++/OpenGL-Lösungen.
    Es geht bei der ganzen Geschichte um ein Projekt (mit 3D-Output), welches auf ner SUN-Station läuft. Projektsprache ist scheinbar C++, und soweit ich weiss, soll Coin3D eingesetzt werden. Java wird eben aus Gründen der Geschwindigkeit nicht verwendet.
    Ist klar, dass Java nicht für schnelle Anwendungen entworfen ist, aber laut ct (19,21 /03) ist Java ja nun wirklich nicht langsam solange es um Berechnungen geht. Ich denke mal, es ist vor allem das GUI bzw. andere Schnittstellen zum BS, was Java so langsam macht..
    Ich frag mich, warum auf der SUN nicht Java eingesetzt wird.. Soviel kanns ja nciht ausmachen, wenn ne gute OpenGL-Lösung für Java existieren sollte.



  • durito schrieb:

    Sgt. Nukem schrieb:

    durito schrieb:

    Java kann sich ja vielfach nicht gerade mit hoher Geschwindigkeit rühmen

    Daraufhin wurde Java ja auch nicht entworfen...

    durito schrieb:

    Existieren irgendwo Geschwindigkeits-Vergleiche zu OpenGL-Lösungen?

    Öhhh... die Bindings SIND OPENGL-Lösungen...!! 😕

    Jup, ich mein C++/OpenGL-Lösungen.

    Ich wüsste keine!
    Ich wollte zwar schon seit Ewigkeiten mal einen Vergleich zwischen C++ / Delphi / C# und Java rausbringen, der auf 3D abzielt, aber hab' einfach keine Zitt... 😞

    Versuch Du's doch mal: Die C++ / Java Variante wenigstens.
    Das Drumherum muß man nur 1x für alle Benches machen, und die GL-Befehle kann man quasi 1:1 übernehmen...

    durito schrieb:

    Es geht bei der ganzen Geschichte um ein Projekt (mit 3D-Output), welches auf ner SUN-Station läuft. Projektsprache ist scheinbar C++, und soweit ich weiss, soll Coin3D eingesetzt werden. Java wird eben aus Gründen der Geschwindigkeit nicht verwendet.

    Kenne mich (leider) weder mit Workstations aus noch mit Coin3D.

    durito schrieb:

    Ist klar, dass Java nicht für schnelle Anwendungen entworfen ist, aber laut ct (19,21 /03) ist Java ja nun wirklich nicht langsam solange es um Berechnungen geht. Ich denke mal, es ist vor allem das GUI bzw. andere Schnittstellen zum BS, was Java so langsam macht..
    Ich frag mich, warum auf der SUN nicht Java eingesetzt wird.. Soviel kanns ja nciht ausmachen, wenn ne gute OpenGL-Lösung für Java existieren sollte.

    Über den genannten Artikel sind schon genug Flamewars gemacht worden! 🤡

    Tja, das letzte Quentchen bekommst Du mit C++ auf jeden Fall noch raus, und mit ASM dann nochmal...
    Die Frage ist nur das Kosten / Nutzen Verhältnis.
    In ASM werden ja auch nur noch wirklich oft und schnell benötigte Teile geproggt (es sei denn man heißt Sawyer und codet Rollercoaster Tycoon :p )...
    Ein echter praktischer Vergleich wäre mal net verkehrt, um mal zu sehen, wie viele Frames wirklich dabei flöten gehen...
    Und ob andere Sprachen in CPU-only Bereichen nicht sogar schneller sind (KI etc.) ...


Log in to reply