ck's Blog

War neulich auf’m tittlinger Wertstoffhof um brav unseren recycelbaren Hausmüll dort abzuliefern. Da ich das öfters mache, bin ich’s schon gewohnt, dass die Container für die Haushalts- und normalen Elektrogeräte von Osteuropäern besetzt sind, die gleich alle technischen Abfälle prüfen, ob sie die noch irgendwie verwerten können.

Mir ist das ja reichlich egal, ob mein Elektroschrott nun fachgerecht entsorgt wird oder ob die Tschechen, Slowaken, Polen oder sonstwer versuchen, noch ‘n bisschen Geld aus den alten Teilen raus zu schlagen.

Neulich also haben mich die Elektroschrottsammler bereits am Eingang des Recyclinghofs abgefangen. So richtig wie bei der Mautstelle kommst dir da vor.

“Haben Elektroteile? Ach, ich sehen! Zwei Satellitenreceiver. Seinen digital?”
“Naa, nur analog.”
*traurig schau* “Naja, ich nehmen trotzdem. Haben auch noch Frnzn?”
“Frnzn?”
“Ja, Frnzn!”
“Frnzn? Achso, Fernseher! Naa, hab ich jetzt ned dabei.”
“Oder Waschmaschine?”
*nach hinten ins Auto schau* “Sieht jetzt nicht so aus, als würde da ‘ne Waschmaschine reinpassen.”
“Na gut, dann bis nächste mal.”

Fleißige Leser meines Blogs kennen ihn schon, den “Nagus’ all in!”. Für alle anderen kurz Zusammengefasst: Da Dom veranstaltet viermal im Jahr (immer am Anfang und am Ende vom Semester) ein kleines Pokerturnier mit zirka acht Leuten bei sich zu Hause. Das Turnier für den Beginn des Sommersemesters 2008 stand letzten Freitag Abend auf’m Programm.

Da Andi legte ‘nen richtig heftigen Start hin und nahm gleich die ersten vier von insgesamt acht mitspielenden Personen im Alleingang vom Tisch, was ihm die Chipleaderschaft bescherte. Sein Monstertum wurde nur noch von seinem grandiosen Ausscheiden übertroffen, denn nach diesem Durchmarsch war’s diesmal auch schon vorbei für’n Andi. Für mehr als Platz Vier reichten dann tatsächlich die ganzen Chips nicht.

Gewonnen hat diesmal da Flo. Damit hat er’s mir nachgemacht und konnte als zweite Person überhaupt seinen Titel verteidigen. Mit seinem Erfolg rückt er mir in der ewigen Bestenliste, die’s am Ende des Blogeintrags zu bestaunen gibt, ganz schön auf den Pelz. Dafür reichten ihm im Prinzip zwei gute Spiele gegen ‘n Dom im Heads-Up. Dazwischen hatte der Dealer einiges zu tun. So viele nicht gespielte Hände im Heads-Up kommen selbst beim Nagus’ all in! nicht all zu oft vor.

Ich selbst hab Fortuna’s Gaben wohl schon allesamt letzten Mittwoch im Wahn’s Inn verzockt. Da hatte ich zwei von drei Full Houses innerhalb von gerade mal fünf Spielen. Bei der siebten Auflage des Nagus’ all in! allerdings habe ich sage und schreibe kein einziges Spiel gewonnen. Und dabei hab ich in meinen Augen keinen Fehler gemacht. Gute Hände habe ich gespielt, schlechte rechtzeitig weg geworfen. Nur ein einziges Mal musste ich mich ärgern, dass ich eine Hand, mit der ich gewonnen hätte, weg geworfen habe. Jedoch zog ich dann bei jedem Showdown, bei dem ich mit von der Partie war, den Kürzeren. So reichte es diesmal nur für Platz Sechs, meine (numerisch) schlechteste Platzierung bisher.

						4.	5.	6.	7.	8.	9.	Teiln.
	1.	Christoph R.	2x	1x	-	1x	2x	1x	-	-	-	7
	2.	Florian N.	2x	-	1x	1x	2x	1x	-	-	-	7
	3.	Michael N.	1x	1x	-	-	-	-	-	3x	-	5
	4.	Stephanie S.	1x	-	1x	1x	-	-	1x	-	-	4
	5.	Fabian F.	1x	-	-	-	-	1x	-	-	-	2
	6.	Dominik S.	-	2x	1x	3x	-	-	-	1x	-	7
	7.	Andreas S.	-	2x	1x	1x	-	1x	-	1x	1x	7
	8.	Christoph E.	-	1x	1x	-	1x	-	-	-	-	3
	9.	Matthias S.	-	-	1x	-	1x	1x	2x	-	-	5
	10.	Christoph W.	-	-	1x	-	-	-	-	-	-	1
	11.	Nicole H.	-	-	-	-	1x	-	-	-	-	1
	12.	Sabrina S.	-	-	-	-	-	1x	-	-	-	1
	13.	Daniel H.	-	-	-	-	-	-	2x	-	-	2
	14.	Michael K.	-	-	-	-	-	-	1x	-	-	1

