Hello World!

Hello World

Now we’ve got two sons. Our youngest is ten days old now.

Camera Model: Nikon D90
Lens: Nikon AF-S DX Nikkor 18-105mm 1:3.5-5.6G ED VR
Focal Length: 105.00 mm
Focal Length (35mm Equiv): 157 mm
Exposure Time: 1/60 sec
F-Number: f/5,6
Shooting mode: Aperture priority
Exposure bias: 0 EV
Flash: Yes
ISO: 200
Image at flickr, large version

Learning to fly

Learning to fly

From a portrait session with our neighbours. We did some "traditional" portrait stuff and later we had the idea of throwing her into the air… So, don’t try this at home! Throwing the kids is not the difficult part, ykwim? 😉

Camera Model: Nikon D90
Lens: Tokina 12-24mm 1:4 DX
Focal Length: 12.00 mm
Focal Length (35mm Equiv): 18 mm
Exposure Time: 1/320 sec
F-Number: f/8,0
Shooting mode: Shutter priority
Exposure bias: 0 EV
Flash: Yes
ISO: 200
Image at flickr, large version

Besserer Maschinencode mit clang

LLVM ist das nächste große Ding. Nach all den Jahren, wo man es hingenommen hat, dass der gcc so ist, wie er ist und man heimlich denkt, dass der Microsoft Visual C++ Compiler doch irgendwie besser war, taucht plötzlich LLVM mit clang im Gespann auf und schickt sich an die Welt zu erobern.

Wer von LLVM noch nie etwas gehört hat, dem kann ich einen ganz wunderbaren Podcast empfehlen. Kurz gesagt: die Low Level Virtual Machine ist eine Compiler Infrastruktur, ein Compiler-Baukasten. Es gibt verschiedene Frontends, die aus unterschiedlichen Eingabesprachen (z.B. C, Objective C, Fortran, in Ansätzen auch C++ ) einen Bytecode generieren. Dieser Bytecode wird optimiert und im letzten Schritt mittels eines Backends in nativen Maschinencode für eine konkrete Architektur übersetzt.

Diese Verarbeitung ist nicht etwa tief im Compiler verborgen, sondern kann ganz praktisch mittels Pipes zusammengebaut werden:

Neben dem Satz an Standard-Optimierungen kann man sich noch mehrere Dutzend Spezial-Optimierungen die heraussuchen, wenn man denkt, dass das eigene Programm die nötig hat. Optimierungen kosten natürlich Zeit und so ist man eher geneigt während der Entwicklung wenige Optimierungen zugunsten schneller Compilerzeiten zu wählen, während man im Release-Stadium mehr Optimierungen wählt um die Performance zu optimieren.

Natürlich möchte man nicht in all seine Makefiles jetzt auf solche Pipe-Orgien umstellen. Es gibt zum Glück ein „drop in replacement“ für den gcc: clang. Man muss nur noch an einer Stelle im Makefile die gcc-Definition durch clang ersetzen – fertig. Alle Parameter werden verstanden, Compiler-Parameter übernommen – so unkompliziert, dass man nur noch staunen kann:

Seit dem Podcast zu LLVM nagt in meinem Kopf die Idee, das ganze im aktuellen Projekt zu testen. In den beiden letzten Mobile Macs Sendungen war clang ebenfalls Thema, was dazu führte, dass heute das LLVM-Virus bei mir ausgebrochen ist 😉

Ich habe also das aktuelle Projekt (365.000-Zeilen C-Code) genommen und genau eine Zeile im Makefile geändert. Und es lief ohne Probleme. Ok, ich habe noch einen Fehler in unserem Makefile gefunden, aber dafür kann ja clang nichts. Die absolut problemlose Umstellung hat mich schon überrascht.

Aber warum sollte man dem gcc untreu werden, was bringt einem clang konkret? Da wären zunächst aussagekräftige Warnungen. Ich liebe Warnungen und predige bei jeder Gelegenheit wie wichtig es ist, auf die Warnungen vom Compiler zu hören. Das ist immer der Moment, in dem die Kollegen plötzlich etwas wichtigeres zu tun haben … 😉 clang spuckt Warnungen aus, mit denen man wirklich etwas anfangen kann:

Dagegen die Meldung vom gcc:

