Das offizielle Blog der h8u.de Gemeinde

Welches ist die Höchstgeschwindigkeit einer unbeladenen Schwalbe?

-- Brückenwächter, "Monty Python - Die Ritter der Kokosnuss"

Eigentlich wollte ich ja mal wieder einen Beitrag machen, der nichts mit Computer zu tun hat, aber dieser wird es noch nicht sein. Es ist quasi ein Nachtrag zu dem Beitrag GCC mit Atom Optimierung. Eher durch einen Zufall ist mir aufgefallen, dass der Testdurchlauf ("Queen Greatest Hits I" von .wav nach .ogg wandeln, mit Standardeinstellungen) auf meinem Haupt-Linux-Rechner auf einmal einen Faktor von circa 30 statt den erwarteten circa 20-fach brachte.

Der Verwunderung konnte erst nach einigen Minuten Einhalt geboten werden: ich hatte einen "Tippfehler" gemacht: statt dem OggVorbis-Encoder meines Testszenarios hatte ich den OggVorbis-Encoder der Linux-Distribution verwendet. Statt der Version 1.0.2 wurde nun 1.2.0 verwendet, aber das kann nicht für einen Geschwindigkeitszuwachs von 50% verantwortlich sein. Dafür schon eher die Architektur: mein Linux läuft unter 64 Bit, und nicht wie das Testprogramm mit nur 32 Bit. Da wurde ich neugierig: kann der Schritt von 32 auf 64 Bit für einen Performancezuwachs von 50% verantwortlich sein?

Dafür habe ich mir folgendes Testszenario aufgebaut: es wurden zwei Testsysteme aufgesetzt, eins mit dem Celeron 220, der die gleiche Architektur wie erste Generation der "Core 2"-CPUs aufweist, und eins mit dem Atom 230. Auf dem wurde die 64-Bit Version von Ubuntu 10.04 alpha installiert. In dieser Umgebung wurde dann oggenc einmal als 64-Bit- und einmal als 32-Bit-Version laufen gelassen. Ich hatte mit einem anderen System schon mal ermittelt, dass es keinen messbaren Performanceunterschied von einem 32-Bit Programm auf einem 32-Bit- und 64-Bit-System gibt. Zum Vergleich gibt es noch die Messergebnisse meines "Haupt-Linux-Rechners", bei dem mir der Leistungszuwachs aufgefallen ist. Der Testparcours ist (wie bei mir üblich) das OggVorbis-Encodieren von "Queen Greatest Hits I".

"Do you have any scars, Charlie Brown?"
"Lots of them.. but they're all mental!"

-- Peanuts by Charles M. Schulz, 6. März 1956

Ich führe seit längerer Zeit eine kleine Statistik, in welchem Umfang die Downloads der von mir angebotene Software stattfinden. Wenn ich da in letzter Zeit mal reingeguckt habe, war ich doch etwas erstaunt. Die Programme, die am häufigsten runtergeladen wird, sind interessanterweise Programme aus der Rubrik "schnelle und schmutzige Hacks": es sind Programme, die ich ursprünglich für die Eee PC 701, 901 und 900A mit der vorinstallierten Linux-Distribution von Xandros zusammengezimmert hatte, um irgendwelche Unzulänglichkeiten zu beheben. Mein Engagement in Sachen Xandros-auf-EeePC habe ich mittlerweile eingestellt. Die Seite mit der Software lasse ich aber selbstverständlich stehen, weil es ja anscheinend noch genug Leute gibt, die damit was Anfangen können.

Das mit Abstand am häufigsten runtergeladene Programm ist übrigens der schmutzigste Hack von allen. Es patcht die Signatur des Flash-Players, so dass er auch mit die alte libc des Eee PC akzeptiert. Das Tool wurde in diversen Blogs, vor allem englischsprachige, beschrieben als eine veritable Möglichkeit Flash zu installieren. Besonders interessant finde ich dabei, dass das Programm auch dazu zweckentfremdet wird, den Moonlight-Player zu pachten, dass er auch auf dem Eee PC läuft.