An dieser Stelle wie immer noch der Verweis auf den entsprechenden Blogeintrag des Gastgebers.

Von meinem Programmierpraktikum habe ich hier in meinem Blog ja schon so einiges erzählt. Mit diesem Artikel möchte ich nun abschließend meine zusammenfassende Ausarbeitung der Allgemeinheit zur Verfügung stellen.

Ausarbeitung: zybesi.pdf (360 KB)

Die erstellte Software selbst, die ich Zybesi getauft habe (Zylinderbeleuchtungssimulator), beziehungsweise deren Quelltext werde ich nicht veröffentlichen. Das hängt damit zusammen, dass Zybesi massiven Gebrauch der FORWISS-Libraries macht. Diese werden für Punkt- und Vektorrechnungen in der Ebene und im Raum sowie für die Erstellung der grafischen Benutzeroberfläche benötigt. Jedoch sind diese Libraries nicht frei zugänglich. Da sie aber sowohl zum Kompilieren als auch für die Ausführung meines Programms benötigt werden, macht es wohl keinen all zu großen Sinn, Quelltext oder das Programm selbst über meinen Blog zu veröffentlichen.

Gestern stand die Abschlusspräsentation meines Programmierpraktikums an, die sehr erfolgreich verlief. In den nächsten Tagen werde ich dann auch die Ausarbeitung meines Programmierpraktikums online stellen.

Bei der Vorbereitung der Präsentation ist mir noch was aufgefallen, was auch in der Ausarbeitung keine Erwähnung mehr findet. Entwickelt hab ich mein Simulationstool hauptsächlich unter Windows, die Präsentation der Software habe ich jedoch unter Linux gemacht. Dabei ist mir aufgefallen, dass die Erstellung der Simulationsbilder unter Linux (unterer Screenshot) wesentlich weniger Zeit beansprucht als unter Windows (oberer Screenshot), was folgende beiden Screenshots illustrieren sollen.

Zwar werden die Laufzeiten auf ganze Sekunden abgerundet, aber man sieht, dass die Ausführung unter Windows (oberer Screenshot) sage und schreibe doppelt so lange dauert wie unter Linux (unterer Screenshot). In meinem Fall handelt es sich um die Distribution Ubuntu).

Dabei wurde beide Male haargenau der selbe Zylinder simuliert mit exakt den selben Form-, Lage-, Beleuchtungs- und Modellierungsparametern. Beide Male wurde die Software mit gcc kompiliert mit absolut identischen Compileroptionen. In keinem der beiden Testläufe waren zusätzliche Programme geöffnet, die Prozessor oder Speicher hätten auslasten können. Auch das Testsystem, mein Notebook, war beide Male das gleiche.

Zwar handelte es sich bei meiner Windows XP Professional Version um die 32-Bit Variante und bei Ubuntu um die mit 64-Bit Unterstützung, das dürfte aber nur einen Unterschied bei der Genauigkeit der Berechnungen, jedoch nicht bei deren Geschwindigkeit machen. Auch die Tatsache, dass nur die Windows Version das Abspeichern von PNG-Dateien unterstützt, dürfte keinen Unterschied machen, da dieses Abspeichern explizit ausgeführt werden muss und nichts mit dem eigentlichen Bildberechnungsprozess zu tun hat. Da es sich bei der CPU in meinem Notebook (einem AMD Athlon-64 3000+) um eine Singlecore CPU handelt, kann auch eine eventuell betriebssystemabhängige Schleifenparalellisierung (in der aktuellen Version ist Zybesi keine Multithreadanwendung), für die wirklich einiges Potential in meiner Software vorhanden ist, nicht schuld an den massiven Leistungsunterschieden sein. Auch habe ich darauf geachtet, dass die CPU sowohl unter Windows als auch unter Linux auf maximalem Arbeitstakt läuft und sich nicht in irgendeinem Stromspamodus befindet und sich somit automatisch herunter taktet.

