GPU-Implementation von “Neural Gas Principal Component Analysis”

Universität Bielefeld 

Technische Fakultät 

AG Technische Informatik 

Bachelorarbeit 

GPU-Implementation von “Neural Gas 

Principal Component Analysis” mit 

blockweisem Ansatz 

Christian Menßen 

26. September 2012 

im Studiengang 

Kognitive Informatik 

Betreuer 

Dr.-Ing. Wolfram Schenck

Diese Bachelorarbeit wurde von Dr.-Ing. Wolfram Schenck betreut und begutachtet. 

Der zweite Gutachter war Dipl.-Inform. Alexander Kaiser. 

Ich danke meinem Betreuer Dr.-Ing. Wolfram Schenck für das interessante Thema und 

die Unterstützung während der Bearbeitung. 

2 Universität Bielefeld, AG Technische Informatik

Kurzbeschreibung 

Die Verwendung der Grafikkarte als universelle Berechnungseinheit hat in den letzten 

Jahren stark zugenommen. Viele rechenintensive Anwendungen wie z.B. physikalische 

Simulationen, Bild- und Videoverarbeitung oder die automatische Spracherkennung 

können durch den Einsatz von Grafikkarten signifikant beschleunigt werden. In dieser 

Bachelorarbeit wird gezeigt, wie ein künstliches neuronales Netzwerk (genauer: ein 

Neural-Gas-Netzwerk mit lokaler Hauptkomponentenanalyse) mit Hilfe der Programmierschnittstelle 

OpenCL auf einem Grafikprozessor trainiert werden kann, wodurch 

eine deutliche Geschwindigkeitssteigerung erreicht wird. 

Universität Bielefeld, AG Technische Informatik 3

Inhaltsverzeichnis 


1 Einleitung 6 

2 Theoretische Grundlagen 7 

2.1 GPU Computing . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

2.1.1 Erreichbarer Speedup . . . . . . . . . . . . . . . . . . . . 7 

2.1.2 Programmierschnittstellen . . . . . . . . . . . . . . . . . . 8 

2.1.3 Speichermodell . . . . . . . . . . . . . . . . . . . . . . . . 8 

2.2 Hauptkomponentenanalyse . . . . . . . . . . . . . . . . . . . . . 8 

2.3 Vektorquantisierung . . . . . . . . . . . . . . . . . . . . . . . . . 9 

2.4 Neural Gas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 

2.5 Erweiterung zu NGPCA . . . . . . . . . . . . . . . . . . . . . . . 10 

2.5.1 Lokale PCA . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

2.5.2 Distanzmaß . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

2.5.3 Training . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

2.6 Orthonormalisierung . . . . . . . . . . . . . . . . . . . . . . . . . 12 

3 Implementation 13 

3.1 Initialisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

3.2 Distanzberechnung . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

3.2.1 Verwendetes Potential . . . . . . . . . . . . . . . . . . . . 16 

3.3 Ranking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 

3.3.1 Sortierverfahren . . . . . . . . . . . . . . . . . . . . . . . 16 

3.4 Adaptierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 

3.4.1 Hauptkomponentenanalyse . . . . . . . . . . . . . . . . . 17 

3.4.2 Orthonormalisierung . . . . . . . . . . . . . . . . . . . . . 17 

3.5 Harte Vektorquantisierung . . . . . . . . . . . . . . . . . . . . . . 18 

3.5.1 Adaptive Anpassung der parallelen Trainingsvektoren . . 19 

4 Experimentelle Ergebnisse 20 

4.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 

4.2 Roboterarmsteuerung . . . . . . . . . . . . . . . . . . . . . . . . 21 

4.3 CT Slices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 

4.4 Speedup nach gewählten Parametern . . . . . . . . . . . . . . . 23 

4.4.1 Anzahl der Prototypen . . . . . . . . . . . . . . . . . . . . 23 

4.4.2 Anzahl der Eigenwerte . . . . . . . . . . . . . . . . . . . . 24 

4.4.3 Verwendetes Potential . . . . . . . . . . . . . . . . . . . . 25 

4.5 Kernellaufzeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 



5 Diskussion 27 

5.1 Pre-Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 

5.1.1 PCA-Verfahren . . . . . . . . . . . . . . . . . . . . . . . . 27 

5.1.2 Orthonormalisierungsverfahren . . . . . . . . . . . . . . . 27 

5.1.3 Implementation einer OpenCL Matrix-Bibliothek . . . . . . 28 

5.2 Beurteilung der Ergebnisse . . . . . . . . . . . . . . . . . . . . . 28 

5.2.1 Einfluss der gewählten Parameter . . . . . . . . . . . . . 29 

5.2.2 Wahl der Plattform . . . . . . . . . . . . . . . . . . . . . . 31 

6 Ausblick 32 

6.1 EFORRLSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 

6.2 AVX, Nvidia Tesla, AMD Plattform . . . . . . . . . . . . . . . . . 32 

6.3 Orthonormalisierung . . . . . . . . . . . . . . . . . . . . . . . . . 33 

6.4 Adaptive Anpassung der parallelen Trainingsvektoren . . . . . . 33 

Literaturverzeichnis 34 

A Verwendete Parameter 36 

A.1 Roboterarmsteuerung . . . . . . . . . . . . . . . . . . . . . . . . 36 

A.2 CT Slices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 

B Quelltexte 37 

C Kompilierung und Ausführung der Quelltexte 43 

D Verwendete Software-Bibliotheken 44 

E Kommandozeilenparameter 45 


1 

Einleitung 

In den letzten Jahren hat GPU Computing, also die Verwendung der Grafikkarte 

als universelle Berechnungseinheit, immer mehr an Bedeutung gewonnen. Moderne 

Grafikkarten besitzen mittlerweile ein Vielfaches der Rechenleistung aktueller Prozessoren 

1 , so dass sie auch für wissenschaftliche Anwendungen interessant werden. 

Zudem steht mit OpenCL eine Programmierschnittstelle zur Verfügung, mit der die 

Implementierung abstrakt zur eigentlichen Hardwareplattform stattfinden kann. 

Im Rahmen dieser Bachelorarbeit wurde eine GPU-Implementierung für ein Neural- 

Gas-Netzwerk mit lokaler Principal Component Analysis (Möller und Hoffmann, 

2004) erstellt. Aufgrund der Unterteilung in lokale PCAs verspricht die Umsetzung 

auf der Grafikkarte einen erheblichen Geschwindigkeitszuwachs, da die bei diesem 

Verfahren verwendeten Prototypen parallel berechnet werden können. 

Kapitel 2 beginnt mit einer näheren Betrachtung des GPU Computing und führt 

anschließend das zugrunde liegende Verfahren Neural Gas mit lokaler Principal 

Component Analysis 2 mit den nötigen Grundlagen ein. 

In Kapitel 3 wird die grundlegende Struktur der Applikation erläutert, woraufhin auf die 

einzelnen Schritte des Lernverfahrens mit den nötigen GPU-spezifischen Anpassungen 

eingegangen wird. 

Die resultierende Geschwindigkeit der Implementation wird in Kapitel 4 anhand von 

zwei ausgewählten Datensätzen evaluiert. Dabei wird der Speedup betrachtet, also das 

Verhältnis von CPU-Laufzeit zu GPU-Laufzeit. 

Abschließend werden in Kapitel 5 die vor dieser Bachelorarbeit durchgeführten Tests 

erläutert und die aus Kapitel 4 resultierenden Ergebnisse diskutiert. Einen Ausblick auf 

mögliche Erweiterungen und Verbesserungen gibt Kapitel 6. 

1 http://developer.download.nvidia.com/compute/DevZone/docs/html/C/ 

doc/CUDA_C_Programming_Guide.pdf 

Datum: 03.09.2012 

2 Im Folgenden “NGPCA” genannt 


2 

Theoretische Grundlagen 

2.1 GPU Computing 

Mit GPU Computing (auch GPGPU 1 genannt) bezeichnet man die Verwendung der 

GPU für Berechnungen, die normalerweise auf der CPU ausgeführt werden. 

Im Laufe der letzten Jahre hat sich die Leistungsfähigkeit von Grafikkarten rasant 

entwickelt. Während moderne Prozessoren weniger als 500 GFLOPs 2 verarbeiten 

können, schaffen aktuelle Grafikkarten bereits über 3.000 GFLOPs 3 . Sie sind also 

theoretisch sehr gut zum wissenschaftlichen Rechnen geeignet. Leider lässt sich 

bestehende Software nicht 1:1 auf die GPU übertragen, was an der zugrunde liegenden 

Hardware-Architektur liegt: 

Während CPUs zum schnellen Abarbeiten von sequenziellen Befehlen ausgelegt sind, 

erreichen GPUs ihre Leistung durch starke Parallelisierung. 

2.1.1 Erreichbarer Speedup 

Sei P ∈ [0, 1] der parallelisierbare Anteil des Algorithmus, (1 − P ) der serielle Anteil 

und N ∈ N ∗ die Anzahl an parallelen Recheneinheiten. Dann wird der theoretische 

maximale Speedup S, also die erreichbare Beschleunigung, durch Amdahls Gesetz 

(Amdahl, 1988) beschrieben: 

S(N) = 

1 

(1 − P ) + P N 

Der Speedup wird dabei nach oben beschränkt durch: 

lim S(N) = 1 

N→∞ (1 − P ) 

1 GPGPU = General Purpose Computation on Graphics Processing Unit 

2 GFLOPs = 10 9 Gleitkommaoperationen pro Sekunde 

3 http://developer.download.nvidia.com/compute/DevZone/docs/html/C/ 

doc/CUDA_C_Programming_Guide.pdf 

Datum: 03.09.2012 

(2.1) 

(2.2) 


2 Theoretische Grundlagen 

Somit ist eine hohe Parallelisierbarkeit essenziell für eine schnelle Implementierung 

auf der Grafikkarte. 

2.1.2 Programmierschnittstellen 

Für die Programmierung von GPUs stehen einige Programmierschnittstellen zur 

Verfügung, von denen sich jedoch das proprietäre Nvidia CUDA C und der offene Standard 

OpenCL durchgesetzt haben. Der große Vorteil von OpenCL ist, dass die Implementierung 

abstrakt zur eigentlichen Hardwareplattform stattfindet, weshalb es auch für 

diese Bachelorarbeit verwendet wurde. Dem entgegen steht die etwas umständlichere 

Programmierung und die geringere Verbreitung im Gegensatz zu CUDA C. 

OpenCL 

OpenCL kann ein oder mehrere OpenCL-Geräte ansprechen, wobei diese von verschiedenen 

Treibern, den sog. Plattformen, gesteuert werden. Geschriebener Quellcode muss 

dabei für jede Plattform separat kompiliert werden, was jedoch zur Laufzeit geschieht. 

Funktionsaufrufe auf der GPU werden Kernel genannt. Kernel führen den selben Programmcode 

parallel auf mehreren sog. Work-Items aus, die ein-, zwei- oder dreidimensional 

angeordnet sein können. Work-Items werden zu Work-Groups zusammengefasst, 

in denen gemeinsamer lokaler Speicher (schnell, siehe Kapitel 2.1.3) und Synchronisationsmechanismen 

zur Verfügung stehen (Munshi, 2012). 

2.1.3 Speichermodell 

Während auf dem Host nur eine Art von Hauptspeicher vorhanden ist, besitzen Grafikkarten 

verschiedene Arten von Speicher mit unterschiedlichen Eigenschaften (Munshi, 

2012; Sanders und Kandrot, 2010): 

• Globaler Speicher 

Größter verfügbarer Speicherbereich (ca. 512 MB - 2 GB), langsamer Zugriff. 

• Konstanter Speicher 

Spezieller nur lesbarer Speicher, optimiert für schnellen parallelen Zugriff. 

• Lokaler Speicher 

Sehr schneller Speicherbereich, den sich die Work-Items einer Work-Group teilen. 

Typischerweise 16 KB groß. 

• Privater Speicher 

Innerhalb eines Work-Items genutzter Speicher. Wird z.B. für lokale Variablen 

verwendet. 

2.2 Hauptkomponentenanalyse 

Principal Component Analysis (PCA) (Jolliffe, 1986) ist ein lineares Dimensionsreduktionsverfahren. 

Dabei wird die Menge der Eingabevektoren X = { ⃗x 1 , ..., x⃗ 

N } ⊂ R n auf 

Vektoren niedriger Dimensionalität Y = {⃗y 1 , ..., y⃗ 

N } ⊂ R m mit m ≤ n abgebildet. Um 



den Informationsverlust zu minimieren werden genau die Achsen weggelassen, die die 

geringste Varianz aufweisen. Dies sind die Eigenvektoren zu den kleinsten Eigenwerten 

der Kovarianzmatrix 

C = 1 N∑ 

(⃗x n − ⃗µ)(⃗x n − ⃗µ) T (2.3) 

