> > > Wenn man sich ein Video anguckt, dauert das meist etwas länger.
> > > Anfangsruckler wären allerdings störend.
>
>> Redest Du eigentlich von meiner Seite?
> Nein, ich meinte Deinen Einwurf, daß die modernen JITs und
> dynamischen Optimizer nur für Serverbetrieb geeignet wären. Am Anfang
> einer Anwendung erwartet man da natürlich Performanceengpässe und
> Verzögerungen, wenn der JIT beginnt, den Code zu analysieren und
> umzuformen.
Nicht Just In Time Compiling von Java1, ich meinte das Hotspot
Compiling von Java 2!!
Soweit ich das verstanden habe, versucht der Just In Time Compiler
größere
Code Bereiche, die augerufen werden, in einem Stück zu kompilieren,
während Hotspot noch weitere (andauernende) Laufzeitanalysen vornimmt
(und entsprechend nebenher dauernd arbeitet und natürlich entsprechen
erstmal RT und Performance kostet, bevor er hoffentlich netto einen
Performancegewinn macht. So jedenfalls die Theorie....Von der Theorie
ist es wirklich "cool":
Ein Compiler MIT Laufzeitinformationen hat mehr Möglichkeiten zu
optimieren,
als ein Compiler, der nur statische Nichtlaufzeitinformationen zur
Verfügung hat. Und klar, von der Theorie her hatte man damit die
Applet-Technologie leider vernachlässigt und Server-Processing im
Blickfeld gehabt. Möglicherweise wäre sogar mit dieser Technologie
effektives Numbercrunching möglich. Ich mit meiner Videoengine gehe
bei dem Spiel aber leider leer aus....
> Ich könnte mir also vorstellen, daß eine Videoengine unmittelbar nach
> dem Start etwas zickt (der JIT ist nicht für Echtzeitfähigkeit
> designt) aber wenn dann der Film ein Stück weit gelaufen ist, hat
> sich meist alles so eingespielt, daß nichts störendes mehr zu
JIT != Hotspot und schau doch mal meine Seite an, einmal mit Java 2
und einmal
mit Microsoft Java 1 (Sun Java 1 läßt sich leider nicht in den
Browser einbinden, es sei denn Du nimmst Netscape 4.78 mit "build in"
Borland Java 1.1.5.... (-: (Es läuft sogar damit...)
> bemerken ist. Es gab schon 1998/2000 Benchmarks, wo eine FFT auf
> einer JVM nach dem "Aufwärmen" schneller lief als auf Visual C++. Ein
> klassischer Interpreter, der bei Highl Level Konstrukten einigermaßen
> ausreichen würde, könnte das nicht, aber ein JIT kann solche Low
> Level Operationen meist recht effektiv in native Code gießen. Und
> solche dürften ja wohl zuhauf beim Dekodieren eines Videostreams
> auftreten. Kinderbenchmarks wie der Bagley-Shootout oder der Fractal
> Benchmark haben meist keine Aufwärmphase und sind schon dadurch
> relativ aussagelos (werden aber gerne und oft zitiert ;)
JIT != Hotspot
Leichte Videoruckler an der oder unter der Wahrnehmungsgrenze gibt es
im Videoabspielen, so daß man den Eindruck hat, das native Player
irgendwie eine klarere Wiedergabe haben. Das ist aber permament so
und kann man auch nicht wegtricksen. Der Gesammteindruck, den ICH bei
meiner Seite beim Videoaspielen habe : Bei Java1 einigermaßen
erträglich, bei Java 5, na ja, fast schon wieder so wie Java1.
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. Ich hätte gerne mal Swing mit einer Java 1
Maschine gesehen.
> > > Anfangsruckler wären allerdings störend.
>
>> Redest Du eigentlich von meiner Seite?
> Nein, ich meinte Deinen Einwurf, daß die modernen JITs und
> dynamischen Optimizer nur für Serverbetrieb geeignet wären. Am Anfang
> einer Anwendung erwartet man da natürlich Performanceengpässe und
> Verzögerungen, wenn der JIT beginnt, den Code zu analysieren und
> umzuformen.
Nicht Just In Time Compiling von Java1, ich meinte das Hotspot
Compiling von Java 2!!
Soweit ich das verstanden habe, versucht der Just In Time Compiler
größere
Code Bereiche, die augerufen werden, in einem Stück zu kompilieren,
während Hotspot noch weitere (andauernende) Laufzeitanalysen vornimmt
(und entsprechend nebenher dauernd arbeitet und natürlich entsprechen
erstmal RT und Performance kostet, bevor er hoffentlich netto einen
Performancegewinn macht. So jedenfalls die Theorie....Von der Theorie
ist es wirklich "cool":
Ein Compiler MIT Laufzeitinformationen hat mehr Möglichkeiten zu
optimieren,
als ein Compiler, der nur statische Nichtlaufzeitinformationen zur
Verfügung hat. Und klar, von der Theorie her hatte man damit die
Applet-Technologie leider vernachlässigt und Server-Processing im
Blickfeld gehabt. Möglicherweise wäre sogar mit dieser Technologie
effektives Numbercrunching möglich. Ich mit meiner Videoengine gehe
bei dem Spiel aber leider leer aus....
> Ich könnte mir also vorstellen, daß eine Videoengine unmittelbar nach
> dem Start etwas zickt (der JIT ist nicht für Echtzeitfähigkeit
> designt) aber wenn dann der Film ein Stück weit gelaufen ist, hat
> sich meist alles so eingespielt, daß nichts störendes mehr zu
JIT != Hotspot und schau doch mal meine Seite an, einmal mit Java 2
und einmal
mit Microsoft Java 1 (Sun Java 1 läßt sich leider nicht in den
Browser einbinden, es sei denn Du nimmst Netscape 4.78 mit "build in"
Borland Java 1.1.5.... (-: (Es läuft sogar damit...)
> bemerken ist. Es gab schon 1998/2000 Benchmarks, wo eine FFT auf
> einer JVM nach dem "Aufwärmen" schneller lief als auf Visual C++. Ein
> klassischer Interpreter, der bei Highl Level Konstrukten einigermaßen
> ausreichen würde, könnte das nicht, aber ein JIT kann solche Low
> Level Operationen meist recht effektiv in native Code gießen. Und
> solche dürften ja wohl zuhauf beim Dekodieren eines Videostreams
> auftreten. Kinderbenchmarks wie der Bagley-Shootout oder der Fractal
> Benchmark haben meist keine Aufwärmphase und sind schon dadurch
> relativ aussagelos (werden aber gerne und oft zitiert ;)
JIT != Hotspot
Leichte Videoruckler an der oder unter der Wahrnehmungsgrenze gibt es
im Videoabspielen, so daß man den Eindruck hat, das native Player
irgendwie eine klarere Wiedergabe haben. Das ist aber permament so
und kann man auch nicht wegtricksen. Der Gesammteindruck, den ICH bei
meiner Seite beim Videoaspielen habe : Bei Java1 einigermaßen
erträglich, bei Java 5, na ja, fast schon wieder so wie Java1.
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. Ich hätte gerne mal Swing mit einer Java 1
Maschine gesehen.