Das soll jetzt natürlich nicht heißen, dass Linux das bessere (oder zumindest schnellere) Betriebssystem ist, aber eine Erwähnung in Form dieses Blogeintrags war’s mir dann doch wert.

Nachtrag (“Wer lesen kann ist klar im Vorteil” oder “Wikipedia ist (meistens) dein Freund”):
Jetzt habe ich doch noch die Lösung für den großen Geschwindigkeitsunterschied bei den Berechnungen unter den beiden Betriebssystemen gefunden. Den weitaus größten Teil der Berechnungen in meinem Simulationstool machen Skalarprodukte von Vektoren aus, also im Prinzip Additionen und Multiplikationen von Gleikommazahlen. Bei der AMD64-Architektur, die die x86-Architektur und den x86-Befehlssatz erweitert und über die meine Notebook-CPU verfügt, sind zwei Faktoren entscheidend für den Performanceboost, den ich festgestellt habe.

• Im 64-Bit Modus stellt die AMD64-Architektur 16 zusätzliche Register zur Verfügung, die bei der Ausführung von 32-Bit Anwendungen auf der selben CPU nicht zugänglich sind.
• Hauptunterschied für den Geschwindigkeitsunterschied dürfte jedoch sein, dass die AMD64-Architektur für Gleitkommaoperationen nicht auf die x86-FPU zurück greift, sondern stattdessen die entsprechende SSE-Einheit benutzt. Diese ist von Haus aus performanter als die x86-FPU. Größter Vorteil der SSE-Einheit ist die Tatsache, dass deren Register, in denen die Operanden für eine Berechnubg stehen, 128 Bit breit sind. Im Gegensatz dazu sind die Register der x86-FPU nur 80 Bit breit.
  In ein Register der SSE-Einheit passen also vier Gleitkommazahlen einfacher Genauigkeit oder zwei Gleitkommazahlen doppelter Genauigkeit. Der Clou ist nun, dass die SSE-Einheit tatsächlich pro Verarbeitungschritt jeweils zwei Gleitkommazahlen doppelter Genauigkeit aus zwei Registern nehmen kann und so in einem Schritt zwei Gleitkommaberechnungen durchführt. Dies dürfte wohl die doppelte Ausführungsgeschwindigkeit der Bildberechnung unter Linux im 64-Bit Modus erklären.

Wer das alles mal selbst durchlesen möchste, dem empfehle ich die beiden Wikipedia-Artikel zu AMD64 und SSE, aus denen ich diese Informationen habe.

Neben Google Analytics zur Analyse der Zugriffszahlen auf meinen Blog verwende ich die Google Webmaster Tools, die mir recht aussagekräftige Informationen über das Ranking meiner Homepage bei der bekannten Suchmaschine liefern.

Nachdem mein Blog nun seit ziemlich genau 1 ½ Jahren online ist, bin ich mit meinem Google-Ranking eigentlich recht zufrieden. Natürlich steht der mit der schnöden Eingabe von Christoph Riesinger ganz oben, aber auch mein Nachname allein reicht für ein Top10-Ranking.

Glücklicherweise findet man meinen Blog nicht nur über meinen Namen. So sind meine beiden Artikel zur Karlsruher Nuklidkarte recht weit oben gelistet, genau so wie mein Beitrag zur WPA-Verschlüsselung unter Windows 2000. Ganz besonders stolz bin ich auf die hohe Bewertung meines HDR-Tutorials, in das ich viel Zeit und Mühe investiert habe. Ebenso bin ich ganz happy, dass ich mit einem meiner beiden Hauptseminare ganz oben stehe.

Ein paar Ergebnisse zum Schmunzeln gibt’s natürlich auch. Mein im alltäglichen Sprachgebrauch nicht gerade häufig vorkommendes Osmanien wird doch tatsächlich gesucht und findet sich auch promt unter den Top10 Google-Treffern.

