Fefes Blog

Fragen? Antworten! Siehe auch: Alternativlos

Sun Nov 8 2009

• [l] Wer auf dem Linux-Kongress meinen Vortrag gesehen hat, oder sich generell für Compiler-Optimierung interessiert, für den möchte ich hier mal auf dieses coole Projekt der LLVM-Leute hinweisen. Das schreibt mir gerade einer der LLVM-Leute, die sich meine Folien angeguckt hatten. Die haben da mal versucht, unter bestimmten Einschränkungen alle einfachen Integer-Funktionen zu generieren, und dann durch die üblichen Compiler laufen zu lassen, um nach Ausreißern zu suchen. Ihre Metrik heißt auch ganz lustig:

  I call the resulting codes "maximally embarrassing" since each function represents some significant failure to optimize.

  Und das übelste Beispiel, das sie bisher gefunden haben, ist:

  int ZZ_00005bbd(int x,int y){return m1s((x?0:x),a8s(y,y));}

  wobei m1s ein signed 16-bit multiply ist und a8s ein signed 8-bit add. Die Funktion sieht für meinen Geschmack schon mal nicht sehr offensichtlich aus, aber guckt sie euch genauer an. Der (x?0:x) Teil ist immer Null, hier wird also Null mal irgendwas gemacht, da kommt immer Null raus. gcc erkennt das und erzeugt Code, der konstant 0 zurück liefert. Wow.

  Update: Meine Folien machen gerade die Runde im Internet, und sind sowohl bei Lambda the Ultimate als auch bei Mike Melanson (der bei Adobe für das Portieren des Flash-Plugins nach x86_64-linux zuständig ist). Wow. :-)

  Usually I make sure that my slides contain everything said at the actual talk, so they are useful on their own if there is no video of the talk, but in this case I had way more slides than I could possibly cover in the allotted time, so I left things out. Basically, the gist was that for normal programming tasks, people should not waste time on doing optimizations that the compiler is already doing for them, or should be doing for them. And, in particular, I wanted to demonstrate that doing integer overflow and range checks can be free in some cases or almost free in the others. Performance is not a valid excuse to not do range checks and then create security vulnerabilities.

  In the slides, I basically say that for many cases the compiler is actually smarter than the programmer, and this is true, but it may have offended the handful of people for which it is not true. So let me state here: yes, some people are smarter than the compiler. The probability that you are one of those people or that you even know one of those people is very small. :-)