N 

mit ⃗µ = 1 N 

∑ N 

n=1 ⃗x n. 

n=1 

2.3 Vektorquantisierung 

Vektorquantisierung ist ein Verfahren zur Datenkompression bzw. zum Datenclustering. 

Hierbei werden die Eingabedaten durch k Merkmalsvektoren ausgedrückt. Die Menge 

der Prototypen C = {⃗c 1 , . . . , ⃗c k } wird auch als Codebuch bezeichnet. Grundsätzlich 

unterscheidet man 2 Arten von Vektorquantisierung: 

• Harte Vektorquantisierung 

Jedem Eingabevektor wird genau ein Merkmalsvektor zugewiesen: 

q : ⃗x ↦→ ⃗c i , i ∈ {1 . . . k} (2.4) 

• Weiche Vektorquantisierung 

Die Wahrscheinlichkeit p(⃗x|⃗c i ), i ∈ {1 . . . k}, dass der Eingabevektor von dem i- 

ten Merkmalsvektor erzeugt wurde, wird modelliert. Die Wahrscheinlichkeitsverteilung 

lässt sich nun als Summe der Zuordnungswahrscheinlichkeiten definieren: 

k∑ 

p(⃗x) = π i p(⃗x|⃗c i ) (2.5) 

i=1 

Wobei die Mischkoeffizienten π i > 0 mit 

Wahrscheinlichkeiten angeben. 

2.4 Neural Gas 

∑ k 

i=1 π i = 1 die A-priori- 

Der Neural-Gas-Algorithmus (NG) (Martinetz et al., 1993) kann als Generalisierung 

der Online-Variante des k-Means-Algorithmus verstanden werden. Im Unterschied 

zu k-Means ist Neural Gas jedoch ein weiches Vektorquantisierungsverfahren, da in 

jedem Lernschritt alle Merkmalsvektoren in Abhängigkeit von der Entfernung zum 

Datenpunkt angepasst werden. Hierdurch wird eine robuste und von der Initialisierung 

der Prototypen größtenteils unabhängige Konvergenz erreicht. 

Zunächst werden alle k Merkmalsvektoren mit zufällig ausgewählten Eingabevektoren 

initialisiert. Anschließend wird in jedem Lernschritt ein Eingabevektor ⃗x zufällig aus 

den Eingabedaten gezogen und der Rang 

r(⃗c i , ⃗x) = |{⃗c j | ‖⃗c j − ⃗x‖ < ‖⃗c i − ⃗x‖}| (2.6) 

jedes Prototypen ermittelt. Der Rang eines Prototypen ist also die Position des Merkmalsvektors 

in einer aufsteigend nach Distanz zum Eingabevektor sortierten Liste. Dieser 

geht direkt als Gewichtung in die Lernregel 

∆⃗c i = ɛ · h p (r(⃗c i , ⃗x)) · (⃗x − ⃗c i ) (2.7) 



ein, wobei ɛ ∈ [0, 1] die Lernrate und h p (r) = e −r/p der Nachbarschaftsfaktor mit 

Nachbarschaftsreichweite p ist. Sowohl die Lernrate als auch der Nachbarschaftsfaktor 

fallen exponentiell während des Trainingsprozesses ab: 

ɛ(t) = ɛ init · 

( 

ɛfinal 

ɛ init 

) t/tmax 

(2.8) 

p(t) = p init · 

( 

pfinal 

p init 

) t/tmax 

(2.9) 

Durch das Abfallen der Trainingsparameter kann neben der “globalen Ordnung” auch 

gegen Ende des Lernprozesses die “lokale Ordnung” durch nur noch kleine lokale Änderungen 

der Merkmalsvektoren optimiert werden. 

2.5 Erweiterung zu NGPCA 

Das in dieser Bachelorarbeit auf der GPU implementierte Verfahren NGPCA (Möller 

und Hoffmann, 2004) basiert auf Neural Gas, erweitert es jedoch um lokale PCAs und 

benutzt dazu passende Distanzmaße. 

2.5.1 Lokale PCA 

Lokale PCA-Verfahren beruhen darauf, mit Hilfe eines Vektorquantisierers den Eingaberaum 

zu partitionieren und anschließend jede Partition durch eine PCA zu approximieren. 

Bei hinreichender Anzahl an Partitionen lassen sich so beliebig komplexe Mannigfaltigkeiten 

gut approximieren. NGPCA ist ein solches Verfahren, welches Neural 

Gas als Vektorquantisierer benutzt. Jede lokale PCA wird dabei zu einem Tupel, der 

sog. Unit U i = (⃗c i , W i , Λ i , σi 2 ) zusammengefasst. Dabei ist ⃗c i der Merkmalsvektor, W i 

eine Matrix mit den m größten Hauptachsen der PCA, Λ i eine Diagonalmatrix mit den 

entsprechenden Varianzen der Hauptachsen und σi 2 = ∑ n 

j=m+1 λ j die Residualvarianz, 

also die summierte Varianz der (n−m) Dimensionen, die nicht durch W i erfasst werden. 

Somit ergibt sich als neues Codebuch U = {U i , . . . , U k } 

Robust Recursive Least Squares Learning Algorithm (RRLSA) 

Robust Recursive Least Squares Learning Algorithm (RRLSA) (Ouyang et al., 2000) 

ist ein Verfahren zur Hauptkomponentenanalyse und kommt bei dieser Bachelorarbeit 

zum Einsatz. 

Grundlage für das Verfahren ist die Hebbsche Lernregel, 

∆⃗w = ɛ · y · ⃗x − λ⃗w (2.10) 

mit der die erste Hauptkomponente der Daten iterativ mit einem Perzeptron bestimmt 

werden kann. ɛ ist dabei die Lernrate, ⃗w der Gewichtsvektor, y = ⃗w T ⃗x die Ausgabe des 

Perzeptrons und λ⃗w ein Abklingterm, der durch λ parametrisiert wird. Dies spart die 

aufwändige Berechnung der Kovarianzmatrix. 

Um nun auch die weiteren Hauptachsen bestimmen zu können, werden Perzeptren sequenziell 

verknüpft. 



Dem zweiten Perzeptron wird der Eingabevektor abzüglich der Projektion auf den ersten 

Gewichtsvektors als Eingabe präsentiert: 

⃗ξ i = 