Wie ich so bei den anderen Großen Suchmaschinen abgeschnitten habe, hab ich nicht so genau in Erahrung gebracht. Allerdings stehe ich bei Yahoo, Ask.com und Lycos mit meinem Namen jeweils an erster Stelle. Beruhigend ist auch, dass ich bei keiner Web- oder Bildersuche Peinlichkeiten von mir gefunden habe. Zumindest keine, die ich nicht selbst online gestellt habe *g*.

Natürlich beziehen sich die Googlelinks nur auf den Stand, als ich diesen Blogeintrag geschrieben habe. Die Ergebnisse können von Zeit zu Zeit natürlich ganz schön variieren.

Nachtrag (am 26.04.2008):
Hehe. Weil ich gerade den Blogeintrag zum siebten Nagus all in! geschrieben habe, habe ich mir gedacht, dass ich mal nach unserem kleinen Pokerturnier googel um zu sehen, welcher Blog weiter oben gelistet ist, der vom Gastgeber oder meiner. Tja, was soll ich sagen, ich hab “gewonnen“.

Vergangenen Dienstag war es soweit. Ein Ereignis von historischem Ausmaße stand an. Ich habe mit der Lernerei für meine Diplomprüfungen in den Sommersemesterferien begonnen.

Während sich andere für ein derartiges Mammutprojekt gerade einmal 100 Tage Zeit lassen, stehen mir auch nicht wirklich komfortable 138 Erdrotationen dafür zur Verfügung.

Da ich in meiner Lernzeit den ein oder anderen Blogeintrag zum Thema Lernen erstellen werde, habe ich mir zu diesem Zweck die beiden Banner oben und unten von diesem Eintrag einfallen lassen. Sie sollen immer den aktuellen Stand meiner Synapsenbildung repräsentieren. Die Dinger gibt’s noch in gelb und in rot, je nachdem wie kritisch die aktuelle Lernphase ist. Momentan ist ja noch nicht viel passiert, also sind sie noch brav grün.

So, das ist jetzt der Blogeintrag, den ich mir in ein paar Jahren mal ansehen kann und dann meinen Kindern erzähle, dass am 15. April 2008 das große Lernen begonnen hat.

Am letzten Sonntag hab ich’s endlich hinter mich gebracht: Mein Programmierpraktikum. Aus diesem Anlass möchte ich gleich zwei Blogeinträge online stellen. Den Ersten gibt’s heute. Teil zwei erscheint dann aller Voraussicht nach die nächsten Tage und wird die Ausarbeitung zu meinem Programmierpraktikum enthalten.

Heute gibt’s aber erstmal ein bisschen zum “Schmunzeln”. Neben zahlreichen Bugs in meiner Software gab’s auch welche, die sich schön mit Bilder dokumentieren lassen. Schließlich handelt es sich um ein Tool, das die Beleuchtung von Zylindern simuliert und folglich auch Bilder produziert. Da kann so ein Programmierfehler oder eine falsch gesetzte Variable zu Bildern führen, die so nicht ganz dem realitätsnahen Anspruch meiner Software mithalten können. Also los geht’s…

Das kommt davon, wenn man die Werte seiner Bildpunkte nicht im Blick hat. Dieses Bild ist aufgrund zahlreicher double-Überläufe entstanden. Noch dazu liegt die Lichtquelle der Szene genau hinter dem Zylinder, was eigentlich zu gar keiner Beleuchtung in dem Bereich führen dürfte, der von der Kamera eingesehen werden kann.

Nanu, was ist denn hier passiert: Die unteren 2/3 sehen ja noch ganz OK aus, aber ab dem Fluchtpunkt sollte da doch nichts mehr sein. Stimmt, das kommt davon, wenn man die Sichtstrahlen des Raytracings zu stiefmütterlich behandelt. Die schneiden den Zylinder natürlich nicht nur vor, sondern auch hinter der Kamera, dort, wo sie eigentlich nichts sehen dürften. Schließlich hat eine Kamera keine Augen auf dem Rücken.

Arrays hin und her zu kopieren ist eigentlich die Todsünde eines jeden Programmierers. Ab und zu lässt sich das aber nicht ganz vermeiden und wenn man nicht aufpasst, kommen solche tollen Streifen dabei raus.