Allerdings ist es doch irgendwie schade, dass die Software in die ich deutlich mehr Arbeit investiert habe bei weitem nicht den selben Anklang findet.

Diese Flash-Seuche frisst CPU-Zeit wie Garfield Lasagne.

-- mhbofh, in den Heise Foren

Na endlich ist es raus. Die Spatzen haben es ja schon länger von den Dächern gepfiffen, aber Gewissheit gab es erst diese Woche von Kaplan Steve: das neue, tolle Ding von Apple ist das iPad. Nach näherer Betrachtung ein iPod Touch auf Steroiden. Selten war die IT-Welt so gespannt auf die Produktvorführung eines Unternehmens.

Im Nachhinein bleibt die Frage: "wieso"? Innovatives kann ich in dem iPad nicht ausmachen. Es ist eher die konsequente Weiterführung der bisherigen Produktstrategie. Seit dem Newton, der in den 90ern seiner Zeit um circa 10 Jahre voraus und deshalb ein Flop war, hat jedes Produkt einen Gewinn zu erwirtschaften. Auch beim iPad ist das nicht anders: wie die Fruchtfliegen tauchen jetzt Ankündigungen auf, dass für das Gerät entwickelt werden soll. Dabei hält Apple auch hier an altbewährtem fest: dem Store, als einziger Bezugs- und Installationsquelle für Software. So kann man sich lästige Konkurrenz relativ einfach vom Hals halten. Microsoft ist schon für weniger "Monopolsicherung" verknackt worden.

Program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence.

-- Edsger Wybe Dijkstra, "The Humble Programmer, ACM Turing Lecture 1972"

Einer der Hauptunterschiede der Architektur eines Intel Atom Prozessors im Vergleich zu den meisten anderen ix86-kompatiblen Prozessoren ist die so genannte "out-of-order execution". Das bedeutet, dass der Prozessor die Befehle so umsortiert, dass er sie möglichst schnell ausführen kann, ohne den eigentlichen Ablauf des Programms zu verändern. Beim Atom wurde diese Technik außen vorgelassen, um so den Prozessor einfacher und kleiner gestalten zu können.

Nun bringt der GCC 4.5 eine extra Optimierung für den Atom mit. Diese soll nun die Idee der out-of-order execution quasi vor verlagern, so dass nun der Compiler die Befehle schon in der optimalen Reihenfolge generiert. Das wollte ich mal ausprobieren, und habe meinen alten Atom 230 reaktiviert, ein Ubuntu 10.04 alpha drauf installiert, und den aktuellen Stand des gcc aus dem Subversion-Archiv des Projektes selbst kompiliert.