{ ⃗x i = 1 

⃗ξ i−1 − y i−1 ⃗w i−1 i > 1 

(2.11) 

Führt man dieses als Deflation (Sanger, 1989) bezeichnete Verfahren fort, erhält man 

sequenziell verschaltete Neuronen, die zu den Eigenvektoren der Kovarianzmatrix konvergieren. 

Dieses Verfahren wird Generalized Hebbian Algorithm (Sanger, 1989) genannt. 

RRLSA baut auf der Deflation auf, verwendet jedoch unnormalisierte Gewichtsvektoren. 

Diese lassen sich rekursiv durch 

∆ ˜w i = ɛ( ⃗ ξ i y i − ˜w i ) (2.12) 

berechnen. Den Eigenwert erhält man aus der Länge des Gewichtsvektors, den Eigenvektor 

durch Normalisierung: 

λ i = ‖ ˜w i ‖, ⃗w i = 

˜w i 

‖ ˜w i ‖ 

(2.13) 

Da die resultierenden Eigenvektoren nicht zwingend paarweise orthogonal zueinander 

sind, ist eine regelmäßige Orthonormalisierung notwendig (siehe Kapitel 2.6). 

2.5.2 Distanzmaß 

Neural Gas bestimmt den Rang eines Merkmalsvektors mit Hilfe des euklidischen Abstandes. 

Dadurch wird die Struktur der PCA-Unterräume jedoch nicht beachtet, weshalb 

es sinnvoll ist, die verwendete Metrik anzupassen. NGPCA beschreibt die normalisierte 

Mahalanobis-Distanz und ein volumenunabhängiges Abstandsmaß. In dieser Bachelorarbeit 

wurde das volumenunabhängige Abstandsmaß verwendet, da die normalisierte 

Mahalanobis-Distanz bei stark gestreuten Datenpunkten problematisch ist (Hoffmann, 

2004). 

Volumenunabhängiges Abstandsmaß 

Grundlage für das volumenabhängige Abstandsmaß ist die normalisierte Mahalanobis- 

Distanz. Diese basiert auf multivariaten Normalverteilungen, dessen Zentren die 

Merkmalsvektoren bilden. Als Achsen für den Hyperellipsoiden werden die Hauptachsen 

der PCA verwendet, skaliert mit der Standardabweichung der entsprechenden 

Richtungen. Da im Falle einer Dimensionsreduktion (m < n) nicht mehr alle Punkte 

korrekt zugeordnet werden können (Möller und Hoffmann, 2004), wird das Modell um 

den Rekonstruktionsfehler (Kambhatla und Leen, 1997) erweitert. 

Durch Normalisieren der Eigenwerte abhängig vom Volumen des Ellipsoiden (Hoffmann, 

2004) erhält man 

( 

d i (⃗x) = ⃗y i T Λ −1 

i ⃗y i + 1 ) 

( ξ 

λ ⃗T ⃗ ∗ i ξ i − ⃗y i T ⃗y i ) V 2/n 

i (2.14) 

i 

mit ⃗ ξ i = ⃗x − ⃗c i , ⃗y i = W T 

i ⃗ ξ i , λ ∗ i = 

σ2 i 

und V = √ |Λ|. 

n−m 



2.5.3 Training 

Das Training eines NGPCA-Netzwerkes verläuft analog zu Neural Gas. Zuerst werden 

die Mittelpunkte ⃗c i der Units zufällig mit Vektoren aus der Trainingsmenge initialisiert. 

Die Wahl der Eigenwerte ist beliebig, alle Units sollten jedoch mit den selben Eigenwerten 

initialisiert werden. W i kann ebenfalls frei gewählt werden, hier ist allerdings 

auf Orthonormalität zu achten. 

Während des Lernprozesses werden zufällig Trainingsvektoren ⃗x aus der Trainingsmenge 

gewählt und der Rang r(⃗c i , ⃗x) aller Prototypen bestimmt. Dabei wird die in Gl. 

2.14 definierte Metrik verwendet. Anschließend werden die Zentren der Units nach 

Gl. 2.7 aktualisiert, wobei die Trainingsparameter nach Gl. 2.8 und 2.9 exponentiell 

abfallen. 

Das Verfahren zur Bestimmung der lokalen PCAs ist austauschbar. In dieser Bachelorarbeit 

wurde RRLSA (Möller und Hoffmann, 2004) verwendet. Hierbei ist auf anschließende 

Orthonormalisierung von W i zu achten. Die Residualvarianz ergibt sich aus 

mit α = ɛ · h p (r(⃗c i , ⃗x)). 

∆σ 2 i = α( ⃗ ξ i T ⃗ ξi − ⃗y i T ⃗y i − σ 2 i ) (2.15) 

Das beschriebene Verfahren aktualisiert in jeder Iteration alle Units und wird im Folgenden 

Soft Clustering genannt. In einigen Szenarien kann es ausreichend sein, nur die Unit 

mit der niedrigsten Distanz zum Trainingsvektor ⃗x zu adaptieren (U i mit r(⃗c i , ⃗x) = 0). 

Dieser als Hard Clustering bezeichnete Ansatz hat den Vorteil, einen Großteil der für 

die Adaption der PCAs benötigten Rechenzeit einzusparen. 

2.6 Orthonormalisierung 

Zur Orthonormalisierung wird das Gram-Schmidtsche Orthonormalisierungsverfahren 

(Giraud et al., 2005) verwendet, welches zu den Vektoren ⃗a 1 , . . . , ⃗a n ein Orthonormalsystem 

⃗q 1 , . . . , ⃗q n berechnet. Der klassische Algorithmus (Listing 2.1) ist jedoch numerisch 

instabil (Björck, 1994), weshalb die mathematisch äquivalente modifizierte Variante 

benutzt wird (Listing 2.2). 

f o r i = 1 : n 

⃗q i = ⃗a i 

f o r i = 1 : n 

⃗q i = ⃗a i 

f o r j = 1 : i −1 

∆⃗q i = −〈⃗q j , ⃗a i 〉 · ⃗q j 

end 

f o r j = 1 : i −1 

∆⃗q i = −〈⃗q j , ⃗q i 〉 · ⃗q j 

end 

end 

⃗q i = ⃗q i / ‖⃗q i ‖ 

end 

⃗q i = ⃗q i / ‖⃗q i ‖ 

Listing 2.1: Klassische Gram-Schmidt Orthogonalisierung 

Listing 2.2: Modifizierte Gram-Schmidt Orthogonalisierung 

Dabei bezeichnet 〈⃗a, ⃗ b〉 das Skalarprodukt zwischen ⃗a und ⃗ b. 


3 

Implementation 

In diesem Kapitel wird die Realisierung des NGPCA-Algorithmus auf der Grafikkarte 

erläutert. Hierfür wurde C++ als Programmiersprache und OpenCL als Schnittstelle 

zur Programmierung der GPU verwendet. Da OpenCL in C geschrieben ist, wurden 

die OpenCL C++ Bindings (siehe Anhang D) verwendet. Diese ermöglichen einen 

objektorientierten Zugriff auf die OpenCL-Funktionen und erlauben die elegante 

Fehlerabfrage mittels Exceptions. 

Die Anwendung wurde durchgehend objektorientiert entworfen, eine Übersicht über 

die wichtigsten erstellten Klassen können Sie dem Klassendiagramm in Abbildung 3.1 

entnehmen. 

CLI 

CLI(argc,argv) 

parse() : int 

units : Unit* 

params : NGPCAParams 

NGPCA 

NGPCA(params,threadCount,hardClustering,...,deviceId) 

loadFromFile(file) 

learn(iterations) 

write(file) 

NGPCAParams 

prototypes : uint 

eigenvalues : uint 

Unit 

center : T* 

w : T* 

lambda : T* 

sigma : T* 

write(out) : void 

Abbildung 3.1: Klassendiagramm der wichtigsten Klassen. Einzelne Attribute und Methoden wurden weggelassen. 

Einstiegspunkt der Applikation ist die CLI-Klasse. Hier werden die Kommandozeilenparameter 

mit Hilfe der Boost Program Options Bibliothek (siehe Anhang 

D) ausgewertet und durch sinnvolle Vorgabewerte erweitert. Des Weiteren werden 

Hilfsfunktionen wie die Anzeige aller verfügbarer OpenCL-Geräte oder die Darstellung 

einer Hilfeseite bereitgestellt. Die zuvor erfassten Trainingsparameter werden in einem 

NGPCAParams-Struct gespeichert und für die Instanziierung eines NGPCA-Objektes 

verwendet. Da die NGPCA-Klasse generisch programmiert wurde, ist eine einfache 

Umstellung von 32 Bit Fließkommazahlen auf 64 Bit möglich. In der Praxis muss ein 

NGPCA-Netzwerk aber mit doppelter Genauigkeit trainiert werden, da das Ergebnis 


3 Implementation 

sonst unzureichend ist. Dies ist insbesondere für die Implementierung auf der Grafikkarte 

von Nachteil, da Berechnungen mit doppelter Genauigkeit deutlich langsamer 

durchgeführt werden (siehe Tabelle 4.1). 

Über die loadFromFile-Methode der NGPCA-Klasse kann nun eine Matrix mit 

Trainingsdaten geladen werden. Dabei wird der OpenCL-Quellcode für das gewählte 

Gerät kompiliert, wobei datensatzspezifische Precompiler-Direktiven wie z.B. die 

Größe der Eingabevektoren, die zu benutzende Eigenwertanzahl etc. gesetzt werden. 

Dadurch kann der OpenCL-Compiler Optimierungen wie z.B. Loop Unrolling (Murthy 

et al., 2010) vornehmen, die bei Übergabe der Parameter zur Laufzeit nicht möglich 

wären. Nach dem Kompiliervorgang werden die Units auf der Grafikkarte initialisiert 

und die Eingabedaten auf das OpenCL-Gerät kopiert (siehe Kapitel 3.1), so dass nach 

dem Ausführen der loadFromFile-Methode alle benötigten Daten initialisiert auf der 

Grafikkarte vorliegen. 

Der Lernprozess kann mit der learn-Methode der NGPCA-Klasse gestartet werden, 

wobei die Anzahl der Iterationen als Parameter übergeben wird. Grundidee 

ist, dass jede Unit eine Work-Group bildet, so dass die Distanzberechnung und die 

Adaption parallel über alle Units durchgeführt wird. Die Daten der Units U i = 

(⃗c i , W i , Λ i , σi 2 ) verbleiben dabei aus Performancegründen während des gesamten Lernprozesses 

im globalen Speicher der Grafikkarte und werden erst zur finalen Speicherung 

wieder in den Arbeitsspeicher kopiert. Da eine globale Synchronisation 

über alle Units nicht innerhalb eines Kernels möglich ist, jedoch für das Ranking 

benötigt wird, wurde jede Iteration in 4 Kernel unterteilt (siehe Abbildung 3.2). 

Zunächst wird die Distanzberechnung für 

einen Datenpunkt ⃗x parallel ausgeführt. Anschließend 

werden die Resultate zur Rangbestimmung 

r(⃗c i , ⃗x) sortiert und parallel dazu 

die Lernparameter bestimmt. Abschließend 

findet die Adaption (inkl. Orthonormalisierung) 

wieder parallel über alle Units statt. Bei 

der Verwendung von Hard Clustering (Kapitel 

2.5.3) wird jedoch nur eine Unit angepasst, 

weshalb die in Abbildung 3.2 rot markierten 

Schritte nicht ausgeführt werden. 

Alle j Iterationen wird ein weiterer Kernel 

zur Überprüfung der Units gestartet. Dieser 

erkennt “tote” Units und setzt diese zurück 

(Welsch, 2009). 

Der auf der CPU während einer Iteration 

ausgeführte Programmcode ist ein potentieller 

Flaschenhals und wurde somit möglichst 

effizient gestaltet. Es wird lediglich der 

nächste Trainingsvektor zufällig bestimmt, 

dessen Index als Kernelparameter übergeben 

Kernel: Distanzberechnung 

Unit 1 Unit 2 ... Unit k 

Kernel: Ranking und Parameterbestimmung 

Ranking 

Kernel: Adaption 

Parameterbestimmung 


Kernel: Überprüfung der Units 


Abbildung 3.2: Kernelaufrufe einer Iteration 

und der Start der entsprechenden Kernel angestoßen. In den Kapiteln 3.1 bis 3.4 werden 

die einzelnen Trainingsschritte näher erläutert. 



Nachdem das NGPCA-Netzwerk erfolgreich trainiert wurde, kann mit der write- 

Methode der NGPCA-Klasse das Ergebnis in einer Datei gespeichert werden. Dabei 

werden die Daten U i von der Grafikkarte kopiert und in einem speziellen Format in die 

übergebene Datei geschrieben. 

3.1 Initialisierung 

Die Initialisierung beginnt mit der Bestimmung einer sinnvollen Work-Group-Größe 

aufgrund der festgelegten Thread-Anzahl. Dazu werden die zu benutzenden Threads 

auf ein zweidimensionales Gitter aufgeteilt, wobei dieses jeweils optimal zu den 

verwendeten Kerneln gewählt wird. Außerdem wird sichergestellt, dass aufgrund der 

verwendeten Reduktionen (Sanders und Kandrot, 2010) nur Zweierpotenzen benutzt 

werden. 

Anschließend wird der in die Applikation automatisch einkompilierte OpenCL- 

Quellcode für das gewählte Gerät kompiliert, wonach die Trainingsvektoren auf das 

Gerät kopiert werden. Abschließend wird (globaler) Speicher für die Units reserviert, 

welcher dann mit einem Kernel parallel für alle Units initialisiert wird. Der Trainingsvektor 

wird innerhalb des Kernels zufällig gewählt und gesetzt, wobei ein 32 Bit Xorshift 

Pseudozufallszahlengenerator 1 (Marsaglia, 2003) zum Einsatz kommt. Dieser wird 

auch für die Initialisierung der Gewichtsmatrix W i benutzt, die anschließend gemäß 

Kapitel 3.4.2 orthonormalisiert wird. Alle weiteren Parameter können einfach aus dem 

übergebenen NGPCAParams-Struct übernommen werden. 

3.2 Distanzberechnung 

Wie bereits erwähnt, berechnet jede Work-Group die Distanz einer Unit U i zum 

Trainingsvektor ⃗x. Bei Vektoroperationen wie z.B. ξ ⃗ i = ⃗x − ⃗c i werden die Work-Items 

eindimensional verwendet, so dass jedes Work-Item eine oder mehrere Positionen in 

dem resultierenden Vektor ermittelt. Matrixoperationen werden hingegen zweidimensional 

ausgeführt. 

Skalare Werte wie ⃗ ξ i T ⃗ ξi und ⃗y i T ⃗y i werden mittels Reduktion (Sanders und Kandrot, 

2010) berechnet, was sich insbesondere bei großen Trainingsvektoren positiv auf die 

Laufzeit auswirkt. Um doppelte Berechnungen zu vermeiden, wird das resultierende ⃗ ξ i , 

⃗y i , ⃗ ξ i T ⃗ ξi und ⃗y i T ⃗y i für die spätere Adaption im globalen Speicher zwischengespeichert. 

Für die Erkennung von “toten” Units besitzt jede Unit einen Zähler, der die “Restlebensdauer” 

angibt. Dieser wird bei der Distanzberechnung dekrementiert und bei Adaptierung 

einer Unit wieder zurückgesetzt. Ein spezieller Kernel (siehe Abbildung 3.2) 

überprüft die verbleibende Lebensdauer aller Units in einem einstellbaren Intervall und 

setzt diese ggf. zurück (Welsch, 2009). 

1 Quellcode siehe Anhang B.1 



3.2.1 Verwendetes Potential 

Das in Gl. 2.14 beschriebene Potential wurde implementiert und wird im Folgenden 

VConst bezeichnet. Es eignet sich jedoch nicht optimal für die GPU, da Wurzeln mit 

relativ hohen Wurzelexponenten berechnet werden müssen. Während das Wurzelziehen 

auf 32 Bit Fließkommazahlen hardwareseitig implementiert ist (Munshi, 2012), sind 64 

Bit Wurzeloperationen relativ langsam. 

Als Alternative wurde daher ein weiteres Potential 

( 

d i (⃗x) = ⃗y i T Λ −1 

i ⃗y i + 1 ) 

( ξ 

λ ⃗T ⃗ ∗ i ξ i − ⃗y i T ⃗y i ) · 

i 

( 

Tr (Λ −1 

i ) + 

) −1 

(n − m)2 

(3.1) 

σi 

2 

mit ξ ⃗ i = ⃗x − ⃗c i , ⃗y i = Wi T ξ ⃗ i und λ ∗ i = σ2 i 

implementiert, welches im Folgenden 

n−m 

TracePotential genannt wird (Kaiser und Schenck). 

3.3 Ranking 

Zur Bestimmung des Ranges r(⃗c i , ⃗x) einer Unit U i werden die in Kapitel 3.2 berechneten 

Distanzen aufsteigend sortiert. Der resultierende Rang ist dann die Position 

z ∈ [0 . . . k − 1] der zu der Unit gehörenden Distanz in der sortierten Distanzliste. 

3.3.1 Sortierverfahren 

Als Sortierverfahren wurde eine modifizierte Variante des Parallel Selection Sort 2,3 

verwendet. Dies ist ein naiver Algorithmus, der parallel jeden zu sortierenden Wert mit 

allen anderen Einträgen vergleicht. 

Da alle Work-Items gleichzeitig dieselbe Distanz zum Vergleich heranziehen, kann 

durch Broadcasting (Sanders und Kandrot, 2010) dennoch eine recht hohe Geschwindigkeit 

erreicht werden. Bei genügend Hardwareressourcen und damit einer echten 

parallelen Ausführung des Sortiervorganges wird eine Komplexität von O(n) erreicht. 

Es gibt durchaus noch schnellere und durch lokalen Speicher beschleunigte Sortierverfahren. 

Auf einen aufwändigen Algorithmus wurde aufgrund der niedrigen Anzahl der 

zu sortierenden Elemente und dem hierdurch geringen Anteil des Rankings an der Gesamtlaufzeit 

(siehe Tabelle 4.5) allerdings verzichtet. 

3.4 Adaptierung 

Die Adaptierung erfolgt wieder parallel für alle Units und basiert auf dem zuvor 

ermittelten Rang. Während beim Soft Clustering alle Units angepasst werden, wird 

beim Hard Clustering nur die Unit mit Rang 0 angepasst. Alle anderen Work-Groups 

beenden ihre Ausführung unmittelbar nach dieser Überprüfung. 

2 http://www.bealto.com/gpu-sorting_parallel-selection.html 

Datum: 21.09.2012 




Zunächst wird nach Gl. 2.7 das Zentrum der jeweiligen der Unit aktualisiert. Anschließend 

erfolgt die Berechnung der lokalen PCA mittels RRLSA (siehe Kapitel 3.4.1) und 

das wie in Kapitel 3.2 beschriebene Zurücksetzen des Alters der Unit. Die Residualvarianz 

wird nach Gl. 2.15 angepasst. Bei Erreichen des eingestellten Orthonormalisierungsintervalles 

(siehe Anhang E) erfolgt die Orthonormalisierung von W i nach Kapitel 

3.4.2. 

3.4.1 Hauptkomponentenanalyse 

Die lokale PCA wird mittels RRLSA (siehe Kapitel 2.5.1) berechnet. Dafür wird 

zunächst das während der Distanzberechnung ermittelte ⃗y i wegen der häufigen Verwendung 

in den lokalen Speicher geladen. Zur einfacheren Berechnung wird eine unnormalisierte 

Version von W i zusätzlich im globalen Speicher vorgehalten. W i und Λ i ergibt 

sich dann aus Gl. 2.13. Für die Normalisierung wird wie bei der Distanzberechnung eine 

Reduktion verwendet. 

3.4.2 Orthonormalisierung 

Das in Kapitel 2.6 beschriebene modifizierte Gram-Schmidtsche Orthogonalisierungsverfahren 

(MGS) ist zwar numerisch stabil, allerdings erzeugt es das Orthonormalsystem 

⃗q 1 , . . . , ⃗q n sequenziell. Aus diesem Grund ist es nur schlecht für eine 

Verwendung auf der GPU geeignet. Dennoch lässt sich das Verfahren parallel auf der 

GPU implementieren, so dass es deutlich schneller als die naive MGS Implementierung 

ist. 

Der Algorithmus 4 (Listing 3.1) arbeitet dabei direkt auf den zu orthonormalisierenden 

Vektoren, womit die Initialisierung ⃗q i = ⃗a i entfällt. Diese werden im Folgenden 

⃗q 1 , . . . , ⃗q n bezeichnet. 

Zunächst wird der erste Vektor ⃗q 1 mittels Reduktion normalisiert und das Ergebnis 

zurück in den globalen Speicher geschrieben. Der normalisierte Vektor ⃗q 1 verbleibt jedoch 

im lokalen Speicher der Work-Group und wird im Folgenden q last ⃗ genannt. Anschließend 

können alle Vektoren ⃗q i , i ∈ [2 . . . n] parallel das Skalarprodukt mit q last ⃗ 

bilden. Dieses wird multipliziert mit q last ⃗ von dem Vektor ⃗q i subtrahiert: 

∆⃗q i = −〈⃗q i , q last ⃗ 〉 · q last ⃗ ∀ i ∈ [2 . . . n] (3.2) 

Durch Normalisierung ⃗q 2 = ⃗q 2 / ‖⃗q 2 ‖ ergibt sich der zweite Vektor des Orthonormalsystemes. 

Dieser wird nun als letzter orthonormalisierter Vektor q last ⃗ im lokalen 

Speicher gehalten, womit der Algorithmus mit der Aktualisierung aller Vektoren 

⃗q i , i ∈ [3 . . . n] fortfährt. Bei jeder Iteration ergibt sich also sequenziell ein Ergebnisvektor 

⃗q i , wobei die Anpassung der verbleibenden Vektoren ⃗q j , j ∈ [i + 1 . . . n] parallel 

geschieht. 

Der gesamte Algorithmus lässt sich zu Listing 3.1 zusammenfassen. 




⃗q 1 = ⃗q 1 / ‖⃗q 1 ‖ 

q last ⃗ = ⃗q 1 

f o r j = 2 : n 

∆⃗q i = −〈⃗q i , q last ⃗ 〉 · q last ⃗ ∀ i ∈ [j . . . n] 

end 

⃗q j = ⃗q j / ‖⃗q j ‖ 

q last ⃗ = ⃗q j 

Listing 3.1: Parallele Gram-Schmidt Orthonormalisierung 

Dabei erfolgt die Anpassung ∆⃗q i parallel über alle i. Alle Normierungen und Skalarprodukte 

werden durch Reduktionen berechnet. 

3.5 Harte Vektorquantisierung 

Wie bereits in Kapitel 2.5.3 und 3 erwähnt wurde, wird beim Hard Clustering nur eine 

Unit adaptiert. Dies spart einen Großteil der für die Adaption benötigten Rechenzeit 

ein. Es hat jedoch auch zur Folge, dass der Parallelitätsgrad während der Adaption sehr 

niedrig ist, wodurch nur ein Bruchteil der möglichen GPU-Leistung tatsächlich benutzt 

wird. 

Um die Auslastung der Grafikkarte zu 

erhöhen werden r Trainingsvektoren gleichzeitig 

Kernel: Distanzberechnung 

präsentiert (siehe Abbildung 3.3). 

Der Distanzkernel arbeitet folglich auf k · r 

Unit 1 

Unit k 

... 

x 1, x 2, ... x r 

x 1, x 2, ... x r 

Work-Groups, wobei k die Anzahl der benutzten 

Prototypen ist. Jede Work-Group berechnet 

also die Distanz einer bestimmten Unit U i 

Kernel: Ranking und Parameterbestimmung 

zu einem festgelegten Trainingsvektor ⃗x j . 

Ranking 

Ranking 

Parameterbestimmung 

Durch die Erweiterung auf mehrere Datenpunkte 

kann das Ranking ebenfalls erwei- 

... 

x 1 

x r 

tert werden. Dabei ermittelt jede Work-Group 

des Ranking-Kernels für einen bestimmten 

Kernel: Altersupdate der Units 

Datenpunkt ⃗x j die “Gewinnerunit” U i mit 

r(⃗c i , ⃗x j ) = 0. Bei den ermittelten “Gewinnerunits” 

Unit ... Unit 

kann es jedoch zu Überschneidungen 

kommen, falls zwei Trainingsvektoren derselben 

Kernel: Adaption 

Unit zugeordnet sind. Daher werden nur 

die zugeordneten Units der ersten s ≤ r Datenpunkte 

adaptiert, bei denen keine Überschneidung 

in den zu adaptierenden Units vorliegt. 

Unit 

Unit 

... 

x 1 

x s 

Kernel: Überprüfung der Units 

Im schlechtesten Fall wird nur eine Unit 

angepasst, im günstigsten Fall allerdings r 

Unit 1 ... Unit k 

Units auf einmal. 

Abbildung 3.3: Kernelaufrufe einer Iterationsreihe, 

Bitte beachten Sie, dass das in Kapitel 3.2 beschriebene 

dekrementieren der “Restlebens- 

Hard Clustering 

dauer” aller Units durch die geänderte Distanzberechnung nicht mehr im Distanzkernel 



geschehen kann, weshalb für diese Aufgabe ein zusätzlicher Kernel “Altersupdate der 

Units” hinzugefügt wurde. 

3.5.1 Adaptive Anpassung der parallelen Trainingsvektoren 

Der in Kapitel 3.5 beschriebene Ansatz funktioniert bei passend gewählter Anzahl 

r an parallel zu verarbeitenden Trainingsvektoren sehr gut und liefert einen hohen 

zusätzlichen Speedup. Leider ist dieser Parameter nicht intuitiv zu wählen und hängt 

stark vom verwendeten Datensatz und der Anzahl an Prototypen ab. Zu kleine Werte 

von r lasten die GPU nicht vollständig aus und verschenken so einen möglichen 

Performancegewinn. Wählt man den Parameter zu hoch, werden Distanzen zu sehr 

vielen Datenpunkten berechnet, von denen allerdings nur ein geringer Teil tatsächlich 

verwendet wird. Die Folge ist ein schlechter Speedup. 

Lösung für dieses Problem ist eine adaptive Anpassung der Anzahl an parallelen Trainingsvektoren. 

Zu Beginn des Lernprozesses ist der Parameter hoch gewählt, wird aber 

in einem einstellbaren Intervall (siehe Anhang E) durch den beobachteten (aufgerundeten) 

Mittelwert der tatsächlich adaptierten Units ersetzt. 


4 

Experimentelle Ergebnisse 

In diesem Kapitel wird die erzielte Geschwindigkeit anhand von zwei ausgewählten 

Datensätzen mit der Referenz-CPU-Implementierung verglichen. Betrachtet wird dabei 

der Speedup S = tcpu 

t gpu 

, also die durch die GPU-Implementierung erzielte Beschleunigung 

des Lernprozesses. 

Zunächst wird in Kapitel 4.1 kurz auf die verwendete Hardware eingegangen, während 

anschließend in Kapitel 4.2 und 4.3 die analysierten Datensätze erläutert werden. Der 

Einfluss einzelner Parameter auf den Speedup wird in Kapitel 4.4 betrachtet. Eine Übersicht 

über die Laufzeiten der einzelnen Kernel liefert Kapitel 4.5. 

4.1 Hardware 

Sämtliche Analysen wurden auf baugleichen Rechnern 1 durchgeführt, einzig die Laufzeiten 

der AMD Karten sind auf einem etwas langsameren System 2 gemessen worden. 

Die Leistungsdaten der verwendeten Grafikkarten können Sie Tabelle 4.1 entnehmen, 

wobei die theoretische Maximalleistung durch 

P max = Prozessortakt · #Shader · Operationen 

Takt 

(4.1) 

berechnen wurde. Von besonderem Interesse ist hier die 64 Bit Performance, da NGPCA 

in doppelter Genauigkeit trainiert wird (siehe Kapitel 3). Dabei ergibt sich die 64 Bit 

Performance bei Nvidia Consumer Karten als 1/8 der 32 Bit Performance bzw. bei 

AMD als 1/4. 

1 Intel(R) Core(TM) i7-2600 CPU, 8 GB RAM 

2 Intel(R) Core(TM) i7-930 CPU, 6 GB RAM 


4 Experimentelle Ergebnisse 

Bezeichnung Takt #Shader P max (32 Bit) P max (64 Bit) 

Nvidia GTX 560 Ti 1,645 GHz 384 1263 GFLOPs 158 GFLOPs 

Nvidia GTX 570 1,4 GHz 480 1344 GFLOPs 168 GFLOPs 

AMD Radeon HD 6970 3 0,94 GHz 1536 2888 GFLOPs 722 GFLOPs 

AMD Radeon HD 7970 4 1,05 GHz 2048 4301 GFLOPs 1075 GFLOPs 

Tabelle 4.1: Theoretische Leistungsdaten der verwendeten Grafikkarten (Operationen/Takt = 2 bei FMA) 

4.2 Roboterarmsteuerung 

Bei diesem 68-dimensionalen Datensatz aus N = 3213 Datenpunkten soll die 

Steuerung eines Roboterarmes gelernt werden. Dabei soll der Roboterarm ein kleines 

Klötzchen greifen. Eine detaillierte Beschreibung des Szenarios finden Sie in Schenck 

(2008) und Hoffmann et al. (2005). 

Abbildung 4.1 zeigt den erreichten Speedup in Abhängigkeit von der verwendeten Grafikkarte. 

Dabei wurde jeweils die Threadanzahl mit dem besten Speedup gewählt (siehe 

Anhang A.1). Interessant ist hierbei die schlechte Performance der AMD Karten und 

der deutlich höhere Speedup beim Soft Clustering. 

12 

10 

Nvidia GTX 560 Ti 

Nvidia GTX 570 

AMD Radeon HD 6970 


6 

5 





8 

4 

speedup 

6 

speedup 

3 

4 

2 

2 

1 

0 

0 20 40 60 80 100 120 140 160 180 200 

clusters 

(a) Soft Clustering 

0 

0 20 40 60 80 100 120 140 160 180 200 

clusters 

(b) Hard Clustering 

Abbildung 4.1: Speedup der Grafikkarten nach Anzahl der Prototypen [4 Eigenwerte, 20.000 Iterationen, optimale 

Threadanzahl] 

Für die Evaluation der Lernqualität (Tabelle 4.2) wurde der in Schenck (2008) beschriebene 

Greiffehler betrachtet. Dabei ist erkennbar, dass die GPU Implementation bei diesem 

Datensatz qualitativ gleichwertig mit der CPU-Referenzimplementierung ist. 

CPU GPU (VConst) GPU (TracePot.) 

Avg. Error 0,871 0,862 0,872 

Std. Dev 0,030 0,036 0,041 

Tabelle 4.2: Greiffehler [4 Eigenwerte, 100 Prototypen, 20.000 Iterationen, Hard Clustering] 

3 http://www.msi.com/product/vga/R6970-Lightning.html 

Datum: 18.09.2012 

4 http://www.hisdigital.com/de/product2-692.shtml 

Datum: 18.09.2012 



4.3 CT Slices 

Dieser 385-dimensionale Datensatz mit N = 53500 Datenpunkten enthält Merkmale 

aus Computertomographie-Schnittbildaufnahmen 5 . Der Merkmalsvektor wird dabei aus 

zwei Histogrammen gebildet, die die Knochenstruktur und die Lufteinschlüsse jeder 

Aufnahme beschreiben. Ziel dabei ist, die relative Position der Schnittbilder zu erlernen. 

In Abbildung 4.2 wird der erreichte Speedup bei optimaler Threadanzahl (siehe Anhang 

A.2) in Abhängigkeit von der verwendeten Grafikkarte gezeigt. Dabei ist die relative hohe 

Soft Clustering Performance der Radeon HD 7970 und der allgemein höhere Speedup 

beim Hard Clustering besonders bemerkenswert. 

4.5 

6 

4 

5 

3.5 

4 

speedup 

3 

2.5 

2 

1.5 



Radeon HD 6970 


speedup 

3 

2 

1 





1 

50 100 150 200 250 300 

clusters 


0 

50 100 150 200 250 300 

clusters 


Abbildung 4.2: Speedup der Grafikkarten nach Anzahl der Prototypen [20 Eigenwerte, 20.000 Iterationen, optimale 

Threadanzahl] 

Die Lernqualität wurde mit dem normalized Mean Square Error (Normalized MSE) 

beurteilt, der über alle Datenpunkte berechnet wurde (Tabelle 4.3). Hierbei ist eine 

deutliche Qualitätverbesserung durch die GPU-Implementierung gegenüber der CPU- 

Referenzimplementierung sichtbar. Des Weiteren verbessert das vermeintlich schlechtere 

Potential das Ergebnis. 

CPU GPU (VConst) GPU (TracePot.) 

Avg. Error 4,663 1,306 0,899 

Std. Dev 1,478 0,315 0,301 

Tabelle 4.3: Normalized MSE [20 Eigenwerte, 200 Prototypen, 200.000 Iterationen, Hard Clustering] 

5 http://archive.ics.uci.edu/ml/datasets/Relative+location+of+CT+ 

slices+on+axial+axis 

Datum: 18.09.2012 



4.4 Speedup nach gewählten Parametern 

In diesem Kapitel wird der Einfluss einzelner Trainingsparameter auf den Speedup untersucht. 

Da sich die Architektur der verwendeten Nvidia Karten untereinander bzw. 

der AMD Karten untereinander nur gering unterscheidet, werden im Folgenden nur die 

Nvidia GTX 570 und die AMD Radeon HD 7970 betrachtet. 

4.4.1 Anzahl der Prototypen 

Abbildung 4.3 und 4.4 zeigen die Abhängigkeit des Speedup von der Anzahl der verwendeten 

Prototypen. Eine höhere Anzahl bewirkt einen größeren Speedup, wobei die 

Steigung mit steigender Anzahl an Unit’s abnimmt. Insbesondere das Hard Clustering 

profitiert von vielen Prototypen. 

11 

10 

9 

8 

32 threads 

64 threads 

128 threads 

256 threads 

512 threads 

5.5 

5 

4.5 

4 

7 

3.5 

speedup 

6 

speedup 

3 

5 

4 

3 

2.5 

2 

1.5 

32 threads 

64 threads 

128 threads 

256 threads 

512 threads 

2 

1 

1 

0 20 40 60 80 100 120 140 160 180 200 

clusters 

(a) Soft Clustering, Nvidia GTX 570 

0.5 

0 20 40 60 80 100 120 140 160 180 200 

clusters 

(b) Hard Clustering, Nvidia GTX 570 

Abbildung 4.3: Speedup nach Prototypen und Threads [Arm Datensatz, 4 Eigenwerte, 20.000 Iterationen] 

speedup 

4.5 

4 

3.5 

3 

2.5 

speedup 

5 

4.5 

4 

3.5 

3 

2.5 

2 

32 threads 

64 threads 

128 threads 

256 threads 

512 threads 

2 

1.5 

32 threads 

64 threads 

128 threads 

256 threads 

512 threads 

1.5 

1 

0.5 

1 

50 100 150 200 250 300 

clusters 

(a) Soft Clustering, Radeon HD 7970 

0 

50 100 150 200 250 300 

clusters 

(b) Hard Clustering, Radeon HD 7970 

Abbildung 4.4: Speedup nach Prototypen und Threads [CT Datensatz, 20 Eigenwerte, 20.000 Iterationen] 



4.4.2 Anzahl der Eigenwerte 

Der Zusammenhang zwischen Speedup und der verwendeten Anzahl an Eigenwerten 

wird in Abbildung 4.5 gezeigt. Für diese Evaluation wurde der CT Datensatz ausgewählt, 

da die Qualität der Lernergebnisse relativ unempfindlich auf die gewählte 

Eigenwertanzahl ist. 

Beim Soft Clustering fällt der Speedup mit steigender Eigenwertanzahl auf einen Grenzwert 

ab, wobei dieser bei der AMD Radeon HD 7970 höher ausfällt und die Änderung 

geringer ist. Für Hard Clustering ist die Nvidia GTX 570 jedoch besser geeignet, da 

der Speedup hier deutlich höher ausfällt und ab einer gewissen Eigenwertanzahl auch 

wieder leicht ansteigt. 

speedup 

10 

9 

8 

7 

6 

5 

4 

32 threads 

64 threads 

128 threads 

256 threads 

512 threads 

speedup 

7 

6 

5 

4 

3 

32 threads 

64 threads 

128 threads 

256 threads 

512 threads 

3 

2 

2 

1 

0 5 10 15 20 25 30 

eigenvalues 

(a) Soft Clustering, Nvidia GTX 570 

1 

0 5 10 15 20 25 30 

eigenvalues 

(b) Soft Clustering, Radeon HD 7970 

7 

6 

5 

4 

3.5 

3 

32 threads 

64 threads 

128 threads 

256 threads 

512 threads 

speedup 

4 

speedup 

2.5 

3 

2 

32 threads 

64 threads 

128 threads 

256 threads 

512 threads 

2 

1.5 

1 

0 5 10 15 20 25 30 

eigenvalues 

(c) Hard Clustering, Nvidia GTX 570 

1 

0 5 10 15 20 25 30 

eigenvalues 

(d) Hard Clustering, Radeon HD 7970 

Abbildung 4.5: Speedup nach Eigenwerten und Threads [CT Datensatz, 20 Eigenwerte, 200 Prototypen, 20.000 Iterationen] 



4.4.3 Verwendetes Potential 

Diese Auswertung untersucht die durch das angepasste Potential (siehe Kapitel 3.2.1) 

verursachte Beschleunigung. Hierbei wurde der CT Datensatz ausgewählt, obwohl 

bei dem Arm Datensatz deutlich höhere Beschleunigungen von etwa 27 % gemessen 

wurden. Auf eine Darstellung des Speedups in Abhängigkeit von der Eigenwertanzahl 

wurde für den Arm Datensatz aufgrund der in Kapitel 4.4.2 genannten Sensitivität 

allerdings verzichtet. 

Das Soft Clustering wird durch das angepasste Potential nicht nennenswert beschleunigt 

(deutlich unter 1 %). Beim Hard Clustering wird jedoch ein zusätzlicher Speedup von 

etwa 5 % erreicht, wobei die Nvidia Karten ein wesentlich stabileres Verhalten zeigen. 

1.014 

1.5 

1.012 

1.01 

1.008 





1.4 

1.3 





speedup 

1.006 

1.004 

1.002 

speedup 

1.2 

1.1 

1 

1 

0.998 

0.996 

0.9 

0.994 

0 5 10 15 20 25 30 

eigenvalues 


0.8 

0 5 10 15 20 25 30 

eigenvalues 


Abbildung 4.6: Speedup nach Eigenwerten [CT Datensatz, 200 Prototypen, 20.000 Iterationen, 512 Threads] 

4.5 Kernellaufzeiten 

In diesem Kapitel wird der Laufzeitanteil der verwendeten Kernel an der Gesamtlaufzeit 

betrachtet. 

Beide Plattformen weisen auf dem Arm Datensatz (Tabelle 4.4) deutliche Unterschiede 

auf, während sich die Laufzeitcharakteristik bei dem aufwändigeren CT Datensatz (Tabelle 

4.5) annähert. Beim Hard Clustering des CT Datensatzes (Tabelle 4.5) trägt die Distanzberechnung 

und die Adaption etwa gleichwertig zur Gesamtlaufzeit bei, die Laufzeit 

des Soft Clusterings wird jedoch fast ausschließlich von der Adaption bestimmt. 

Auffällig ist auch, dass eigentlich sehr einfache Kernel wie die Unit Reset Heuristik 

und das Ranking auf der AMD Plattform deutlich stärker ins Gewicht fallen. 



Kernel 

Laufzeitanteil 

Nvidia GTX 570 AMD Radeon HD 7970 

Hard Cl. Soft Cl. Hard Cl. Soft Cl. 

Distanzberechnung 43,5 % 4,3 % 25,6 % 17,5 % 

Unit Reset 15,9 % 0,8 % 14,8 % 1,9 % 

Ranking + Parameterbestimmung 6,7 % 2,6 % 26,4 % 30,5 % 

Unit Altersupdate 2,2 % 1,4 % 

Adaption 31,7 % 92,2 % 31,8 % 50,0 % 

Tabelle 4.4: Kernellaufzeiten [Arm Datensatz, 4 Eigenwerte, 100 Prototypen, 20.000 Iterationen, 512 Threads] 

Kernel 

Laufzeitanteil 

Nvidia GTX 570 AMD Radeon HD 7970 

Hard Cl. Soft Cl. Hard Cl. Soft Cl. 

Distanzberechnung 48,9 % 2,8 % 34,0 % 1,4 % 

Unit Reset 1,2 % 0,0 % 4,1 % 0,2 % 

Ranking + Parameterbestimmung 1,7 % 0,2 % 7,2 % 1,4 % 

Unit Altersupdate 0,3 % 0,2 % 

Adaption 47,9 % 97,0 % 54,5 % 97,0 % 

Tabelle 4.5: Kernellaufzeiten [CT Datensatz, 20 Eigenwerte, 200 Prototypen, 20.000 Iterationen, 512 Threads] 

Besonders interessant ist, dass die Laufzeit des Soft Clusterings beim CT Datensatz fast 

ausschließlich von der Adaption bestimmt wird. Die Vermutung liegt nahe, dass dieses 

Verhalten durch die höhere Eigenwertanzahl verursacht wird, da der Aufwand für die 

Orthonormalisierung quadratisch mit der Anzahl der Eigenwerte steigt (Möller, 2006). 

Aus diesem Grund wird in Abbildung 4.7 der Anteil der Orthonormalisierung an der 

Gesamtlaufzeit bei variierender Eigenwertanzahl untersucht. 

0.9 

0.45 

0.85 

0.4 

0.8 

0.35 

orthonormalization part 

0.75 

0.7 

0.65 

0.6 

orthonormalization part 

0.3 

0.25 

0.2 

0.15 

0.55 

0.5 



0.1 

0.05 



0.45 

0 5 10 15 20 25 30 

eigenvalues 


0 

0 5 10 15 20 25 30 

eigenvalues 


Abbildung 4.7: Anteil der Orthonormalisierung an der Gesamtlaufzeit [CT Datensatz, 200 Prototypen, 20.000 Iterationen, 

512 Threads] 


5 

Diskussion 

5.1 Pre-Tests 

Vor der eigentlichen Implementierung wurden einige Tests durchgeführt, die die Vorund 

Nachteile verschiedener Verfahren evaluiert haben. In diesem Kapitel werden die 

Verfahren erwähnt, die aufgrund ihrer Nachteile nicht implementiert wurden. 

5.1.1 PCA-Verfahren 

Das verwendete PCA-Verfahren RRLSA (Kapitel 2.5.1) liefert nicht mehr paarweise 

orthonormale Vektoren, weshalb eine regelmäßige Orthonormalisierung nötig ist. 

Coupled PCA (Möller und Konies, 2004) ist zwar etwas aufwändiger als RRLSA, soll 

allerdings die Orthonormalität der Hauptachsen größtenteils beibehalten. Dies würde 

den zeitaufwändigen Gram-Schmidt Algorithmus überflüssig machen. Leider hat sich 

dies nicht hinreichend bestätigt, so dass auch mit Coupled PCA in einem gewissen 

Intervall orthonormalisiert werden muss. 

Insgesamt gesehen ist RRLSA schneller als Coupled PCA, da auch Coupled PCA nur 

bei Orthonormalisierung nach jeder Iteration eine zu RRLSA vergleichbare Trainingsqualität 

liefert. 

5.1.2 Orthonormalisierungsverfahren 

Von Hyvärinen et al. (2001) wird ein iteratives symmetrisches Orthonormalisierungsverfahren 

beschrieben, welches sich von der Struktur her gut für GPUs eignet (wobei 

W die zu orthonormalisierende Matrix ist): 

W (1) = W (0)/‖W (0)‖ (5.1) 

W (t + 1) = 3 2 W (t) − 1 2 W (t)W (t)T W (t) (5.2) 

Dabei konvergiert W gegen die orthonormalisierte Matrix. 


5 Diskussion 

Der Test auf Konvergenz war allerdings zu aufwändig, weshalb mit einer festen Iterationszahl 

gearbeitet werden musste. Leider war dieses Verfahren nur bei geringer Iterationszahl 

schneller als die in Kapitel 3.4.2 beschriebene angepasste Gram-Schmidt 

Orthonormalisierung. Bei einer so geringen Iterationszahl war die Qualität der Orthonormalisierung 

allerdings nicht zufriedenstellend. 

5.1.3 Implementation einer OpenCL Matrix-Bibliothek 

NGPCA lässt sich mit Hilfe von Matrixoperationen sehr elegant programmieren. Daher 

wurde zunächst der Ansatz verfolgt, eine kleine Matrix-Bibliothek für OpenCL zu 

schreiben. Mit dieser sollte dann der NGPCA-Algorithmus implementiert werden. 

Zudem könnte die OpenCL-Bibliothek für weitere Projekte genutzt werden. 

Dieser Ansatz funktionierte gut und ermöglichte besonders leserlichen Code. Zudem 

konnte man bestehende Matlab-Algorithmen 1:1 auf der GPU implementieren. Leider 

müssen durch diese Herangehensweise viele Zwischenergebnisse gespeichert werden, 

welche zu groß für den lokalen Speicher sind und deshalb im globalen Speicher der 

Grafikkarte abgelegt werden müssen. Dies führt zu extrem vielen Speicherzugriffen 

und damit zu einer schlechten Gesamtperformance. 

Durch das explizite Implementieren der verwendeten Algorithmen konnten die Speicherzugriffe 

deutlich verringert und in den Matrix-Funktionen verwendete Schleifen 

zusammengefasst werden. 

5.2 Beurteilung der Ergebnisse 

Sowohl beim Hard- als auch bei Soft Clustering konnte ein erheblicher Geschwindigkeitszuwachs 

(Abbildung 4.1 und 4.2) gegenüber der CPU-Referenzimplementierung 

erreicht werden. Zusätzlich wird bei hochdimensionalen Datensätzen die Lernqualität 

signifikant verbessert (Tabelle 4.3). Dies liegt vermutlich an den verwendeten Reduktionen, 

die durch viele Zwischenergebnisse die numerische Stabilität verbessern. 

Während der Parallelitätsgrad beim Soft Clustering durch die gleichzeitige Berechnung 

der Prototypen hoch genug war, musste das Hard Clustering wie in Kapitel 3.5 

beschrieben angepasst werden. Hierdurch konnte auch beim Hard Clustering eine hohe 

GPU-Auslastung und ein damit verbundener signifikanter Speedup erreicht werden. 

Die Trainingsqualität wurde durch dieses Verfahren nicht negativ beeinflusst (Tabelle 

4.2 und 4.3). 

Es hat sich jedoch herausgestellt, dass sich der NGPCA-Algorithmus nicht so optimal 

wie ursprünglich gedacht für eine GPU-Implementierung eignet. Dies liegt vor allem an 

der nötigen doppelten Rechengenauigkeit, wodurch bei Nvidia Karten nur 1/8 der 32 

Bit Rechenleistung zur Verfügung steht (bei AMD Karten 1/4). In Hardware implementierte 

Funktionen, z.B. für das Wurzelziehen, stehen bei 64 Bit Berechnungen ebenfalls 

nicht zur Verfügung. Dies konnte jedoch durch ein angepasstes Potential (siehe Kapitel 

3.2.1 und 5.2.1) entschärft werden, welches auf langsame Wurzeloperationen verzichtet. 

Des Weiteren musste zur Synchronisation zwischen den Work-Groups jede Iteration in 

mehrere Kernel unterteilt werden, was hohe Ansprüche an die effiziente Gestaltung der 


5 Diskussion 

Kernelstarts in den entsprechenden Treibern stellt (siehe Kapitel 5.2.2). 

Der durch die GPU-Implementierung erzielte Speedup hängt jedoch teilweise stark von 

den gewählten NGPCA-Parametern (Kapitel 5.2.1) und der verwendeten Hardware (Kapitel 

5.2.2) ab. 

5.2.1 Einfluss der gewählten Parameter 

In diesem Kapitel wird der Einfluss einzelner Parameter auf den Speedup diskutiert. 

Insbesondere wird auf die Anzahl der Prototypen, die Anzahl der Eigenwerte und das 

verwendete Potential eingegangen. 

Anzahl der Prototypen 

Latency Hiding (Fatahalian und Houston, 2008) ist ein Grundkonzept von GPUs, 

wobei mehr Threads zur Ausführung vorgehalten werden als Hardwareressourcen 

zur Verfügung stehen. Sind nun einzelne Gruppen von Threads durch ausstehende 

Speicheranforderungen nicht ausführbar, können andere Threads bearbeitet werden. 

Die Grundidee der Implementation ist es, alle verwendeten Prototypen parallel auf 

der Grafikkarte zu berechnen. Jede Work-Group besteht dabei aus einer vordefinierten 

Anzahl an Threads (siehe Anhang E). Die Anzahl der von der Grafikkarte zu verarbeitenden 

Threads steigt somit mit der Anzahl der Units. Damit funktioniert das o.g. 

Latency Hiding besser, was sich positiv auf die Auslastung der Grafikkarte auswirkt. 

Resultat ist ein höherer Speedup. 

In Abbildung 4.3 und 4.4 ist eine Verbesserung des Speedup bei steigender Anzahl 

an Protoypen deutlich erkennbar. Die Steigung des Speedup nimmt jedoch mit zunehmenden 

Units ab. Ab einer gewissen Prototypanzahl bringen weitere Units bei der 

Betrachtung des Speedup also keinen Mehrwert, da die Grafikkarte bereits vollständig 

ausgelastet ist. 

Bei hochdimensionalen Datensätzen und Soft Clustering wird jedoch bereits bei 

wenigen Prototypen ein Speedup nahe des Maximums erreicht. Dies liegt an den 

aufwändigeren Berechnungen für hochdimensionale Vektoren, so dass die maximale 

Auslastung der GPU schneller erreicht wird. 

Generell profitiert das Hard Clustering stärker von einer höheren Prototypanzahl, was 

sich aufgrund des in Kapitel 3.5 beschriebenen Verfahrens erklären lässt. Während beim 

Soft Clustering alle Units parallel angepasst werden, werden beim Hard Clustering gerade 

so viele Units parallel adaptiert, dass keine Überschneidungen entstehen. Mehr 

Prototypen senken die Wahrscheinlichkeit, dass eine Unit doppelt angepasst werden 

würde, was wiederrum den Parallelitätsgrad und damit auch den Speedup erhöht. 

Anzahl der Eigenwerte 

Die Anzahl der verwendeten Eigenwerte hat ebenfalls Einfluss auf den resultierenden 

Speedup, allerdings besteht dieser Zusammenhang nur indirekt. 


5 Diskussion 

Wie in Abbildung 4.5 ersichtlich ist, fällt der Speedup beim Soft Clustering zunächst 

mit steigender Eigenwertanzahl ab. Nach Erreichen eines Schwellwertes bleibt er 

jedoch nahezu konstant. In Tabelle 4.5 ist erkennbar, dass die Laufzeit und damit 

auch der Speedup beim Soft Clustering mit hoher Eigenwertanzahl nur durch die 

Adaption bestimmt wird. Da der Aufwand für die Orthonormalisierung quadratisch 

mit der Anzahl der Eigenwerte steigt (Möller, 2006), steigt auch der Anteil der 

Orthonormalisierung an der Adaption. Folglich erhöht sich der Laufzeitanteil der 

Orthonormalisierung bei steigender Eigenwertanzahl, was deutlich in Abbildung 4.7a 

ersichtlich ist. Die Steigung des Laufzeitanteils fällt jedoch ab, was den Grenzwert in 

Abbildung 4.5a und 4.5b erklärt. 

Hieraus lässt sich schließen, dass die einzelnen Abschnitte der Implementation stark 

unterschiedliche Beschleunigungen des NGPCA-Algorithmus verursachen. Die nach 

Kapitel 3.4.2 implementierte Gram-Schmidt Orthonormalisierung hat im Vergleich 

zu den anderen Implementationsabschnitten einen deutlich niedrigeren Speedup, was 

vermutlich mit den häufigen Lese- und Schreibzugriffen auf den globalen Speicher 

zusammenhängt. Durch Erhöhung der Eigenwerte konvergiert der Speedup der Implementation 

gegen den Speedup der Orthonormalisierung. 

Im Gegensatz zum Soft Clustering wird beim Hard Clustering pro Trainingsvektor nur 

eine Adaption (und somit Orthonormalisierung) durchgeführt. Hierdurch verringert sich 

der Speedup bei steigender Eigenwertanzahl nur gering (Nvidia GTX 570, Abb. 4.5c) 

bzw. steigt sogar (Radeon HD 7970, Abb. 4.5d). 

Verwendetes Potential 

Während das verwendete Potential bei der Berechnung auf der CPU nahezu keinen 

Einfluss auf die Laufzeit hat, konnte durch die Verwendung des in Kapitel 3.2.1 

beschriebenen Potentials ein teilweise deutlicher zusätzlicher Speedup erreicht werden. 

Dies liegt an der Architektur von GPUs, bei der Wurzeloperationen besonders “teuer” 

sind und den Speedup somit verschlechtern. Insbesondere trifft dies auf 64 Bit Wurzeloperationen 

zu, die nicht in Hardware implementiert sind und daher nochmals deutlich 

zeitaufwändiger sind. 

Eine Beschleunigung der Potentialberechnung hat natürlich nur Auswirkungen auf 

die Distanzberechnung. Da die Laufzeit des Soft Clusterings größtenteils von der 

Adaption bestimmt wird (Tabelle 4.5), erzielt das angepasste Potential hier nur eine 

nicht nennenswerte Beschleunigung von unter 1 % (Abb. 4.6). 

Beim Hard Clustering geht die Distanzberechnung mehr in die Gesamtlaufzeit ein, weshalb 

hier ein höherer zusätzlicher Speedup erreicht wird. Auf dem in Abbildung 4.6 benutzten 

CT Datensatz liegt dieser bei etwa 5 %. Bei niedrigdimensionalen Datensätzen 

mit geringer Eigenwertanzahl sind jedoch deutlich höhere Beschleunigungen möglich, 

da hier die Potentialberechnung einen höheren Laufzeitanteil an der Gesamtberechnung 

besitzt. Auf dem Arm Datensatz konnte ein zusätzlicher Speedup von 27 % gemessen 

werden. 


5 Diskussion 

Anzahl der Threads 

Die Anzahl der Threads pro Work-Group steuert den Parallelitätsgrad und hat starke 

Auswirkungen auf die Geschwindigkeit der GPU-Implementierung. Bei niedrigdimensionalen 

Datensätzen und verwendetem Soft Clustering sollte die Anzahl der verwendeten 

Threads nicht deutlich über der Dimension der Trainingsdaten liegen (Abb. 4.3). 

Ansonsten empfiehlt sich aber die Wahl einer eher hohen Threadanzahl (Abb. 4.3 und 

4.4). 

5.2.2 Wahl der Plattform 

Die in Kapitel 4 gezeigten experimentellen Ergebnisse zeigen ein recht unterschiedliches 

Laufzeitverhalten der zwei verwendeten Plattformen, während sich die 

Grafikkarten derselben Plattform häufig nur durch einen bestimmten konstanten Faktor 

im Speedup unterscheiden. 

Dies führt zu der Frage, welche Plattform sich für die GPU-Implementierung des 

NGPCA-Algorithmus am besten eignet. Eine pauschale Antwort lässt sich nicht geben, 

da beide Plattformen ihre Vor- und Nachteile haben. Die theoretischen Leistungsdaten 

(Tabelle 4.1) bescheinigen den AMD Karten einen deutlichen Vorteil bei der Berechnung 

von 64 Bit Fließkommazahlen, die Radeon HD 7970 hat sogar mehr als die 

6-fache Leistung der Nvidia GTX 570. Dennoch erzielen beide Nvidia Karten auf dem 

niedrigdimensionalen Arm Datensatz deutlich bessere Resultate (Abb. 4.1). 

Die Laufzeit der einzelnen Kernel ist auf dem Arm Datensatz aufgrund der niedrigdimensionalen 

Vektoren sehr gering. Folglich ist eine effiziente Verarbeitung der großen 

Menge an Kernelstarts besonders wichtig. Diese Aufgabe erfüllt die Nvidia Plattform 

scheinbar besser. Des Weiteren sind Kontrollstrukturen und Divergenz (Nischwitz 

et al., 2012) besonders für die AMD Plattform problematisch. Dies wird durch den im 

Vergleich zu Nvidia Karten sehr hohen Laufzeitanteil des Ranking-Kernels deutlich 

(Tabelle 4.4), der eine hohe Divergenz und relativ viele Kontrollstrukturen aufweist. Eine 

weitere mögliche Erklärung für das schlechte Laufzeitverhalten der AMD Plattform 

ist eine schlechtere Quellcode-Optimierung, denn gerade bei dem niedrigdimensionalen 

Datensatz lässt sich der Code durch z.B. Loop Unrolling stark optimieren. 

Bei aufwändigeren Berechnungen, z.B. beim Soft Clustering des CT Datensatzes mit 

vielen Eigenwerten (Abb. 4.2a), kann die Radeon HD 7970 ihre hohe 64 Bit Leistung 

nutzen. Hier ist sie der Nvidia GTX 570 deutlich überlegen. Sobald die Komplexität 

der Berechnung allerdings gesenkt wird, z.B. durch Verwendung von Hard Clustering 

(Abb. 4.2b), erreicht die Nvidia GTX 570 wieder den besten Speedup. 

Betrachtet man diese Ergebnisse, so ist die AMD Plattform besonders für rechenintensive 

Anwendungen mit wenigen Kontrollstrukturen und geringer Divergenz geeignet. 

Die Nvidia Architektur ist universell verwendbar, allerdings erreichen die Nvidia Karten 

eine deutlich geringere 64 Bit Leistung. 


6 

Ausblick 

Die im Rahmen dieser Bachelorarbeit entwickelte GPU-Implementierung konnte einen 

deutlichen Geschwindigkeitszuwachs gegenüber der CPU-Referenzimplementierung 

erreichen. Dennoch ergeben sich einige Verbesserungsmöglichkeiten, die in diesem Kapitel 

vorgeschlagen werden. 

6.1 EFORRLSA 

EFORRLSA (Möller, 2002) ist ein Verfahren zur Vereinheitlichung von RRLSA und 

Gram-Schmidt Orthonormalisierung. Für hochdimensionale Trainingsvektoren lässt 

sich so die Geschwindigkeit von RRLSA + Orthonormalisierung theoretisch um den 

Faktor 2 steigern. Zudem würde eine Verschmelzung von Hauptkomponentenanalyse 

und Orthonormalisierung die Zugriffe auf den globalen Speicher verringern, was sich 

ebenfalls positiv auswirkt. 

6.2 AVX, Nvidia Tesla, AMD Plattform 

Die CPU-Implementierung arbeitet noch nicht mit explizit implementierten AVX- 

Befehlen 1 , wodurch eine Geschwindigkeitssteigerung bis zu Faktor 4 erreicht werden 

könnte. Andererseits hätte eine Nvidia Tesla Karte mit einer 64 Bit Leistungsfähigkeit 

von 515 GFLOPs 2 die dreifache Leistung der Nvidia GTX 570. Viel sinnvoller erscheint 

jedoch eine Optimierung speziell für die AMD Plattform. Hierdurch könnte die enorme 

Leistungsfähigkeit der Radeon HD 7970 besser genutzt werden. 

1 http://software.intel.com/en-us/avx 

Datum: 21.09.2012 

2 http://www.nvidia.de/content/PDF/data-sheet/NV_DS_Tesla_C2075_ 

Sept11_US_HR.pdf 

Datum: 23.09.2012 


6 Ausblick 

6.3 Orthonormalisierung 

Beim Soft Clustering nimmt der Speedup mit steigender Eigenwertanzahl ab, was 

durch die verwendete angepasste Gram-Schmidt Orthonormalisierung verursacht wird. 

Durch eine weitere Optimierung dieses Algorithmus könnte der Speedup signifikant 

erhöht werden. Eine andere Möglichkeit wäre der Austausch des Algorithmus durch 

ein besser für die GPU geeignetes Verfahren. 

Das klassische Gram-Schmidtsche Orthonormalisierungsverfahren lässt sich grundsätzlich 

besser parallelisieren als die modifizierte Variante. Zur Verbesserung der numerischen 

Stabilität kann das Verfahren iteriert werden. Dies vervielfacht den Berechnungsaufwand, 

dennoch kann das Verfahren eine höhere Performance als MGS liefern. (Lingen, 

2000). 

6.4 Adaptive Anpassung der parallelen Trainingsvektoren 

Das Hard Clustering würde ebenfalls von einer verbesserten Orthonormalisierung profitieren. 

Es bietet sich jedoch an, die relativ einfache Heuristik zur adaptiven Anpassung 

der parallelen Trainingsvektoren zu erweitern. Durch eine verbesserte Heuristik könnte 

dieser Parameter besser geschätzt werden, was die Auslastung der GPU verbessern bzw. 

unnötige Distanzberechnungen vermeiden würde. 


LITERATURVERZEICHNIS 

Literaturverzeichnis 

Amdahl, G. Limits of expectation. 2(1):88–97, 1988. 

Bishop, C. M. Natural [Neural] networks for pattern recognition. Oxford Univ. Press, 

Oxford [u.a.], 2008. 

Björck, A. Numerics of gram-schmidt orthogonalization. Linear Algebra and its Applications, 

197198(0):297 – 316, 1994. 

Fatahalian, K. und Houston, M. Gpus a closer look. In ACM SIGGRAPH 2008 classes, 

SIGGRAPH ’08, pages 11:1–11:11, New York, NY, USA, 2008. ACM. 

Giraud, L., Langou, J., und Rozloznik, M. The loss of orthogonality in the gram-schmidt 

orthogonalization process. Computers & Mathematics with Applications, 50(7):1069 

– 1075, 2005. 

Hoffmann, H. Unsupervised learning of visuomotor associations. 2004. 

Hoffmann, H., Schenck, W., und Möller, R. Learning visuomotor transformations for 

gaze-control and grasping. Biological Cybernetics, 93:119–130, 2005. 

Hyvärinen, A., Karhunen, J., und Oja, E. Independent component analysis. Wiley, New 

York [u.a.], 2001. 

Jolliffe, I. T. Principal component analysis. Springer, New York [u.a.], 1986. 

Kaiser, A. Implementierung und Test des Twin-Birth-Verfahrens für Neural Gas Principal 

Component Analysis. Diplomarbeit, Technische Fakultät der Universität Bielefeld, 

Bielefeld, 2008. 

Kambhatla, N. und Leen, T. K. 

analysis, 1997. 

Dimension reduction by local principal component 

Lingen, F. J. Efficient gramschmidt orthonormalisation on parallel computers. Communications 

in Numerical Methods in Engineering, 16(1):57–66, 2000. 

Marsaglia, G. Xorshift rngs. Journal of Statistical Software, 08(i14), 2003. 

Martinetz, T., Berkovich, S., und Schulten, K. ‘neural-gas’ network for vector quantization 

and its application to time-series prediction. Neural Networks, IEEE Transactions 

on, 4(4):558 –569, jul 1993. 

Milde, B. und Schneider, M. Parallel implementation of classical Gram-Schmidt orthogonalization 

on CUDA graphics cards. 2009. 


LITERATURVERZEICHNIS 

Möller, R. Interlocking of learning and orthonormalization in RRLSA. Neurocomputing, 

49(1-4):429–433, 2002. 

Möller, R. First-order approximation of Gram-Schmidt orthonormalization beats deflation 

in coupled PCA learning rules. Neurocomputing, 69(13-15):1582–1590, 2006. 

Möller, R. und Hoffmann, H. An extension of neural gas to local pca. Neurocomputing, 

62(0):305 – 326, 2004. 

Möller, R. und Konies, A. Coupled principal component analysis. Neural Networks, 

IEEE Transactions on, 15(1):214 –222, jan. 2004. 

Munshi, A. OpenCL programming guide. Addison-Wesley, Upper Saddle River, NJ 

[u.a.], 2012. 

Murthy, G., Ravishankar, M., Baskaran, M., und Sadayappan, P. Optimal loop unrolling 

for gpgpu programs. In Parallel Distributed Processing (IPDPS), 2010 IEEE 

International Symposium on, pages 1 –11, april 2010. 

Nischwitz, A., Fischer, M., Habercker, P., Socher, G., Nischwitz, A., Fischer, M., Habercker, 

P., und Socher, G. Gpu programmierung mit cuda und opencl. In Computergrafik 

und Bildverarbeitung, pages 481–505. Vieweg+Teubner Verlag, 2012. 

Oh, K.-S. und Jung, K. Gpu implementation of neural networks. Pattern Recognition, 

37(6):1311 – 1314, 2004. 

Ouyang, S., Bao, Z., und Liao, G.-S. Robust recursive least squares learning algorithm 

for principal component analysis. Neural Networks, IEEE Transactions on, 11(1): 

215 –221, jan 2000. 

Rünger, G. und Schwind, M. Comparison of different parallel modified gram-schmidt 

algorithms. In Euro-Par 2005 Parallel Processing, volume 3648 of Lecture Notes in 

Computer Science, pages 622–622. 2005. 

Sanders, J. und Kandrot, E. CUDA by example. Addison-Wesley, Upper Saddle River, 

NJ [u.a.], 2010. 

Sanger, T. D. Optimal unsupervised learning in a single-layer linear feedforward neural 

network. Neural Networks, 2(6):459 – 473, 1989. 

Schenck, W. Adaptive internal models for motor control and visual prediction. MPI 

series in biological cybernetics ; 20. Logos-Verl., 2008. 

Welsch, R. Adaptive Lernratensteuerung für Neural Gas Principal Component Analysis. 

Bachelorarbeit, Technische Fakultät der Universität Bielefeld, 2009. 


A 

Verwendete Parameter 

A.1 Roboterarmsteuerung 

Parameter 

Wert 

Eigenwerte 4 

Iterationen 20.000 

Threadanzahl (Soft Clustering) 64 

Threadanzahl (Hard Clustering) 256 

A.2 CT Slices 

Parameter 

Wert 

Eigenwerte 20 

Iterationen 20.000 

Threadanzahl (Soft Clustering, Nvidia GTX 560 Ti) 256 

Threadanzahl (Soft Clustering, Nvidia GTX 570) 512 

Threadanzahl (Soft Clustering, AMD Radeon HD 6970) 512 

Threadanzahl (Soft Clustering, AMD Radeon HD 7970) 256 

Threadanzahl (Hard Clustering, Nvidia GTX 560 Ti) 512 

Threadanzahl (Hard Clustering, Nvidia GTX 570) 512 

Threadanzahl (Hard Clustering, AMD Radeon HD 6970) 512 

Threadanzahl (Hard Clustering, AMD Radeon HD 7970) 256 


B 

Quelltexte 

OpenCL Pseudozufallszahlengenerator 

1 / ∗ ∗ 

2 ∗ c a l c u l a t e random v a l u e i n [ 0 . . 1 ] 

3 ∗ / 

4 i n l i n e r e a l r a n d x o r s h i f t 3 2 ( g l o b a l u i n t ∗ s t a t e ) { 

5 u i n t x = ∗ s t a t e ; 

6 x ˆ= x > 1 7 ; 

8 x ˆ= x

B 

Quelltexte 

OpenCL Parallel Selection Sort 1 

1 i n l i n e void s o r t ( 

2 c o n s t a n t u i n t ∗ s o r t A r r I d x , 

3 c o n s t a n t r e a l ∗ s o r t A r r V a l , 

4 g l o b a l u i n t ∗ s o r t A r r I d x O u t , 

5 g l o b a l u i n t ∗ h c I d x s ) 

6 { 

7 c o n s t u i n t chunkIdx = g e t g r o u p i d ( 0 ) − 1 ; 

8 

9 # i f PARALLEL HARDCLUSTERING == 1 

10 / / s h i f t t o c u r r e n t chunk 

11 s o r t A r r I d x += PROTOTYPES ∗ chunkIdx ; 

12 s o r t A r r V a l += PROTOTYPES ∗ chunkIdx ; 

13 # e n d i f 

14 

15 f o r ( s i z e t i = g e t l o c a l i d ( 0 ) ; i < PROTOTYPES ; i += 

g e t l o c a l s i z e ( 0 ) ) 

16 { 

17 u i n t i D a t a = s o r t A r r I d x [ i ] ; 

18 r e a l iKey = s o r t A r r V a l [ i ] ; 

19 

20 / / compute u n i t r a n k i n g 

21 i n t rank = 0 ; 

22 f o r ( i n t j =0; j

B 

Quelltexte 

Verwendung der NGPCA-Klasse 

1 # i n c l u d e ”NGPCA.H” 

2 

3 / / . . . 

4 

5 / / params 

6 NGPCAParams params ; 

7 params . p r o t o t y p e s = 2 0 ; 

8 params . o u t p u t D i m e n s i o n = 2 ; 

9 params . l a m b d a I n i t = 1 0 ; 

10 params . o r t h o i n t e r v a l = 1 ; 

11 params . r e s e t c h e c k i n t e r v a l = 1 5 ; 

12 

13 params . p h i = 2 . 0 ; 

14 params . mu = 0 . 0 0 5 ; 

15 params . r h o i n i t = 2 ; 

16 params . r h o f i n a l = 0 . 0 1 ; 

17 params . e p s i l o n i n i t = 0 . 5 ; 

18 params . e p s i l o n f i n a l = 0 . 0 1 ; 

19 params . pcaType = RRLSA; 

20 params . potType = VCONST; 

21 

22 u i n t t h r e a d C o u n t = 512; 

23 bool h a r d C l u s t e r i n g = t r u e ; 

24 u i n t maxChunkSize = 2 0 ; 

25 bool adaptiveMaxChunkSize = t r u e ; 

26 u i n t a d a p t i v e M a x C h u n k S i z e I n t e r v a l = 1 5 ; 

27 u i n t d e v i c e I d = 0 ; 

28 u i n t i t e r a t i o n s = 20000; 

29 

30 

31 / / i n i t 

32 NGPCA ngpca ( params , t h r e a d C o u n t , h a r d C l u s t e r i n g , maxChunkSize 

, adaptiveMaxChunkSize , a d a p t i v e M a x C h u n k S i z e I n t e r v a l , d e v i c e I d ) ; 

33 

34 / / l o a d d a t a 

35 ngpca . l o a d F r o m F i l e ( ” i n p u t . mat ” ) ; 

36 

37 / / l e a r n 

38 ngpca . l e a r n ( i t e r a t i o n s ) ; 

39 

40 / / w r i t e o u t p u t 

41 ngpca . w r i t e ( ” i n p u t . mat . ngpca ” ) ; 

Listing B.3: Verwendung der NGPCA-Klasse 


B 

Quelltexte 

OpenCL Gram-Schmidt Orthonormalisierung 

1 i n l i n e 

2 void o r t h o P a r a l l e l ( 

3 g l o b a l r e a l ∗ w, 

4 g l o b a l r e a l ∗ v , 

5 g l o b a l r e a l ∗ l , 

6 l o c a l r e a l ∗ tempBuffer , / / WORKGROUP SIZE∗WORKGROUP SIZE 

7 l o c a l r e a l ∗ norm , 

8 l o c a l r e a l ∗ buf ) / / VEC SIZE 

9 { 

10 / ∗ ∗ 

11 ∗ Vars 

12 ∗ / 

13 c o n s t u i n t l i n e a r L o c a l I d x = g e t l o c a l i d ( 0 ) + g e t l o c a l i d ( 1 ) ∗ 

g e t l o c a l s i z e ( 0 ) ; 

14 c o n s t s i z e t t h r e a d s = g e t l o c a l s i z e ( 0 ) ∗ g e t l o c a l s i z e ( 1 ) ; 

15 

16 / ∗ ∗ 

17 ∗ O r t h o n o r m a l i z e W 

18 ∗ / 

19 { 

20 / ∗ ∗ 

21 ∗ n o r m a l i z e f i r s t column 

22 ∗ / 

23 { 

24 / / quadr 

25 t e m p B u f f e r [ l i n e a r L o c a l I d x ] = 0 ; 

26 f o r ( s i z e t yIdx = l i n e a r L o c a l I d x ; yIdx < VEC SIZE ; yIdx += 

t h r e a d s ) { 

27 r e a l v a l = w[ yIdx ∗OUT DIM ] ; 

28 

29 buf [ yIdx ] = v a l ; 

30 

31 t e m p B u f f e r [ l i n e a r L o c a l I d x ] += v a l ∗ v a l ; 

32 } 

33 b a r r i e r (CLK LOCAL MEM FENCE) ; 

34 

35 / / r e d u c e quadr p e r t h r e a d 

36 s i z e t r e d u c t i o n I d x = t h r e a d s / 2 ; 

37 w h i l e ( r e d u c t i o n I d x != 0) { 

38 i f ( l i n e a r L o c a l I d x < r e d u c t i o n I d x ) { 

39 t e m p B u f f e r [ l i n e a r L o c a l I d x ] += t e m p B u f f e r [ l i n e a r L o c a l I d x + 

r e d u c t i o n I d x ] ; 

40 } 

41 


43 r e d u c t i o n I d x = r e d u c t i o n I d x / 2 ; 

44 } 

45 

46 / / c a l c u l a t e norm 

47 i f ( l i n e a r L o c a l I d x == 0) { 

48 ∗norm = SQRT( t e m p B u f f e r [ 0 ] ) ; 

49 } 


51 

52 / / n o r m a l i z e and s t o r e 

53 r e a l f i r s t L = l [ 0 ] ; 


B 

Quelltexte 


t h r e a d s ) { 

55 r e a l n o r m a l i z e d = buf [ yIdx ] / (∗ norm ) ; 

56 

57 / / s t o r e r e s u l t 

58 w[ yIdx ∗OUT DIM] = n o r m a l i z e d ; 

59 v [ yIdx ∗OUT DIM] = n o r m a l i z e d ∗ f i r s t L ; 

60 

61 / / keep r e s u l t i n l o c a l memory 

62 buf [ yIdx ] = n o r m a l i z e d ; 

63 } 

64 } 

65 

66 / ∗ ∗ 

67 ∗ c a l c u l a t e s c a l a r p r o d u c t s 

68 ∗ / 

69 f o r ( s i z e t c o l = 1 ; c o l < OUT DIM ; c o l ++) { 


71 

72 s i z e t o f f s e t = c o l ; 

73 s i z e t xIdx = c o l + g e t l o c a l i d ( 0 ) ; 

74 

75 w h i l e ( o f f s e t < OUT DIM) { 

76 / / i n i t 


78 

79 i f ( xIdx < OUT DIM) { 

80 / / sum up 

81 f o r ( s i z e t yIdx = g e t l o c a l i d ( 1 ) ; yIdx < VEC SIZE ; yIdx += 

g e t l o c a l s i z e ( 1 ) ) { 

82 t e m p B u f f e r [ l i n e a r L o c a l I d x ] += w[ xIdx + yIdx ∗OUT DIM] ∗ 

buf [ yIdx ] ; 

83 } 

84 } 


86 

87 / / r e d u c e 


89 w h i l e ( r e d u c t i o n I d x >= g e t l o c a l s i z e ( 0 ) ) { 




92 } 

93 



96 } 

97 

98 / / t e m p B u f f e r c o n t a i n s s c a l a r p r o d u c t s i n f i r s t 

WORKGROUP SIZE e l e m e n t s 

99 

100 / / s u b t r a c t 

101 i f ( xIdx < OUT DIM) { 

102 f o r ( s i z e t yIdx = g e t l o c a l i d ( 1 ) ; yIdx < VEC SIZE ; yIdx += 

g e t l o c a l s i z e ( 1 ) ) { 

103 w[ xIdx + yIdx ∗OUT DIM] −= t e m p B u f f e r [ g e t l o c a l i d ( 0 ) ] ∗ 

buf [ yIdx ] ; 

104 } 


B 

Quelltexte 

105 } 

106 

107 o f f s e t += g e t l o c a l s i z e ( 0 ) ; 

108 xIdx += g e t l o c a l s i z e ( 0 ) ; 

109 } 

110 b a r r i e r (CLK GLOBAL MEM FENCE) ; 

111 

112 / ∗ ∗ 

113 ∗ c a l c u l a t e r e s u l t i n g column 

114 ∗ / 

115 / / quadr 



t h r e a d s ) { 

118 r e a l v a l = w[ c o l + yIdx ∗OUT DIM ] ; 

119 

120 buf [ yIdx ] = v a l ; 

121 

122 t e m p B u f f e r [ l i n e a r L o c a l I d x ] += v a l ∗ v a l ; 

123 } 


125 

126 / / r e d u c e quadr p e r t h r e a d 


128 w h i l e ( r e d u c t i o n I d x != 0) { 




131 } 

132 



135 } 

136 

137 / / c a l c u l a t e norm 

138 i f ( l i n e a r L o c a l I d x == 0) { 

139 ∗norm = SQRT( t e m p B u f f e r [ 0 ] ) ; 

140 } 


142 

143 / / n o r m a l i z e & s t o r e 

144 r e a l c u r r L = l [ c o l ] ; 


t h r e a d s ) { 

146 r e a l n o r m a l i z e d = w[ c o l + yIdx ∗OUT DIM] / (∗ norm ) ; 

147 

148 / / s t o r e r e s u l t 

149 w[ c o l + yIdx ∗OUT DIM] = n o r m a l i z e d ; 

150 v [ c o l + yIdx ∗OUT DIM] = n o r m a l i z e d ∗ c u r r L ; 

151 

152 / / keep r e s u l t i n l o c a l memory 

153 buf [ yIdx ] = n o r m a l i z e d ; 

154 } 

155 } 

156 } 

157 } 