Und das passiert wenn man meint, dass sein Simulationsbild einen Pixel breiter und höher ist, als es tatsächlich zutrifft. Dann verschiebt sich beim Zeichnen der mühsam berechneten Pixel jede Zeile und jede Spalte ein wenig und über das ganze Bild betrachtet, sieht das dann so aus.

Heute möchte ich meiner Leserschaft eine weitere Serie empfehlen. Gestolpert bin ich über sie beim Durchstöbern von diversen Kritiken, die allesamt gut bis exzellent ausgefallen sind. Und da die Serie schon nach 13 Folgen aufgrund mangelnden Zuschauerinteresses abgesetzt wurde, war mir klar, dass sie mal einen Blick wert ist. Schließlich ist dieses Argument im Zeitalter von Reality-, Casting- und Dokushows eher ein Qualitäts- als abwertendes Kriterium, verspricht es doch mal ‘ne Serie mit etwas mehr Tiefgang. Von welchem TV-Event ich spreche? Von “Bis in die Spitzen”.

Die Grundhandlung ist schnell erzählt: Der Weiberheld Finn kehrt nach Berlin zurück um sich seine Flamme und einzig wahre Liebe aus Jugendzeiten unter den Nagel zu reißen. Die ist mittlerweile erfolgreiche Unternehmerin und glücklich verheiratet, verfällt aber trotzdem Finns Charme. Die Story an sich ist jetzt vielleicht nicht die neueste und innovativste, aber die Umsetzung und vor allem die schauspielerische Leistung ist überragend, von der bedrückenden Atmosphäre gar nicht zu sprechen.

Zahlreiche Nebencharaktere sorgen für tolle Sidestories abseits vom Hauptplot. Das bietet viel Potential für abwechslungsreiche Unterhaltung. Weiterer Pluspunkt der Serie ist, dass immer was weitergeht. Da wird nicht die halbe Staffel gewartet, bis mal ein schmutziges Geheimnis an die Oberfläche kommt. Außerdem verhalten sich alle Rollen sehr authentisch, abseits von übertriebenen Gefühlsgedusel oder Verhalten à la “Zwei bei Kallwass”.

Dass die Serie in Deutschland gefloppt ist, kann ich mir gut denken, denn man muss viel “zwischen den Zeilen lesen” und viele interessante Aspekte werden nur angedeutet, oft aber nicht explizit erwähnt. Das macht die Serie äußerst vielschichtig und führt dazu, dass in wenigen Episoden sehr viele äußerst komplexe Personen eingeführt werden.

Mit ihren 13 Episoden fällt die Serie recht kurz aus, weshalb sich jeder Serienjunkie ruhig mal ein Bild von ihr machen sollte. Bereuen dürften’s wohl die wenigsten. Zwar basiert “Bis in die Spitzen” auf einer BBC-Serien, nichts desto trotz mal eine äußerst erfreulichen deutsche Fernsehproduktion.

Dass das studieren des Boulevardfernsehprogramms doch ab und zu das ein oder andere Schmankerl zu Tage fördert, hatte ich ja schon mal geschrieben. Und wieder bin ich im Fernsehen über was Technisches gestolpert, bei dem’s meiner Meinung nach wert ist, dass ich drüber blogge.

Am vergangenen Dienstag kam bei taffNet in der Nachmittagssendung taff auf ProSieben ein kleiner Bericht über einen von Boston Dynamics entwickelten Roboterhund, der mich ganz schön beeindruckt hat.

Wie man auf der entsprechenden Seite im Internet von Boston Dynamics nachlesen kann, ist der “BigDog” in der Lage, etwa 150kg Nutzlast durch unwegiges Gebiet wie Wälder, Bauschutt, Schotterpisten oder Schnee zu transportieren, ohne dass er dabei stecken bleibt oder umfällt. Auch ein Hindernisparcours ist kein Problem, ebenso wenig wie der aktive Versuch, den Roboterhund umzuschmeißen.

Was für Ottonormalbürger jetzt nicht sonderlich spektakulär aussieht ist für Leute vom Fach fast schon eine mittelgroße Revolution, waren Roboter auf zwei oder vier Beinen in der Vergangenheit zu nicht viel mehr fähig als aufrechtem gehen oder vielleicht noch Treppen steigen. Sprinten oder im Kreis laufen gehörte da schon zum höchsten der Gefühle.