[Rob Pike's] Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures.
[...]
Ken Thompson, the man who designed and implemented the first Unix, reinforced Pike's rule 4 with a gnomic maxim worthy of a Zen patriarch: When in doubt, use brute force.

-- Basics of the Unix Philosophy

Zu meinen Aufgabenbereichen gehört bei meinem Job auch das Portieren von altem Code auf unsere neue Plattform. Einer der größten Unterschiede dabei ist, dass sich der Compiler von GCC 3.x auf GCC 4.x geändert hat. Das bringt einige Probleme mit sich. Interessant finde ich dabei, wie die Probleme von den Leuten aufgenommen wurden, die für den ursprünglichen Code verantwortlich waren.

Ein fast schon klassisches Beispiel: in C++-Code wurde eine Klasse angelegt, die verschiedene Variablen enthält, die aber nicht initialisiert wurden. Der GCC 3.x hat die Speicherbereiche anscheinend mit Nullen gefüllt, der GCC 4.x erwartet vom Programmierer, dass er dort etwas genauer spezifiziert, was er eigentlich gemeint hat. Tut er dies nicht, wird (vermutlich aus Performancegründen) der Speicher dort auch nicht initialisiert. Dies hat zur Folge, dass die Software mal geht und mal nicht, je nachdem, was gerade zufällig an dieser Stelle im Speicher steht. So ziemlich jeder weiß, dass solche Fehler sind schwer zu finden sind. Erste Reaktion die ich auf den Hinweis bekommen habe, dass man das so besser nicht machen sollte: "Wieso hat denn den Fehler im GCC 4 noch keiner behoben?" Ich weiß bis heute nicht, ob diese Frage wirklich ernst gemeint war, oder doch nur Spaß... Meine sonstigen Erfahrungen lassen mich allerdings ersteres annehmen.

(Nicht nur) bei uns ein weiterer Klassiker: während des Kompilieren werden Warnungen noch und nöcher geworfen. Bei den größeren Einzelteilen sind sie im vierstelligen Bereich. Die Herangehensweise ist auch schon klassisch: "Wieso die Warnungen rausnehmen? Das Programm läuft doch." Natürlich wird es für einen schwer, selbst Code von besserer Qualität in ein solches Moloch einzufügen. Die Warnung vom eigenen Code gehen in dem Sumpf einfach unter. Ein Kollege hat das die Tage so beschrieben: wenn ein Haus irgendwo steht und die Scheiben heile sind, bleiben sie auch heile. Ist aber erst mal eine kaputt, geht es schnell, bis auch die anderen eingeschmissen werden.

"Und? Wie war Dein Wochenende?" - "Fresse halten!"

-- sich gelegentlich wiederholender Dialog zwischen mir und einem Kollegen

Wo ich gerade in den Erinnerungen die Zeit in meiner vorherigen Firma geschwelgt habe, lege ich gleich noch einen nach. Dort hatte ich zwei Kollegen, die ein besonderes Verhältnis zum Fußball haben: der eine ist Hamburg-Fan, der andere Bremen-Fan. So wie man sich als Laie Fußball-Fans vorstellt, mit Schal und allem.

Besonderes spaßig waren die Montage, wenn Bremen gewonnen und Hamburg verloren hatte, oder noch besser umgekehrt. Dann war es immer schön der ersten Begegnung der beiden beizuwohnen, wenn dann die Diskussionen und Rechtfertigungen stattfanden.

Irgendwann habe ich dann auch angefangen am Montag bei den beiden Kollegen mal besonders scheinheilig nachzufragen, wie denn das Wochenende so war um dann noch etwas Salz in die Wunde zu streuen, wenn eins der Teams mal wieder ordentlich verkackt hatte. Nein, eigentlich ging es genau andersherum: ursprünglich hatte ich ohne den Hintergedanken an Fußball gefragt, wie das Wochenende war, und bekam nur eine Antwort das Spiel des Wochenendes betreffend. Der Rest vom Wochenende war dann anscheinend nicht weiter erwähnenswert.

Später dann bin ich noch einen Schritt weiter gegangen: wenn mir Fußballergebnisse untergekommen sind, habe ich mir gemerkt, wie Bremen und Hamburg gespielt haben, um besser mit meiner Frage besser vorbereitet zu sein. Die Antworten auf meine Frage gingen dann von "blendend, wir haben sie lang gemacht" bis hin zu "sei bloß ruhig, Du weißt doch, dass wir abgelattet wurden". Top war natürlich, wenn die beiden Teams gegeneinander gespielt haben. Bei dem Tief, das Bremen in der vorletzten Saison hatte, hat der entsprechende Kollege dann einmal festgestellt: "Och, weißt Du, ich bin zu der Erkenntnis gelangt, dass Fußball eigentlich gar nicht so wichtig ist". Das Zitat am Anfang stammt übrigens vom Hamburg-Fan...

Ich grüße Euch beide!

Was bedeutet schon Geld? Ein Mensch ist erfolgreich, wenn er zwischen Aufstehen und Schlafengehen das tut, was ihm gefällt.

-- Bob Dylan

Wieder einmal wohnte ich einem Ausstand von Ex-Kollegen bei. Das ist der häufigste Grund, dass ich "meine alte Firma" besuche. Aber irgendwie sollte ich das Ganze besser anders anfangen. Also noch mal von vorne:

Bei meiner letzten Arbeitsstelle hatte ich echt Glück. Das Aufgabengebiet passte recht gut zu dem, was ich konnte. Viel besser passte aber das Arbeitsumfeld - sprich meine Kollegen - zu mir. Damals waren wir so circa 35 Leute, also deutlich weniger als die 80 bei meinem Weggang. Besonders Glück hatte ich mit meinem Chef: die Chemie stimmte einfach.

Der Umstand, dass wir uns gegenüber saßen, verstärkte dies nur. Aufgrund seiner Position war er auch recht viel unterwegs. Als sein Gegenüber wurde ich auch ein bisschen so etwas wie ein "Anrufbeantworter" für die Kollegen. Denn die meisten Fragen, die mir in meiner Anfangszeit dort gestellt wurden drehten sich nicht um mich oder mein Aufgabengebiet, sondern um ihn: "Wo ist Ralph? Wann ist er wieder da?" Ich lernte schnell, auf diese Fragen vorbereitet zu sein, indem ich ihm dieselben Fragen stellte. Die ersten Male guckte er mich noch fragend an, worauf ich ihm dann erklärt habe, dass ich an jeden Tag, an dem er nicht da ist, genau diese Fragen mehrfach beantworten muss. Später bekam ich die Antworten schon ohne zu fragen...

Zurückblickend muss ich sagen, dass diese zwei Jahre als die glücklichsten bezeichne, die ich in meiner bisherigen Berufslaufbahn erlebt habe. Nicht vom Fachlichen her, da fühle ich mich bei meinem jetzigen Job noch besser aufgehoben, aber vom Menschlichen her. Auch mit meinen Kollegen, mit denen ich mich heute rumplage, stimmt im Großen und Ganzen die Chemie, und meinen (Sitz-)Platz in der Firma möchte ich mit keinem anderen dort tauschen. Aber damals war das doch irgendwie etwas anderes: es war der erste Job nach dem Studium und der zweite Vollzeitjob überhaupt; neben dem Studium hatte ich aber schon einiges an Erfahrung in diversen Teilzeitjobs sammeln können. So konnte ich recht gut abschätzen, was ich kann, und was nicht. Es gab mir für den eigentlichen Einstieg in mein Berufsleben ein gewisses Selbstvertrauen.

Lucy: "Ha! You got your shoes on the wrong feet again!"
Linus: "I don't have time to worry about the non-essentials! These are my shoes and these are my feet.. Shoes are on feet... That's all I care about!"

-- Peanuts by Charles M. Schulz, 6. März 1957

Normalerweise pflege ich im Bereich "Computer" eher einen konservativen Ansatz: nichts einsetzen, was sich nicht schon wenigstens woanders bewährt hat. Wenn ich programmiere achte ich im Allgemeinen auf eine breite Einsetzbarkeit meiner digitalen Ergüsse. Die meisten meiner Programme laufen auf vielen Betriebssystemen. Um dieses Ziel zu erreichen setze ich das Qt-Framework ein, welches das Schreiben von Multiplattform-Applikationen sehr stark erleichtert.

Mich überzeugt ein Programm erst dann, wenn man nicht erst noch einen Tag oder länger einen Rechner installieren muss, nur um überhaupt mit dem Programmieren anfangen zu können. Genauso will ich aber auch, dass man für meine Programme auch nicht viel machen muss, um sie laufen zu lassen. Deshalb habe ich mir mal einen gebrauchen Mac Mini gekauft, damit ich meine Programme bereits installationsfertig auch für diese Plattform anbieten kann. Für Windows gibt es sowieso mehr als genug Möglichkeiten, seine Software benutzerfreundlich auszuliefern. Das Standard-Installationsformat für Unix-Derivate die nichts mit Linux zu tun haben, ist sowieso der Quellcode.

Bleibt noch Linux. Da wird es kompliziert. Da gibt es zum Beispiel verschiedene Paketverwaltungen, was aber nicht wirklich ein Problem darstellt, da es dafür Konvertierungsprogramme gibt. Problematischer wird es zum Beispiel bei der verwendeten Codebasis, da möchte ich mal wieder auf das eingangs erwähnte Qt zurück kommen. Das wird kontinuierlich weiterentwickelt, bleibt aber dabei innerhalb der Version 4.x abwärtskompatibel, so läuft ein Programm, welches nur Funktionen von 4.3 verwendet auch unter 4.4 und 4.5. Andersherum geht das natürlich nicht.