spiro schrieb am 11. September 2006 3:50
> Der Clou bei der Sache:
> Bei meinem Java-System verarbeiten dann die Java 1 Maschienen genau
> den Code, der von Java 2 Kompilern erzeugt wurde.
> Das heißt, der Bytecode für beides, Java 1 UND java 2
> Abspielen, ist Java 2 Compiler generierter Code.
keine Überraschung, da der Bytecode seinen Umfang oder das Format
nicht geändert hat: Aufwärtskompatibilität war fast heilig.
> Das nochmal als Info zum Thema "Optimierung"
> für altes oder neues Java.
Das hat mit dem Compiler nichts zu tun; der "optimiert" kaum etwas.
Es hätte allenfalls mit dem Sourcecode und Anwendungsdesign zu tun.
Z.B. waren es viele von C her gewohnt, in Schleifen abwärts zu zählen
und bei Null abzubrechen, um bessere Performance zu erhalten.
Natürlich liest sich
 for (int i=9; i>=0; --i)
für die meisten holpriger als
 for (int i=0; i<10; ++i)
Und letzteres muß heutzutage nicht langsamer sein, die JITs machen
oft seltsame Dinge und Optimierungsregeln von gestern können morgen
schon veraltet sein. Der Trend geht zu einfacher Darstellung, mehr
Freiraum für Abstraktion und dennoch low level Optimierungen
"irgendwo unter der Motorhaube" - aber eher abgestimmt auf
verallgemeinerte Programme als auf solche, die mit spezifischen
Tricks gespickt sind. Es gab mal ein Buch "Kick-Ass Java", das war
voll von solchen Tricks of the Trade. Wenn ich mehr Zeit hätte, würde
ich mir das nochmal ansehen und testen, wieviel die heute noch
bringen, und was alles den Code komplexer und unflexibler macht, ohne
daß es irgendwas hilft. my 2c.
> Der Clou bei der Sache:
> Bei meinem Java-System verarbeiten dann die Java 1 Maschienen genau
> den Code, der von Java 2 Kompilern erzeugt wurde.
> Das heißt, der Bytecode für beides, Java 1 UND java 2
> Abspielen, ist Java 2 Compiler generierter Code.
keine Überraschung, da der Bytecode seinen Umfang oder das Format
nicht geändert hat: Aufwärtskompatibilität war fast heilig.
> Das nochmal als Info zum Thema "Optimierung"
> für altes oder neues Java.
Das hat mit dem Compiler nichts zu tun; der "optimiert" kaum etwas.
Es hätte allenfalls mit dem Sourcecode und Anwendungsdesign zu tun.
Z.B. waren es viele von C her gewohnt, in Schleifen abwärts zu zählen
und bei Null abzubrechen, um bessere Performance zu erhalten.
Natürlich liest sich
 for (int i=9; i>=0; --i)
für die meisten holpriger als
 for (int i=0; i<10; ++i)
Und letzteres muß heutzutage nicht langsamer sein, die JITs machen
oft seltsame Dinge und Optimierungsregeln von gestern können morgen
schon veraltet sein. Der Trend geht zu einfacher Darstellung, mehr
Freiraum für Abstraktion und dennoch low level Optimierungen
"irgendwo unter der Motorhaube" - aber eher abgestimmt auf
verallgemeinerte Programme als auf solche, die mit spezifischen
Tricks gespickt sind. Es gab mal ein Buch "Kick-Ass Java", das war
voll von solchen Tricks of the Trade. Wenn ich mehr Zeit hätte, würde
ich mir das nochmal ansehen und testen, wieviel die heute noch
bringen, und was alles den Code komplexer und unflexibler macht, ohne
daß es irgendwas hilft. my 2c.