Wer sich selbst ein Bild davon machen will, kann dies auf der entsprechenden Produktseite machen. Das Promovideo ist dabei meiner Meinung nach absolut sehenswert.

Nachdem ich die letzten beiden Tage damit beschäftigt war, den Quelltext meines Programmierpraktikums zu kommentieren, habe ich heute mit dem Tippen der Ausarbeitung begonnen. Wie es sich für einen anständig wissenschaftlich arbeitenden Informatiker gehört, verwende ich dafür LaTeX.

Dabei bin ich auf ein kleines Problem gestoßen bei dem es mich wundert, dass ich es nicht schon viel früher gelöst habe. Schließlich handelt es sich bei der schriftlichen Ausarbeitung meines Programmierpraktikums bei weitem nicht um mein erstes größeres LaTeX-Projekt. Es geht darum, Vektorgrafiken in Form von EPS-Dateien (Encapsulated PostScript) mit dem Befehl \includegraphics{} in ein PDF-Dokument einzubinden.

Der Vorteil von Vektorgrafiken liegt auf der Hand: Sie lassen sich ohne Qualitätsverlust oder Entstehen von Artefakten skalieren, also vergrößern oder verkleinern. Natürlich eignen sich Vektorgrafiken nicht für jede Art von Bild (klassisches Gegenbeispiel ist das Foto). Aber jede Form von Diagrammen oder Schemata, wie sie ausschließlich in meiner Programmierpraktikumsausarbeitung vorkommen, speichert man am besten als Vektorgrafik.

So lange man sein LaTeX-Dokument nach DVI oder PS exportiert, ist die Verwendung von EPS-Dateien, die Bilder als Vektorgrafiken speichern, kein Problem. Exportiert man sein LaTeX-Dokument jedoch nach PDF, ist man mit folgendem Problem konfrontiert: Der Export erfolgt in der Regel mittels des Befehls pdflatex und dieser akzeptiert nur PNG, BMP oder TIFF-Dateien als Bilddateien. Da keine dieser Bilddateien ein Vektorgrafikformat ist, muss man sich was einfallen lassen.

Abhilfe schafft hierbei das Package \usepackage{epstopdf}: Es wandelt beim Übersetzungsvorgang alle im LaTeX-Dokument eingebundenen EPS-Dateien implizit in PDF-Dateien um, die dann als Bilder inkludiert werden können. Diese PDF-Dateien sind dann auch Vektorgrafiken, die in den PDF-Export übernommen werden. Man muss lediglich \usepackage{epstopdf} am Anfang seines LaTeX-Dokuments angeben. Die EPS-Dateien lassen sich dann wie gewohnt an gewünschter Stelle mit \includegraphics{dateiname.eps} einbinden.

Eine Kleinigkeit muss man jedoch beachten: Bei epstopdf handelt es sich um ein externes Programm. Dies muss pdflatex beim Übersetzungsvorgang mitgeteilt werden, ansonsten erhält man eine Fehlermeldung der Form Shell escape feature is not enabled. MiKTeX verwendet hierfür den Parameter --enable-write18, teTeX und TeX Live den Parameter --shell-escape.

Wer TeXnicCenter als LaTeX-Editor verwendet, dem sei an dieser Stelle schnell erklärt, wie er das Argument --enable-write18 automatisch übernimmt. Über “Ausgabe” → “Ausgabeprofil definieren” kann man unter “Argumente, die an den Compiler übergeben werden sollen” das Argument --enable-write18 (für MiKTeX) angeben. In der Regel steht dort bereits -interaction=nonstopmode "%pm". Dem stellt man das neue Argument getrennt durch ein Leerzeichen einfach voran.

Noch ein kleiner Hinweis am Rande: Wer will, dass seine Grafik automatisch auf die Breite des Textes skaliert wird, kann dies mit der Option width=\textwidth machen. Das Einfügen eines Bildes würde dann beispielsweise so aussehen: \includegraphics[width=\textwidth]{dateiname.eps}. Auch Skalierungen wie \includegraphics[width=0.4\textwidth]{dateiname.eps} oder \includegraphics[width=.7\textwidth-2cm]{dateiname.eps} sind möglich.