Listing B.4: OpenCL Gram-Schmidt Orthonormalisierung 


C 

Kompilierung und Ausführung der 

Quelltexte 

Kompilierung 

Die Kompilierung in der PROG4 Umgebung kann einfach mittels vmk gestartet werden. 

Soll das Projekt separat übersetzt werden, so kann dies mit Hilfe von CMake geschehen: 

cmake . && make 

Ausführung 

Das Trainieren eines NGPCA-Netzwerkes mit 100 Prototypen, 20.000 Iterationszyklen 

und einer Ausgabedimension von 4 kann z.B. mit folgendem Kommando gestartet werden 

1 : 

gpu_ngpca \ 

-d 4 -p 100 -i 20000 \ 

train INPUT_FILE 

Bitte beachten Sie, dass die Angabe dieser Parameter obligatorisch ist, während weitere 

Parameter (siehe Anhang E) optional sind. 

1 Wobei INPUT FILE ein Platzhalter für den Pfad zur Eingabematrix ist 


D 

Verwendete Software-Bibliotheken 

Für die Umsetzung der vorliegenden Bachelorarbeit wurden folgende Software- 

Bibliotheken benutzt: 

• OpenCL 1.1 - GPGPU Schnittstelle 

http://www.khronos.org/opencl/ 

• OpenCL C++ Bindings 1.1 - C++ Wrapper für OpenCL 

