spiro schrieb am 12. September 2006 20:24
> Nicht Just In Time Compiling von Java1, ich meinte das Hotspot
> Compiling von Java 2!!
Heute machen das praktisch alle. Daher meinte ich mit "JIT" immer
auch dynamische Optimierungstechniken (gleich ob die gerade Hotspot
oder schon wieder anders heißen).
> Ein Compiler MIT Laufzeitinformationen hat
> mehr Möglichkeiten zu optimieren,
Speziell die höheren Abstraktionskonstrukte kann er aufgrund von
Informationen wie "ist jene Methode bereits irgendwo überschireben
worden" besser optimieren ohne den "dynamischen Nachladecharakter"
typischer Plugin-Architekturen zu zerstören. Objektorientierung,
Polymorphie etc. werden "erschwinglicher", da sie an fast jeder Ecke,
wo sie nicht genutzt wurden, wegoptmiert werden können. In statisch
kompilierten Umgebungen muß man für tiefgreifende Optimierungen den
ganzen Code im voraus haben (nix Plugins nachladen ;) und es wird
trotzdem schwierig und das Resultat läuft auf genau einer
Zielarchitektur.
Oder man vereinfacht es sich und fordert: Weg mit Polymorphie und
Konsorten, die werden ja ohnehin nur an einigen Stellen gebraucht.
C++ läßt einen mit "virtual" festlegen, welche Funktion polymorph
sein soll. Leider sind dann die anderen statisch gebunden, auch wenn
sich diese Wahl später als unglücklich herausstellt.
> JIT != Hotspot...
> ...
> JIT != Hotspot
Schon gut. Heutzutage ist es bei Java eben meist so, weshalb ich wie
gesagt "JIT" als Pars pro Toto verwendete ;-)
> Ob nun Swing oder SWT (defakto aufgepepptes AWT) schneller
> (=Performance UND RT, jawohl RT = auch "gefühlte" Performance) ist,
> kann man nur schwer beantworten, weil Swing eben ZUSAMMEN mit Hotspot
> auf dem Markt kam.
So schwer ist das imho nicht. "Schnell" ist heute nur noch, wer die
Grafikbeschleunigung der Hardware nutzt. Die Verbesserungen bei den
Zeichenoperationen in Java sind wohl stark auf die Zunahme dieser
Nutzung zurückzuführen. Es werden seit 1.4 sogar 3D-Funktionen für
den 2D-Desktop verwendet, da heutzutage die 2D-Fähigkeiten der Karten
oft hinter einer 2D-zweckentfremdeten 3D-Funktion herhinken.
Die Architekturmaßnahmen hinter Swing sind natürlich eine andere
Sache, aber da man meist die Frage "SWT versus Swing" eher als
"native Fenster versus Emulation" auffaßt, ist dieser Teil i.W. durch
die Nutzung der Hardwarebeschleunigung charakterisiert - und das
können beide. Die architektonischen Unterschiede schlagen erst
jenseits von SWT zu, das ja z.B. keine MVC-Strukturen u.ä.
"höherleveliges" bietet. Swing deckt eben da einen größeren Bereich
ab, und daher würde man es eher mit der Kombination SWT+JFace
vergleichen. Ganz stimmt auch das nicht, denn der reichhaltige Satz
von Grafikoperationen aus Java2D exisitert in dem Umfang in SWT
nicht, und auch sonst hat man noch Unterschiede im Aufbau. Für die
Wiedergabe von Videos ist das aber eher unerheblich, da würde ich
meinen, die Grafikoperationen und die Arbeitsweise Grafikpipeline
sind die bestimmenden Faktoren. Mir fällt aber kein SWT-Fenster "zur
Videowiedergabe" ein, vermutlich muß man da noch etwas natives
schreiben, um solche Fähigkeiten javaseitig zur Verfügung zu stellen;
SWT-Standard dürfte das nicht sein (hab aber zuwenig Detailerfahrung
mit SWT um das sicher auszuschließen - es kann im übrigen schon was
Zusätzliches geben, das man sich einfach zu SWT dazuinstalliert, da
ja mancher vielleicht schon sowas gebraucht hat).
> Ich hätte gerne mal Swing mit einer Java 1 Maschine gesehen.
Das alte Swing 1.0.3 sollte dort eigentlich laufen, oder? Natürlich
ist die Architektur dort alt, aber das Tempo der bloßen
Grafikoperationen und die eigenschaften der VM für die nötigen
Berechnungen in Echtzeit sollte das kaum stören; und diese Dinge
dürften ja für Videowiedergabe vordringlich wichtig sein. Leider
dürfte es mit der Nutzung von Beschleunigerfunktionen meist Essig
sein, daran wird's also scheitern. Da Swing 100% Java ist, könnte man
versuchen, ob es sich herauslösen und auf einer alten JVM betreiben
läßt. Nur sind die Nutzung der Beschleuniger und die 2D und
Pipelinesachen wohl eher im teilweise nativen AWT, auf dem Swing
aufsetzt, und das dann wieder auf 1.1-Niveau wäre. Also auch da eher
Fehlanzeige. Wegen dieser Abhängigkeiten und Verstrickungen halte ich
"Swing mit einer Java 1 Maschine" für einen sehr schwer definierbaren
Beriff, über den man kaum sinnvoll spekulieren kann. Eigentlich kann
es sowas in konsistenter Form nicht geben. my 2c.
> Nicht Just In Time Compiling von Java1, ich meinte das Hotspot
> Compiling von Java 2!!
Heute machen das praktisch alle. Daher meinte ich mit "JIT" immer
auch dynamische Optimierungstechniken (gleich ob die gerade Hotspot
oder schon wieder anders heißen).
> Ein Compiler MIT Laufzeitinformationen hat
> mehr Möglichkeiten zu optimieren,
Speziell die höheren Abstraktionskonstrukte kann er aufgrund von
Informationen wie "ist jene Methode bereits irgendwo überschireben
worden" besser optimieren ohne den "dynamischen Nachladecharakter"
typischer Plugin-Architekturen zu zerstören. Objektorientierung,
Polymorphie etc. werden "erschwinglicher", da sie an fast jeder Ecke,
wo sie nicht genutzt wurden, wegoptmiert werden können. In statisch
kompilierten Umgebungen muß man für tiefgreifende Optimierungen den
ganzen Code im voraus haben (nix Plugins nachladen ;) und es wird
trotzdem schwierig und das Resultat läuft auf genau einer
Zielarchitektur.
Oder man vereinfacht es sich und fordert: Weg mit Polymorphie und
Konsorten, die werden ja ohnehin nur an einigen Stellen gebraucht.
C++ läßt einen mit "virtual" festlegen, welche Funktion polymorph
sein soll. Leider sind dann die anderen statisch gebunden, auch wenn
sich diese Wahl später als unglücklich herausstellt.
> JIT != Hotspot...
> ...
> JIT != Hotspot
Schon gut. Heutzutage ist es bei Java eben meist so, weshalb ich wie
gesagt "JIT" als Pars pro Toto verwendete ;-)
> Ob nun Swing oder SWT (defakto aufgepepptes AWT) schneller
> (=Performance UND RT, jawohl RT = auch "gefühlte" Performance) ist,
> kann man nur schwer beantworten, weil Swing eben ZUSAMMEN mit Hotspot
> auf dem Markt kam.
So schwer ist das imho nicht. "Schnell" ist heute nur noch, wer die
Grafikbeschleunigung der Hardware nutzt. Die Verbesserungen bei den
Zeichenoperationen in Java sind wohl stark auf die Zunahme dieser
Nutzung zurückzuführen. Es werden seit 1.4 sogar 3D-Funktionen für
den 2D-Desktop verwendet, da heutzutage die 2D-Fähigkeiten der Karten
oft hinter einer 2D-zweckentfremdeten 3D-Funktion herhinken.
Die Architekturmaßnahmen hinter Swing sind natürlich eine andere
Sache, aber da man meist die Frage "SWT versus Swing" eher als
"native Fenster versus Emulation" auffaßt, ist dieser Teil i.W. durch
die Nutzung der Hardwarebeschleunigung charakterisiert - und das
können beide. Die architektonischen Unterschiede schlagen erst
jenseits von SWT zu, das ja z.B. keine MVC-Strukturen u.ä.
"höherleveliges" bietet. Swing deckt eben da einen größeren Bereich
ab, und daher würde man es eher mit der Kombination SWT+JFace
vergleichen. Ganz stimmt auch das nicht, denn der reichhaltige Satz
von Grafikoperationen aus Java2D exisitert in dem Umfang in SWT
nicht, und auch sonst hat man noch Unterschiede im Aufbau. Für die
Wiedergabe von Videos ist das aber eher unerheblich, da würde ich
meinen, die Grafikoperationen und die Arbeitsweise Grafikpipeline
sind die bestimmenden Faktoren. Mir fällt aber kein SWT-Fenster "zur
Videowiedergabe" ein, vermutlich muß man da noch etwas natives
schreiben, um solche Fähigkeiten javaseitig zur Verfügung zu stellen;
SWT-Standard dürfte das nicht sein (hab aber zuwenig Detailerfahrung
mit SWT um das sicher auszuschließen - es kann im übrigen schon was
Zusätzliches geben, das man sich einfach zu SWT dazuinstalliert, da
ja mancher vielleicht schon sowas gebraucht hat).
> Ich hätte gerne mal Swing mit einer Java 1 Maschine gesehen.
Das alte Swing 1.0.3 sollte dort eigentlich laufen, oder? Natürlich
ist die Architektur dort alt, aber das Tempo der bloßen
Grafikoperationen und die eigenschaften der VM für die nötigen
Berechnungen in Echtzeit sollte das kaum stören; und diese Dinge
dürften ja für Videowiedergabe vordringlich wichtig sein. Leider
dürfte es mit der Nutzung von Beschleunigerfunktionen meist Essig
sein, daran wird's also scheitern. Da Swing 100% Java ist, könnte man
versuchen, ob es sich herauslösen und auf einer alten JVM betreiben
läßt. Nur sind die Nutzung der Beschleuniger und die 2D und
Pipelinesachen wohl eher im teilweise nativen AWT, auf dem Swing
aufsetzt, und das dann wieder auf 1.1-Niveau wäre. Also auch da eher
Fehlanzeige. Wegen dieser Abhängigkeiten und Verstrickungen halte ich
"Swing mit einer Java 1 Maschine" für einen sehr schwer definierbaren
Beriff, über den man kaum sinnvoll spekulieren kann. Eigentlich kann
es sowas in konsistenter Form nicht geben. my 2c.