Bezüglich des Artikels "AGB für Knigge" halte ich es für etwas gewagt, die "Optimierung durch Exceptions" durch den Einsatz in der medizinischen Meßtechnik zu begründen, da dort die "zeitlichen Anforderungen" besonders hoch seien. Handelt es sich tatsächlich um ein kritisches Echtzeitsystem ist es sicher nicht damit getan durch Tricks eine Schleife ein wenig zu beschleunigen, denn bekanntlich muß ein derartiges System nicht möglichst schnell sondern im worst-case nachweislich schnell genug sein.
Eigentlich wollte ich nochmals auf die Optimierung a < x < b eingehen, die laut Artikel eine "wirklich intelligente und elegante Optimierungsmethode" ist, die nur deshalb keine meßbaren Verbesserungen bringt, weil sie vom Compiler/JIT/Hotspot bereits umgesetzt wird. Ich denke damit ist die Optimierung "if(0 <= z && z <= 255)" zu "if(z - 0x80000000 <= 0x800000FF)" aus JM 11/04 gemeint. Mehrere Leser haben angemerkt, das diese Optimierung nichts bringt, da lediglich ein Vergleich durch eine Subtraktion ersetzt wurde. Wenn man sich mal den Byte-Code ansieht (JDK 1.5.0_04):
<PRE>
if(0 <= z && z <= 255):
</PRE>
iflt 16
iload_1
sipush 255
if_icmpgt 16
<br>
Zweimal push auf den Stack (iload, sipush), zwei Vergleiche (iflt, if_icmpgt). Ev. Abkürzung, falls iflt bereits zutrifft, wird der Rest nicht ausgeführt.
<PRE>
if(z - 0x80000000 <= 0x800000FF):
</PRE>
ldc #16;
isub
ldc #17;
if_icmpgt 14
<br>
Zweimal push auf den Stack (zweimal ldc), ein Vergleich (if_icmpgt) und eine Subtraktion (isub).
<br>
Es stellt sich hier die Frage wo denn die Optimierung ist bzw. warum Variante 2 schneller sein soll, denn wie bereits angemerkt wurde lediglich ein Vergleich iflt gegen eine Subtraktion isub (also zweimal vom Stack lesen, subtrahieren und wieder zurückschreiben) ersetzt. Auch ohne das ganze in x86 Assembler zu übersetzen kann man leicht abschätzen, das Variante 1 in der Praxis eher etwas schneller sein wird.
In diesem Thread
http://entwickler-forum.de/webx?50@@.4a87166a
wurde genau darauf hingewiesen. Die Behauptung, der Compiler würde diese Optimierung bereits durchführen ist nicht nachvollziehbar. Warum also ist diese Methode intelligent und elegant und warum ist sie für Compiler-Hersteller so nützlich?
Gruß,
Alwin
Eigentlich wollte ich nochmals auf die Optimierung a < x < b eingehen, die laut Artikel eine "wirklich intelligente und elegante Optimierungsmethode" ist, die nur deshalb keine meßbaren Verbesserungen bringt, weil sie vom Compiler/JIT/Hotspot bereits umgesetzt wird. Ich denke damit ist die Optimierung "if(0 <= z && z <= 255)" zu "if(z - 0x80000000 <= 0x800000FF)" aus JM 11/04 gemeint. Mehrere Leser haben angemerkt, das diese Optimierung nichts bringt, da lediglich ein Vergleich durch eine Subtraktion ersetzt wurde. Wenn man sich mal den Byte-Code ansieht (JDK 1.5.0_04):
<PRE>
if(0 <= z && z <= 255):
</PRE>
iflt 16
iload_1
sipush 255
if_icmpgt 16
<br>
Zweimal push auf den Stack (iload, sipush), zwei Vergleiche (iflt, if_icmpgt). Ev. Abkürzung, falls iflt bereits zutrifft, wird der Rest nicht ausgeführt.
<PRE>
if(z - 0x80000000 <= 0x800000FF):
</PRE>
ldc #16;
isub
ldc #17;
if_icmpgt 14
<br>
Zweimal push auf den Stack (zweimal ldc), ein Vergleich (if_icmpgt) und eine Subtraktion (isub).
<br>
Es stellt sich hier die Frage wo denn die Optimierung ist bzw. warum Variante 2 schneller sein soll, denn wie bereits angemerkt wurde lediglich ein Vergleich iflt gegen eine Subtraktion isub (also zweimal vom Stack lesen, subtrahieren und wieder zurückschreiben) ersetzt. Auch ohne das ganze in x86 Assembler zu übersetzen kann man leicht abschätzen, das Variante 1 in der Praxis eher etwas schneller sein wird.
In diesem Thread
http://entwickler-forum.de/webx?50@@.4a87166a
wurde genau darauf hingewiesen. Die Behauptung, der Compiler würde diese Optimierung bereits durchführen ist nicht nachvollziehbar. Warum also ist diese Methode intelligent und elegant und warum ist sie für Compiler-Hersteller so nützlich?
Gruß,
Alwin
Comment