http://www.khronos.org/registry/cl/specs/ 

opencl-cplusplus-1.1.pdf 

• Matrix 4-6-WS1 - Matrix Bibliothek 

˜/PROG4/libraries/Matrix-4-6-WS1 

• Boost Program Options 1.46.1 - Parser für Kommandozeilenargumente 

http://www.boost.org/doc/libs/1_46_1/doc/html/program_ 

options.html 

• CMake - Build System (optional) 

http://www.cmake.org 


E 

Kommandozeilenparameter 

Die Applikation kann mittels gpu_ngpca [command] {options} gestartet werden, 

wobei die möglichen Kommandos und Optionen im Folgenden erläutert werden. 

Kommandos 

Befehl 

list-platforms 

list-devices 

train [inputFile] 

Wirkung 

Zeigt alle verfügbaren OpenCL-Plattformen an 

Zeigt alle verfügbaren OpenCL-Geräte an 

Trainiert ein NGPCA-Netzwerk 

Generelle Optionen 

Befehl 

Vorgabewert 

--help 

Zeigt die Hilfe an 

--device 

Auswahl des OpenCL Gerätes 0 

--doublePrecision 

Soll mit doppelter Genauigkeit gerechnet werden? 

1 (Ja) 

--threadCount 

Maximale Anzahl der parallelen Ausführungsstränge 512 