Dann wäre noch das Thema Performance. Es gibt Aussagen wie „OpenSSL wird 10% schneller“ (letzte MM-Sendung). Das macht schon neugierig und ich werde in der nächsten Woche auf jeden Fall ein paar Benchmarks durchführen um dem auf den Grund zu gehen. Jede Anwendung ist anders und bei unserem Projekt muss man erstmal sehen, was es wirklich bringt.

Wenn man aber „einfach so“ mehr Performance erhält, ist das ein hoch interessantes Thema. Ein Kunde von uns lastet mit unserer Anwendung eine 8-Core Maschine voll aus. Aufgrund gesteigerter Datenmengen wird diese Maschine bald zu klein sein. Wenn wir ihm sagen können „behalte Deinen Hobel, wir haben noch ordentlich etwas rausgeholt“ ist das für den Kunden natürlich ein Gewinn. Er kann die Hardware länger nutzen und spart Mirgrationskosten. Für uns ist das eher schlecht, weil wir am Lizenzupgrade nichts verdienen … aber ich bin Techniker und kein Verkäufer 😉

Maulbronn Abbey (3)

Maulbronn abbey

This is my favorite of the series.

Camera Model: Nikon D90
Lens: Tokina 12-24mm 1:4 DX
Focal Length: 12.00 mm
Focal Length (35mm Equiv): 18 mm
Exposure Time: 1/60 sec, 1/20 sec, 5 sec
F-Number: f/4,0
Shooting mode: Manual
Exposure bias: 0 EV
Flash: No
ISO: 100
Image at flickr, large version

Maulbronn Abbey (2)

Maulbronn abbey

The same spot, but another view.

Camera Model: Nikon D90
Lens: Tokina 12-24mm 1:4 DX
Focal Length: 12.00 mm
Focal Length (35mm Equiv): 18 mm
Exposure Time: 1/13 sec, 1/2 sec, 2 sec
F-Number: f/4,0
Shooting mode: Manual
Exposure bias: 0 EV
Flash: No
ISO: 100
Image at flickr, large version

Maulbronn Abbey

Maulbronn Abbey

The sun-rays are faked 🙂

Maulbronn Abbey is the best preserved medieval Cistercian monastery complex in Europe. (more)

Das Kloster Maulbronn gilt als die am besten erhaltene mittelalterliche Klosteranlage nördlich der Alpen. Hier sind alle Stilrichtungen und Entwicklungsstufen von der Romanik bis zur Spätgotik vertreten. (mehr)

Camera Model: Nikon D90
Lens: Tokina 12-24mm 1:4 DX
Focal Length: 12.00 mm
Focal Length (35mm Equiv): 18 mm
Exposure Time: 1/1600 sec, 1/400 sec, 1/100 sec, 1/25 sec, 1/6 sec, 0,8 sec
F-Number: f/5,0
Shooting mode: Manual
Exposure bias: 0 EV
Flash: No
ISO: 100
Image at flickr, large version

Eternal Twins

Eternal Twins

The title is inspired by this song 😉

Camera Model: NIKON D90
Lens: Nikon AF-S VR 70-200mm/2.8G IF-ED
Focal Length: 200 mm
Focal Length (35mm Equiv): 300 mm
Exposure Time: 1/500
F-Number: f/5,6
Shooting mode: Aperture priority
Exposure bias: -1/3 EV
Flash: No
ISO: 400
Image at flickr, large version

Whoopee

Whoopee

Camera Model: Nikon D90
Lens: Nikon AF-S DX Nikkor 18-105mm 1:3.5-5.6G ED VR
Focal Length: 105.00 mm
Focal Length (35mm Equiv): 157 mm
Exposure Time: 1/320 sec
F-Number: f/5,6
Shooting mode: Program automatic
Exposure bias: 0 EV
Flash: No
ISO: 200
Image at flickr, large version

Im schwarzen Moor

Im schwarzen Moor

Well, the HDR is completely overdone, the sharpening destroys the clouds … but I like it somehow.

Camera Model: Nikon D90
Lens: Tokina 12-24mm 1:4 DX
Focal Length: 12.00 mm
Focal Length (35mm Equiv): 18 mm
Exposure Time: 1/200 sec, 1/100 sec, 1/40 sec,
F-Number: f/7,1 f/5,0 f/4,0
Shooting mode: Program automatic
Exposure bias: 0 EV
Flash: No
ISO: 100
Image at flickr, large version

