Java

[Leonhard]

Ich find Java foll ***.

Ich find's einfach zu Langsam. Und dann fährend der Ausführung ruckt es: sind wir hier in der Steinzeit? Es währe doch möglich, Java-Code in Assember zu übersetzen und im Speicher auszuführen. Das würde alles schneller machen, aber nein, ...

Java ist Java: Langsam, Ruckelnd aber auf jeder Platform laufend. Aber das mit der Plattformunabhängigkeit kann man ja auch besser Regeln. Ich will da gar-nicht erst mit dem Speicher-Verbrauch anfangen. Mich nerft jedes Programm bzw. Programmiersprache, die Ressourcen fressen, obwohl das ganze mit besserer/optimierterer Programmierung alles behoben werden könnte.

Das ist auch ein Grund, warum ich PureBasic nicht super-toll finde: Es ist einfach nicht optimiert. Nur zu C hab ich mich nie durchgerungen, da der Code einfach zu C ist . Ich find den Syntax einfach nicht toll. Ich weis, PB ist da auch nicht grad die leuchte, aber den Umstieg auf andere Sprachen hab ich nie gebracht, da es einfach keine Sprache gibt, die IMHO einen gescheiten Syntax hat. Das endert sich ja evtl., wenn ich mein Berufliches Gym. fertig hab (fang im Sommer an).

[ZeHa]

Also dann sag ich mal noch was zur Geschwindigkeit

Ich war lange Zeit auch der Meinung, Java ist langsam. Und ja, es nervt mich zum Teil auch heute noch, weil manche Dinge langsam sind. Aber generell kann man das nicht behaupten. Ich habe in der Firma einen Audioplayer programmiert, der die Audiofiles als Hüllkurve und als Sonagramm anzeigt, und man kann problemlos mit dem Mausrad "hineinzoomen", und die Bilder werden sehr schnell wieder aufgebaut. Ein vergleichbares Programm (Goldwave, kompiliert als EXE) ist da nicht schneller.

Ursprünglich war der Player (nicht von mir entwickelt) wirklich arschlahm, und meine Aufgabe war es, das zu optimieren. Ich hab auch native Dinge eingebaut, die Assembler-optimiert waren. Hat zwar was gebracht, aber nur bedingt. Später hab ich den gesamten Player nochmal von vorn entwickelt, und zwar in 100% purem Java, und das Ding ist schnell wie noch was. Es liegt also nicht nur an der Sprache bzw. an der Technik, sondern vor allem daran, WIE etwas programmiert ist.

Seit ich diesen Player programmiert hab, hab ich einfach ein anderes Bild von Java. Wie gesagt, es ist nicht in jeder Hinsicht perfekt, aber welche Sprache kann das schon von sich behaupten. Dennoch kann man mit Java echt gute Sachen basteln, die schnell, oder zumindest schnell genug laufen.

[PMV]

@ PMV: Ich hab halt mal "private" versucht, da sagte er dann "illegal Modifier".

Das die Leute mich nie für voll nehmen
"Weg machen" heißt, das Wort löschen ... also das Wort "public"
markieren und dann auf die Taste "Entf" drücken.

Ich hab nichts von "tausche mit private" geschrieben.


Ansonnsten interessant ... Leonhard beschwert sich übers Ruckeln,
während andere, z.B. Froggerprogger meinen, Java wäre so schnell wie C-
Programme und könnte sogar schneller sein.
Irgend etwas stimmt da nicht

Die Wahrheit wird wohl eher dazwischen liegen.
Und ein Programm kann nur so gut sein, wie sein Programmierer. Das ist
also Sprachenunabhängig

MFG PMV

[ZeHa]

Das hat nix mit "nicht für voll nehmen" zu tun, das hat eher Deinerseits mit "nicht richtig verstanden" zu tun denn ich hab nicht gesagt, daß ich es nach Deinem Posting extra nochmal probiert hab, sondern das war noch auf meinen vorherigen Versuch bezogen, wo ich selber schon so klug war, zumindest mal public UND private zu versuchen

Das mit dem "Wort löschen" hab ich dann schon auch verstanden, aber ich hab es seitdem halt noch nicht neu versucht weil ich gerade was anderes mach...


EDIT: Davon abgesehen heißt "kein Modifier" normalerweise eh das gleiche wie "private", daher wundert es mich eh, daß es ohne Modifier funzt und mit private nicht.

[PMV]

Na gut

... bei mir heißt die Fehlermeldung übrigens:
"modifier private not allowed here"

Aber in Java haben die Dinger nicht immer die selbe Bedeutung bei Klasse,
Methode und Variable. Da muss man schon aufpassen. Könnte man
übrigends auch als Negativpunkt ankreiden ^_^

MFG PMV

[Froggerprogger]

Zum Thema Speed:

Ich find's einfach zu Langsam. Und dann fährend der Ausführung ruckt es: sind wir hier in der Steinzeit? Es währe doch möglich, Java-Code in Assember zu übersetzen und im Speicher auszuführen. Das würde alles schneller machen, aber nein, ...

