AGB für Knigge

[Alwin Ibba]

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

[Stefan Gawlick]

Hallo Alwin,
<br>
Die "Knigge-Beiträge" sind wirklich unglaublich. Was der Autor unter "Optimierung" versteht ist äußerst fragwürdig.
Lesbarkeit des Codes interessiert offensichtlich gar nicht, Exceptions werden zur Programmsteuerung verwendet und es werden "Optimierungen" vorgeschlagen, die nicht meßbar sind und so weiter und so fort.
Solchem Programm-Code möchte ich lieber nicht in Projekten begegnen. Aus Erfahrung kann ich sagen, daß solche "Optimierungen" beliebte Fehlerquellen sind, weil bestimmte Konstellationen nicht berücksichtigt werden, aussagekräftige Exceptions werden verschluckt, weil das Exception-Handling zur Programmsteuerung verwendet wird, Schleifenbedingungen (Subtraktion anstelle eines Vergleichs) werden von anderen Programmierern nicht richtig verstanden, z.B. wenn sie beim Debuggen auf solche Stellen stoßen...
<br>
Schon seit längerem ist das Erste was ich mache, wenn ich die neue Ausgabe des java Magazin aus meinem Briefkasten hole: ich reiße die Seite(n) mit der Knigge raus. (Kein Witz, das mache ich wirklich)
<br>
Schade nur, daß eventuell Anfänger und Unerfahrene sich das als "guten Programmierstil" abschauen; schließlich haben sie es ja in einem Fachmagazin gelesen.<br>
<br>
Schönen Gruß,
Stefa

[Hans Mole]

Da es den Knigge ab der nächsten Ausgabe nicht mehr in der Form geben wird
(*schnief*), wage ich mal ein Resumee:

1.) Der Name "Knigge" ist nicht nur "kritisch zu betrachten" sondern schlicht irreführend.
Er ist auch nicht "historisch gewachsen", wie Herr Szymanski uns glauben machen will,
sondern hat schon von Anfang an nicht gestimmt. Es wurde nie allgemeingültiges
gutes Verhalten gezeigt, wie man es von einem Knigge erwartet, sondern von der
1. Ausgabe an wurden fragwürdige und/oder völle falsche Performancetipps
gegeben.

2.) kritische Anmerkungen, dass man die genannten "Optimierungen" nur in
bestimmten (Ausnahme-)Fällen benutzen sollte, fehlten in der Kolumne bzw. wurden
erst dann genannt, als die Kritik hier im Entwicklerforum übermächtig wurde.

3.) Es wurde teilweise schlichtweg falsche Tipps gegeben (DCL, a < x < b, ...).
Da kann man sich nicht damit ausreden, man sollte nicht alles gleich umsetzen,
was man liest. Falsch bleibt falsch. Aber es scheint wohl unzumutbar zu sein,
das einfach mal zuzugeben.

4.) Was ich am schlimmsten finde: Javamagazin ist (auch) eine Zeitschrift für relativ unerfahrene
Javaprogrammierer. Klar gilt auch für diese Gruppe: nicht alles glauben, was man
liest. Trotzdem ist diese Gruppe naturgemäß anfälliger für schlechte Tipps.
Wenn so ein Programmierer auf eine Kolumne namens "Knigge" stößt, denkt er sich
wahrscheinlich "Oh toll, dann kann ich bestimmt was lernen" und reflektiert das
ganze wesentlich weniger als ein erfahrener Entwickler.
Diese Programmierer sind jetzt wahrscheinlich gerade dabei Unmengen an Javacode
zu produzieren, der wegen der Knigge-Tipps nicht nur schlechter lesbar, sondern
auch nicht ein Stück performanter als "sauber" geschriebener Code ist.

Gruß,
Han

[Thomas Billenkamp]

