spiro schrieb am 11. September 2006 19:37
> > > Das Einzige, was man Performancemäßig für Java2
> > > optimieren kann, ist die Benutzung von Java2 only
> > > Klassen, wie java.nio für asynchrones IO.
> > > Da hat man einfach alle synchronized - statements entfernt -
> > > deshalb asynchron und deshalb theoretisch scneller....
> .....
> A multiplexed, non-blocking I/O facility... for writing scalable servers
> <Zitat Ende>
>
> > Uups, das ist wohl ein grobes Mißverständnis.
> > Asynchroner IO ist doch etwas anderes.
>
> Stimmt - dann eben non-blocking I/O facility.
Ich medinte, daß die Performancegewinne nicht vom Weglassen der
Synchronisierung kommen. Denn synchronisieren muß man ja an einigen
Stellen trotzdem. Mit "asynchron" meint Sun hier, daß Dein
aufrufender Thread sofort zurückkehrt und der I/O im Hintergrund
parallel läuft, ohne daß jeder Anwendungsprogrammierer dazu selbst
einen weiteren Thread starten muß. Das ganze wird dann intern und
zentral gehandhabt (braucht auch nicht unbedingt für jeden
I/O-Auftrag einen eigenen Thread) und mittels neuer APIs und
Konstrukte (z.B. Channels) der Anwendung zugänglich gemacht
(Anwendungsthread kann zwischendurch was anderes tun und kriegt mit,
wann der I/O fertig ist; Anwendung kann bei mehreren I/Os einfach bei
dem weitermachen, der als erster "bereit" ist, anstatt sich für einen
zu entscheiden zu müssen, der aber dann zufällig lange blockiert).
Diese Maßnahmen können in Situationen mit viel I/O-Last
(typischerweise Server) mehr Performance und vor allem Skalierbarkeit
bringen. Nicht in jedem Einzeltest ist aber eine NIO-Lösung, die
dasselbe macht wie die alten Methoden, schneller.
> > 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.
Aber nach einiger Zeit (Sekunden, Minuten... je nach Strategie) ist
so ziemlich alles performancerelevante am Code gefunden und
optimiert, d.h. wenn eine Anwendung dann "gleichmäßig" läuft (nicht
ständig neuen Code nachlädt, der alte Schlußfolgerungen über den
Haufen werfen könnte) sollten die rechenintensiven Operationen recht
effizient laufen.
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
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 ;)
> > Echtzeitfähigkeit gehört wirklich nicht zu den Zielen, dafür wäre
> > RT-Java zuständig. Will man sowas wie "weiche Echtzeitfähigkeit" mit
> > J2SE realisiern, muß man schon in die Trickkiste greifen.
>
> Also noch ein Flash-Video Fan....
Nein, wie käme ich dazu. "In die Trickkiste greifen" heißt optimieren
ohne Rücksicht auf Übersichtlichkeit und Wartbarkeit des Codes,
Ausnutzen von Eigenheiten einer konkreten Plattform, die dort
Performance bringen, aber beim Wechsel auf ein anderes Zielsystem
bereits den Gegenteiligen Effekt haben könnten. Eben die
Extremmaßnahmen, die nötig sind, wenn man nicht genügend
Performancereserven hat. Das von mir erwähnte Buch "Kick Ass Java"
ist ein Beispiel dafür. Sowas macht man nur, wenn es nötig wird, was
aber eben ab und zu auch vorkommt. Ist allgemein so in der
Programmierung. Und das kann nicht durch "Zaubertrankrezepte" wie
Flash oder Active-X ersetzt werden. my 2c.
> > > Das Einzige, was man Performancemäßig für Java2
> > > optimieren kann, ist die Benutzung von Java2 only
> > > Klassen, wie java.nio für asynchrones IO.
> > > Da hat man einfach alle synchronized - statements entfernt -
> > > deshalb asynchron und deshalb theoretisch scneller....
> .....
> A multiplexed, non-blocking I/O facility... for writing scalable servers
> <Zitat Ende>
>
> > Uups, das ist wohl ein grobes Mißverständnis.
> > Asynchroner IO ist doch etwas anderes.
>
> Stimmt - dann eben non-blocking I/O facility.
Ich medinte, daß die Performancegewinne nicht vom Weglassen der
Synchronisierung kommen. Denn synchronisieren muß man ja an einigen
Stellen trotzdem. Mit "asynchron" meint Sun hier, daß Dein
aufrufender Thread sofort zurückkehrt und der I/O im Hintergrund
parallel läuft, ohne daß jeder Anwendungsprogrammierer dazu selbst
einen weiteren Thread starten muß. Das ganze wird dann intern und
zentral gehandhabt (braucht auch nicht unbedingt für jeden
I/O-Auftrag einen eigenen Thread) und mittels neuer APIs und
Konstrukte (z.B. Channels) der Anwendung zugänglich gemacht
(Anwendungsthread kann zwischendurch was anderes tun und kriegt mit,
wann der I/O fertig ist; Anwendung kann bei mehreren I/Os einfach bei
dem weitermachen, der als erster "bereit" ist, anstatt sich für einen
zu entscheiden zu müssen, der aber dann zufällig lange blockiert).
Diese Maßnahmen können in Situationen mit viel I/O-Last
(typischerweise Server) mehr Performance und vor allem Skalierbarkeit
bringen. Nicht in jedem Einzeltest ist aber eine NIO-Lösung, die
dasselbe macht wie die alten Methoden, schneller.
> > 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.
Aber nach einiger Zeit (Sekunden, Minuten... je nach Strategie) ist
so ziemlich alles performancerelevante am Code gefunden und
optimiert, d.h. wenn eine Anwendung dann "gleichmäßig" läuft (nicht
ständig neuen Code nachlädt, der alte Schlußfolgerungen über den
Haufen werfen könnte) sollten die rechenintensiven Operationen recht
effizient laufen.
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
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 ;)
> > Echtzeitfähigkeit gehört wirklich nicht zu den Zielen, dafür wäre
> > RT-Java zuständig. Will man sowas wie "weiche Echtzeitfähigkeit" mit
> > J2SE realisiern, muß man schon in die Trickkiste greifen.
>
> Also noch ein Flash-Video Fan....
Nein, wie käme ich dazu. "In die Trickkiste greifen" heißt optimieren
ohne Rücksicht auf Übersichtlichkeit und Wartbarkeit des Codes,
Ausnutzen von Eigenheiten einer konkreten Plattform, die dort
Performance bringen, aber beim Wechsel auf ein anderes Zielsystem
bereits den Gegenteiligen Effekt haben könnten. Eben die
Extremmaßnahmen, die nötig sind, wenn man nicht genügend
Performancereserven hat. Das von mir erwähnte Buch "Kick Ass Java"
ist ein Beispiel dafür. Sowas macht man nur, wenn es nötig wird, was
aber eben ab und zu auch vorkommt. Ist allgemein so in der
Programmierung. Und das kann nicht durch "Zaubertrankrezepte" wie
Flash oder Active-X ersetzt werden. my 2c.