Die SPD in Thüringen

Die Situation in Thüringen fasst Fefe treffend zusammen: „Die Linken haben trotz mehr Sitzen freiwillig auf das Ministerpräsidentenamt verzichtet, damit die SPD keine Ausrede hat, um mit der CDU zu koalieren, und die machen es trotzdem.
Tja, auf die SPD ist – wie immer – Verlass. Vielleicht knacken sie ja bei der nächsten Bundestagswahl die 5% Hürde – in umgekehrter Richtung.

Kanga-bloody-roo

Kanga-bloody-roo

Camera Model: NIKON D90
Lens: Nikon AF-S VR 70-200mm/2.8G IF-ED
Focal Length: 200 mm
Focal Length (35mm Equiv): 300 mm
Exposure Time: 1/80
F-Number: f/5,0
Shooting mode: Aperture priority
Exposure bias: -1/3 EV
Flash: No
ISO: 100
Image at flickr, large version

kurzer Schauer

kurzer Schauer

Camera Model: Nikon D90
Lens: Nikon AF-S DX Nikkor 18-105mm 1:3.5-5.6G ED VR
Focal Length: 105.00 mm
Focal Length (35mm Equiv): 157 mm
Exposure Time: 1/25 sec
F-Number: f/5,6
Shooting mode: Aerture priority
Exposure bias: -1/3 EV
Flash: No
ISO: 100
Image at flickr, large version

An der schönen Isar

An der schönen Isar

Camera Model: Nikon D90
Lens: Nikon AF-S DX Nikkor 18-105mm 1:3.5-5.6G ED VR
Focal Length: 58.00 mm
Focal Length (35mm Equiv): 87 mm
Exposure Time: 1/640 sec
F-Number: f/6,3
Shooting mode: Program automatic
Exposure bias: 0 EV
Flash: No
ISO: 100
Image at flickr, large version

Stacktrace gefällig?

Gelegentlich braucht man einen Stacktrace. Ich bin heute über ein Problem gestolpert, bei dessen Lösung mir ein Stacktrace sehr helfen würde.

20090907_dddlogoEine unserer Bibliotheken kümmert sich um Speichermanagement. Das sind kleine Wrapper um malloc / free, die Buchhaltung über den Speicher führen und bei Fehlern entsprechende Meldungen ausgeben. Also der übliche Weg für das Speichermanagementproblem in C, es gibt duzende Lösungen die ähnlich funktionieren.

Das Problem heute war, dass Speicher freigegeben werden sollte, der nie allokiert war oder schon einmal freigegeben wurde. Er war auf jeden Fall nicht mehr als belegt gekennzeichnet und konnte somit nicht freigegeben werden. Programme ohne solch ein Speichermanagement würden an dieser Stelle abstürzen, bei uns taucht nur eine Meldung im Log auf.

Diese Meldung war mein Startpunkt für die Suche. Die Aufrufe der free-Wrapperfunktion sind jedoch in vielen Sourcefiles auf tausenden Zeilen Code verstreut. Wie soll man dort den einen Aufruf finden, der die Ursache für die Meldung ist?

Genau: ein Stacktrace muss her. Der schmutzige Weg wäre, das Programm mutwillig zum Absturz zu bringen. Dann kann man sich aus dem core-File den Stack rauspopeln und weiss, woher der Aufruf kommt.

Es gibt jedoch etwas viel schöneres: backtrace() aus der glibc. Mit ein paar Zeilen Code kann man an jeder beliebigen Stelle des Programms einen Stacktrace erzeugen:

Ich habe also in der free-Wrapperfunktion backtrace() eingebaut und konnte mir den Stacktrace für den Fehlerfall ausgeben. Im Log erhält man dann etwa diese Ausgabe:

Ok, das sieht schon mal gut aus 😉 Jetzt muss man nur noch yourbinary in den ddd laden um die Speicheradressen in Codezeilen umzuwandeln – et voilà: schon ist die bösartige Zeile Code identifiziert.

Pages: <<< 1 2 3 ... 6 7 8 9 10 ... 95 96 97 >>>