Woche #44

(Zeitraum: 20.8.2012 – 24.8.2012)

Mein Code läuft gut. Das Bottleneck ist allerdings die Anzeige.
Nachdem jeder Wert konform abgebildet wurde und die Hough-Transformierten errechnet wurden, möchte ich mir den ganzen Kram auch angucken. Dazu lasse ich jeden Wert in ein ROOT-TH2D-Histogramm einfüllen. Eine lineare (nicht-parallele) Operation, die bei der Feinheit des Grids (also der Auflösung) ganz schön langsam wird. Beispiel? Meine X-Achse läuft von 0° bis 360°. Ich möchte dort mit einer Auflösung von 0,01° arbeiten. Heißt: Auf dieser Achse 36.000 Bins. Zu jedem Winkelwert wird pro Punkt ein passender Y-Hough-Transform-Wert berechnet. Die Formel ist also: 360°/Auflösung * Anzahl_der_untersuchten_Hits. Bei den sechs Beispielpunkten, mit denen ich arbeite, sind das also 6*36000 = 216000 Einträge. Irgendwas hab ich jetzt vergessen, denn mein angezeigtes Histogramm sagt, es habe 77.000.000 Einträge.
Jedenfalls: 216.000 lineare Operationen dauern (77 Millionen umso mehr).
Und das kann ich vielleicht parallelisieren?

Das interessante: ROOTs TH2D hat einen Konstruktor mit einer Matrix als Argument. Die Idee: Ich möchte eine Matrix GPU-seitig füllen und dann ROOT zum konstruieren rüberschieben.

Allerdings sind Matritzen ganz schön fiese Gebilde, im Computer, so. Deren zweidimensionalität braucht schnell viel Speicher. Außerdem gibt’s keinen naiven Datentyp dafür. Ich mache mir an der Tafel Gedanken, ob man das zweidimensionale Problem eindimensionalisieren kann (kann man), ob das schön (nein) und praktikabel (vielleicht – ich hab aufgegeben) ist. 

Ich könnte mich in die Untiefen des Plain-CUDA einarbeiten – da gibt’s von NVIDIA ein CuBLAS, ein Linear-Algebra-System für CUDA. Aber das ist Plain-CUDA und das will ich eigentlich vermeiden.

Ich finde einen Template-orientierten CUDA-Wrapper, so wie Thrust auch einer ist, extra für Matrizen (genauer: dünnbesetzte, »Sparse«-Matrizen), namens Cusp. Der macht zumindest mal das Anlegen von Matrizen etwas leichter. Aber das immanente Histogrammproblem löst das noch nicht. Denn Matrizen füllen, als wären sie Histogramme (also: alter Wert des Bins + 1, falls aktuelle Koordinate ein zweites Mal vorkommt) ist eigentlich keine gute Sache um überhaupt parallelisierbar zu sein.

Wie ich durch die Beispiele browse, finde ich allerdings etwas, das tatsächlich irgendwie auf meinen Fall passen könnte. Es werden trickreich Sortierfunktionen von Thrust mit Matrixfüllmethoden von Cusp verwurschtelt. Und das lässt sich mit etwas Arbeit auf meinen Fall rumwurschteln.
Das mache ich also den Rest der Woche. Rumwurschteln, verbessern, erweitern.