--maxChunkSize 

Maximale Anzahl an parallelen harten Vektorquantisierungen 20 

--adaptiveMaxChunkSize 

Soll die Anzahl an parallelen harten Vektorquantisierungen automatisch 

angepasst werden? 

1 (Ja) 

--adaptiveMaxChunkSizeInterval 

In welchem Intervall soll die automatische Anpassung durchgeführt 20 

werden? 


E 

Kommandozeilenparameter 

NGPCA Optionen 

Befehl 

Vorgabewert 

-i [ --iterations ] 

Anzahl der Iterationszyklen 

-p [ --prototypes ] 

Anzahl der zu verwendenden Prototypen 

-d [ --outputDimensions ] 

Ausgabedimension 

--lambdaInit 

Initiales Lambda 10 

--orthoInterval 

Intervall, in dem die Orthonormalisierung durchgeführt werden 1 

soll 

--resetCheckInterval 

Intervall, in dem die Prototypen überprüft und ggf. zurückgesetzt 15 

werden 

--phi 

Phi 2 

--rhoInit 

Rho (Anfangswert) 2 

--rhoFinal 

Rho (Endwert) 0.01 

--epsilonInit 

Epsilon (Anfangswert) 0.5 

--epsilonFinal 

Epsilon (Endwert) 0.001 

--hardClustering 

Soll harte Vektorquantisierung verwendet werden? 

1 (Ja) 

--pcaType 

Art der lokalen PCA (1 = RRLSA,2 = CouplePCA) 

1 (RRLSA) 

--potType 

Art der Potentialberechnung (1 = VConst,2 = TracePotential) 2 (TracePotential) 


Hiermit versichere ich, dass ich diese Bachelorarbeit selbständig bearbeitet habe. 

Ich habe keine anderen als die angegebenen Quellen und Hilfsmittel benutzt und 

entsprechende Zitate kenntlich gemacht. 

Bielefeld, den 26. September 2012 

Christian Menßen

GPU-Implementation von “Neural Gas Principal Component Analysis”

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?