Hallo zusammen,
ich will mich an dieser Stelle nicht fachlich mit dem Knigge bzw. dem "AGB für Knigge" auseinandersetzen, hier im Forum haben das bereits andere Leser wie z.B. Alwin Ibba getan, wo Knigge Ausführungen als schlicht fehlerhaft nachgewiesen wurden. Am "AGB für Knigge" mißfallen mir zwei Tatsachen vehement. Beim Betrachten der Firmenzugehörigkeit der Herren Wiedeking und Szymanski macht man sich doch seine Gedanken bei der Feststellung, daß beide Autoren der selben Firma angehören. Ich will das ganze nicht weiter kommentieren, jeder Leser kann sich selbst seinen Reim darauf machen. Der zweite Punkt ist, daß mir der ganze Artikel viel zu sehr darauf abzielt, alles auf Mißverständnisse zurückzuführen. Man kennt das ja von Politikern die wegen Zitaten öffentlich zurückrudern müßen ("aus dem Zusammenhang gerissen", "falsch zitiert", "mißverstanden" etc.), der ganze Artikel ist mir viel zu sehr in genau dieser Rechtfertigungsrhetorik gehalten. Man soll das ganze eben nicht wortwörtlich nehmen, sondern situativ den jeweiligen Erfordernissen anpassen und überhaupt hätten die Kritiker des Knigge das meiste ohnehin falsch verstanden. Imho greift diese Erklärung überhaupt nicht. Ich weiß aus meinem Kollegenkreis bzw. von anderen regelmäßigen Lesern des Java Magazins, daß der Knigge in der Akzeptanz zwischen Ablehnnung und Belustigung schwankt. "Dass die Kolumne nett, interessant, und vor allem erfrischend ist..." wie Szymanski am Schluß seines Artikels schreibt, konnte ich beim besten Willen bisher bei keinem Kollegen feststellen und möchte das ganz einfach mal bezweifeln. Die ganz simple Wahrheit um den Java-Knigge ist doch schlicht und ergreifend die, daß es sich um eine ganz schlechte Artikelserie handelt. Und daran ändern auch alle Erklärungen und AGBs nichts. Wer mir jetzt vorwirft ich würde nur undifferenziert mies machen und keine Verbesserungsvorschläge bringen - wenn man sehen will, wie man so eine Reihe wirklich fundiert, fachlich richtig und gut geschrieben aufzieht, der werfe mal einen Blick in ein nicht unbekanntes Konkurrenzblatt zum Java-Magazin. Dort läuft seit geraumer Zeit eine Reihe namens "Effective Java" von Angelika Langer und Klaus Kreft, etwas in dieser Art würde ich mir auch im Java-Magazin wünschen.
Grüße
Thoma

[Foo Bar]

Zu einer schwachen Kolumne noch ein weinerlicher Abgang, wirklich sagenhaft. Warum ist es dem Autor nicht möglich, einfach mal zu sagen, dass man Mist gebaut hat? Aber natürlich sind die bösen Kritiker Schuld, wer auch sonst!

Also schickt er einen rührseligen Stellvertreter ins Rennen, der uns weismachen will, der gute alte Knigge habe alles gewusst, alles sei ihm klar und das ganze sei ein Riesenmissverständnis.

Der Gipfel ist jedoch, die a<b<c Optimierung als "Rat an die Compilerbauer" umzudeuteln, eine solche Dreistigkeit ist wohl nur im Java-Magazin möglich [als ob die Compilerbauer einen solch läppischen Rat vom Knigge nötig hätten]; ich würde meinen, dass dieser Trick unintelligent, unelegant und völlig unnütz ist, eigentlich nur eine kleine Java-Kuriosität.

Ich bin ja man gespannt wie's weitergeht, hätte da ein paar Anregungen:

1. Performance-Tipps sind sinnlos, wenn sie nicht durch Benchmarkergebnisse untermauert werden (am besten per Link, mit Quellcodes)

2. Mikroverbesserungen der Performance sind extrem schwierig zu messen, am besten man verzichtet ganz auf solche "Tipps"! Dieses Minenfeld können wahrscheinlich nur echte Experten betreten. Das Studium des Bytecodes hilft auch nichts, weil dieser nicht besonders gut optimiert ist, und den JIT mit einem Debugger anzuhalten und den Maschinencode zu studieren ist auch nicht leicht. Hinzu kommen verschienene JVMs und verschiedenen Plattformen (Sparc und X86 und Apple...)

3. Wahrscheinlich gibts da Honorar für einen Autor nicht her, solche komplexen Tests usw. durchzuführen; das muss man einfach realistisch sehen. Also lieber kleinere Brötchen backen.

4. Java ist ein extrem "reifes" Umfeld, es gibt genügend Erfahrungen und echte Tipps, die man ohne grosses Nachdenken befolgen kann (natürlich nicht muss); allein die Aufbereitung der Verfügbaren Best Practices, Pitfalls usw. würde zig Hefte füllen. Komisch dass der Knigge sowas einfach ignoriert hat

5. Mein Hauptwunsch: macht endlich Schluss mit der Seitenschinderei! Der Artikel über die Zukunft von Java in der aktuellen Ausgabe ist leider ein typischer Vertreter seiner Art: öde, schwurbelig und völlig ohne Neuigkeitswert.

Gibts denn keinen Redakteur, der solche Eseleien einfach ablehnt? Oder ist am Ende das Heft zu dick, in diesem Fall könntet ihr ja

Wie wärs eigentlich mal mit einem realistischen Artikel aus der Praxis? Mal ein Projekt vorstellen, bei dem nicht alles grossartig, wie geschmiert, mit atemberaubender Geschwindigkeit, kostengünstig und elegant und schön und sonnig und gut und besser läuft?

Und mal andere als die heldenhaften superguten Top-Programmierer (die zufällig auch fürs Java-Magazin schreiben) vorstellen, die ihre Jobs spielend, schnell und mit tollen selbst entwickelten Frameworks lösen

[Alwin Ibba]