Genau das macht der JIT-Compiler doch. Und dabei kann er sogar anhand von Kriterien optimieren, die erst zur Laufzeit feststehen.
Oft wird die 'Geschwindigkeit' eines Programms an seiner GUI 'gesehen'. Natürlich ruckeln viele Applets, die mit AWT ungeschickt auf ein Canvas-Objekt rendern, ebenso wie Swing-GUIs, deren Programmierer die ganzen Zwischendurchberechnungen vom selben Thread machen lassen, der auch der Anzeige dient. Also: Wenn die GUI schön 'schnell' laufen soll, muss man sie auch richtig programmieren, das gilt bei PB genauso: Da sollte man auch kein generelles Delay(10) in eine WindowEvent()-Eventschleife setzen, sondern nur dann, wenn sonst kein Event stattfand.
Aber unabhängig davon meine ich mit Geschwindigkeit die reine Rechenleistung. Einige Performancetests zeigten dort keinen großen Unterschied. Der schlimmste Fall war bei mehrdimensionalen Arrays, da war Java etwa um Faktor 10 langsamer als C mit Pointersprüngen, weil mehrdimensionale Arrays in Form von "Arrays von Arrays" implementiert waren, und somit öfter und weiter beim Zugriff gesprungen werden musste. Aber ansonsten war der Faktor so 1-4 also insbesondere halt auch ohne Unterschied. Solche Abstände sind für die meisten üblichen Programme völlig egal, selbst bei etwas zeitkritischeren Dingen. Die Möglichkeiten stattdessen bei der Entwicklungszeit enorm Zeit zu sparen machen das locker wieder wett.
Aber bei z.B. wissenschaftlichen Berechnungen, die viele Stunden und Tage laufen, dort sollte man diese Berechnungskerne natürlich effektiver und unter Einsatz aller Hardwaredetails wie Cacheoptimierung, SSE, etc. programmieren, weil dann ein Unterschied von 2-10 natürlich gigantische Auswirkungen hat.

[Andreas_S]

Also, im großen und ganzen ist Java keine schlecht Sprache, aber mich nervt eben oft die Geschwindigkeit...
Wie ich mich an einem kleinen Renderer in Java versucht ist aber nichts draus geworden...
Java ist auch insofern langsamer weil man eigendlich zB bei Strings immer neue erzeugen muss, und das macht die Sache auch nicht schneller...

@ZeHa
Zu deinem Audioplayer... die Darstellung ist ja nicht wegen Java schnell, sondern wegen des Renderers den Java verwendet...

Das heißt Java kann zwar Sachen importieren die schnell sind, aber alleine wäre Java nichts...

Außerdem kann ich mir nicht vorstellen das wären der Ausführung des Bytecodes, dieser Compiliert wird... weil ja immer nur die VM CPU-Belastung anzeigt... Und es gibt auch keinen eigenen Prozess von einem Javaprogramm.

Für Anwendungsprogramme ist Java vil. ganz nett, aber im Fall 3D Darstellung und Spiele nutze ich lieber PB bis C++.

[ZeHa]

Ich muß aber während des Zeichnes tonnenweise Berechnungen ausführen, und im Falle des Sonagramms muß ich sogar jeden Pixel einzeln berechnen. Das meine ich mit schnell. Und zwar bei jedem Zoom-Schritt, das Zoomen mache ich selbst, das hat nix mit dem Java-Renderer zu tun.

Sondern ich benutze die ganzen 2D-Drawing-Befehle von Java (die meines Wissens nichtmal hardwarebeschleunigt sind) und berechne die Pixel zum größten Teil einzeln, und zwar anhand von Audio-Daten die ich erst durch eine FFT jagen muß und hinterher noch auf eine logarithmische Farbskala anwenden muß.

[Froggerprogger]

Mini-Infos zum JIT-Compiler unter Wikipedia: http://de.wikipedia.org/wiki/JIT-Compiler
Ist aber an sich ein hochkomplexes Thema.

Hier noch ein paar Infos zur JVM (Java Virtual Machine):
Der Java-Source wird vom Java-Compiler in plattformunabhängigen Byte-Code übersetzt, das ist im wesentlichen nur der Source in komprimierter Form. Die JVM läuft als eigenständiges Programm auf dem jeweiligen Rechner, egal ob Windows, Linux oder Handy und erhält als Eingabe den ByteCode. Dieser wurde früher immer nur interpretiert, und einige exotische Plattformen machen das auch noch heute so, für alle gängigen werden aber in der JVM die JIT-Compiler eingesetzt, die übersetzen zur Laufzeit kritische Teile des Byte-Code in Maschinencode (auch z.B. nur einzelne Methoden oder Schleifen) und führen diese dann aus (es gab sogar mal Ansätze von Byte-Code-Prozessoren, die den Byte-Code in Hardware umsetzen). Dabei wird zunehmend daran gearbeitet immer weitere Optimierungen einzubauen, z.B. bei Bedarf eine Funktion mal per Inline einzubetten, If-Blöcke mit derzeit immer falschen Annahmen zu entfernen um Sprünge zu sparen, ebenso in Switch-Blöcken innerhalb von Loops, deren Wert sich in der Loop nicht ändert, etc. Solche Dinge können nur zur Laufzeit optimiert werden, sind aber algorithmisch anspruchsvoll, was die JIT-Compiler zu einem komplexen Thema macht.

Je nach JVM kann dann der gesamte Java-Sprachumfang oder auf nicht-standard-Architekturen nur Teile daraus unterstützt werden. Je nach Architektur kann dann auch einiges beschleunigt werden, z.B. werden bereits 2D-Grafikfunktionen unter Windows und Linux hardwarebeschleunigt, sofern eine solche Grafikkarte vorhanden ist, ansonsten eben emuliert.
Auch gibt es mehrere Anbindungen an OpenGL (z.B. per JOGL) mit denen sich gut für diverse Plattformen 3D-Programmieren lässt, z.B. für hardwareunterstützte 3D-Objektanzeige in Anwendungen. Trotzdem wird voraussichtlich niemals ein amtlicher Ego-Shooter unter Java entwickelt, da dabei natürlich ein großer Unterschied zwischen 10 oder 40 fps/Sekunde besteht.

[milan1612]

Diese ganze Diskussion hier hat mich doch tatsächlich so weit gebracht dass ich mir mal
das JDK & Eclipse runtergeladen hab. Jetzt muss ich Java doch selber mal ausprobieren