<i>Mikroverbesserungen der Performance sind extrem schwierig zu messen, am besten man verzichtet ganz auf solche "Tipps"! Dieses Minenfeld können wahrscheinlich nur echte Experten betreten. Das Studium des Bytecodes hilft auch nichts, weil dieser nicht besonders gut optimiert ist, und den JIT mit einem Debugger anzuhalten und den Maschinencode zu studieren ist auch nicht leicht. </i>
<br>
Richtig, zumal der HotSpot ja auch noch Run-time profiling betreibt, das läßt sich wirklich kaum noch nachvollziehen (darum hab ich es gar nicht erst versucht :-). In dem eher einfachen if(0 <= z && z <= 255) Beispiel bestätigen aber die Messungen das, was man sogar am Sourcecode bereits ablesen kann, nämlich das if(z - 0x80000000 <= 0x800000FF) nichts bringt (sondern geringfügig langsamer ist, sogar wenn man den Wertebereich der Zufallszahlen so wählt, das die Abkürzung nie zuschlägt). Den Bytecode braucht man (optimiert oder nicht) in diesem Fall nicht, er bestätigt das Ergebnis nur nochmal. Ich habe ihn nur gebracht um die Behauptung "der Compiler setzt das schon um" zu widerlegen (wobei noch die Frage offen ist, welcher Compiler gemeint ist, aber der JIT vollbringt hier auch keine Wunderdinge, wie die Messung zeigt). Die javac oder HotSpot/JIT-Entwickler haben so einen Rat wohl kaum nötig.

Gruß,

Alwi

[Martin Wessel]

>Wie wärs eigentlich mal mit einem realistischen Artikel aus der >Praxis? Mal ein Projekt vorstellen, bei dem nicht alles grossartig, >wie geschmiert, mit atemberaubender Geschwindigkeit, >kostengünstig und elegant und schön und sonnig und gut und >besser läuft?

Genau darüber schreibt man aber eigentlich nicht gerne.
Denn man hat ja schliesslich auch einen Ruf zu verlieren.
Das gilt ja auch schon innerhalb einer Firma.
Schlechte Nachrichten kommen lieber unter den berühmten Teppich.
Ich habe selber als Consultant viele sehr interessante
Projekte betreut. Aber nur sehr sehr selten sind Kunden
damit einverstanden, diese Erfahrungen auch zu veröffentlichen.
Und das MUSS man verstehen.
Und dann hat man es endlich geschafft mit einem Kunden
öffentlich aufzutreten (Vortrag auf der JAX 2005, wir haben
keinen Druck ausgeübt und auch nix bezahlt, also alles
wirklich freiwillig), dann ist das Interesse eher gedämft.
Wirklich schade!

>Und mal andere als die heldenhaften superguten Top->Programmierer (die zufällig auch fürs Java-Magazin schreiben) >vorstellen, die ihre Jobs spielend, schnell und mit tollen selbst >entwickelten Frameworks lösen?

Auch das muss man verstehen. Die Berater machen Werbung für sich und ihre Frima. Der wirkliche Praktiker weiss aber, dass eben nicht alles Gold ist was glänzt. Aber er weiss auch, dass diese Person schon mal ein Projekt erfolgreich abgeschlossen hat.
Denn über gescheiterte Projekte schreibt man nicht (siehe oben)

[Foo Bar]

Aha,

man muss das also verstehen, wenn im Java Magazin Märchengeschichten aus dem Wolkenkuckusheim geschrieben werden?

Und auch das muss man verstehen: dass das Java Magazin ein Marketing Instrument ist, in dem supertolle Berater (man denke an den Knigge) ihren Käse absondern und irgendwelche erfundenen Albernheiten über ihre grandiosen Erfolge verbreiten dürfen, um Werbung für sich und Ihre Firma zu machen???

Und die ahnungslosen Käufer bezahlen für den Mist??????????

BTW: Es müssen ja keine gescheiterten Projekte sein, aber etwas mehr Realismus - und wenns nur bei der Wortwahl ist - könnte nicht schaden; in der Praxis sind "fantastische Geschwindigkeiten" und "atemberaubende Erfolge" eher selten

[Foo Bar]

Nachtrag

<i>Richtig, zumal der HotSpot ja auch noch Run-time profiling betreibt,
das läßt sich wirklich kaum noch nachvollziehen (darum hab ich es gar nicht erst versucht :-)</i>

verständlich :-) ich denke auch dass das fast unmöglich ist, durch diese "dynamische Verbesserung", die "oft ausgeführten Code" dann "noch besser optimiert" sind wohl alle Versuche hier eine Aussage zu machen sinnlos

und um bei a<b<c Beispiel zu bleiben: der java bytecode der oben gepostet ist dürfte wohl 1-1 in maschinensprache übertragen werden - reine Vermutung mal von mir - und bei den heutigen taktzyklen muss schon eine kniggesches Genie daherkommen um da überhaupt irgendeinen gewinn rauszulesen...

<i>
Ich habe ihn nur gebracht um die Behauptung "der Compiler setzt das schon um" zu widerlegen (wobei noch die Frage offen ist, welcher Compiler gemeint ist, aber der JIT vollbringt hier auch keine Wunderdinge, wie die Messung zeigt). Die javac oder HotSpot/JIT-Entwickler haben so einen Rat wohl kaum nötig.
</i>
Ganz genau!!! Diese Behauptung im Artikel war wohl der größte Witz..