Parallelisierung des Growing Cells Meshing Algorithmus

Parallelisierung des Growing Cells Meshing
Algorithmus

Marcus Riemer, Florian Held

Fachhochschule Wedel
University of Applied Sciences Wedel

WS 2011

Parallelisierung des Smart Growing Cells Algorithmus

Notwendige Kenntnisse
Programmierung & Elementare Datenstrukturen
Vorlesungen
Programmstrukturen 2 ausreichend
Algorithmen und Datenstrukturen in C optimal
Inhaltlich
B¨ume, Listen und Dynamische Arrays
a

Hilfreiche Kenntnisse
Grundlagen Threadprogrammierung
Vorlesung Prozessprogrammierung
Inhaltlich
Elementare Probleme (Erzeuger-Verbraucher, Leser-Schreiber)
Thread, Mutex, Lock

Gliederung

Einf¨hrung
u

Surface Reconstruction
Allgemein
Smart Growing Cells

Parallelisierung
Bedingungen
1. Ansatz: Bottom Up
2. Ansatz: Erzeuger-Verbraucher
Parallele Datenstrukturen
Gegen¨berstellung
u

Ergebnis


Reales Objekt ⇒ Punktwolke ⇒ Mesh

Surface Reconstruction - Dimensionen


Etwa 9.826.000 Punkte als Eingabe


Etwa 4.000.000 Dreiecke im Ergebnismesh


132 Minuten bei 2,6 Ghz und 8 Gb RAM


132 Minuten bei 2,6 Ghz und 8 Gb RAM
Eines der eher kleineren Modelel, die zu verarbeiten sind ...

Surface Reconstruction - Probleme

M¨glichkeiten der Verkn¨pfung
o u


Zu analysierende Punktwolke

Smart Growing Cells Algorithmus

Ausgangssituation

Smart Growing Cells Algorithmus

Gebildetes Neuronales Netz

Smart Growing Cells Algorithmus - Schritte

(a) Move / Gl¨tten
a


(a) Move / Gl¨tten
a

(b) Split


(a) Move / Gl¨tten
a

(b) Split

(c) Collapse

Smart Growing Cells Algorithmus - Ablauf

Ablauf einer Rekonstruktion

Parallelisierung

Eignung des Verfahrens f¨r die Parallelisierung
u
Robust gegen¨ber Ver¨nderungen der Reihenfolge und
u a
Verteilung der Operationen

Parallelisierung

u
u a
Gr¨ße des Meshes ∼ Anzahl m¨glicher Threads
o o

Parallelisierung

u
u a
Gr¨ße des Meshes ∼ Anzahl m¨glicher Threads
o o
Theorie: Standardprozess einfach mehrfach ausf¨hren
u

Parallelisierung

Eignung der Implementierung f¨r die Parallelisierung
u

Parallelisierung

u
Hochgradig optimiert

Parallelisierung

u
Nutzung von vorreserviertem Speicher

Parallelisierung

u
Eigene grundlegende Datenstrukturen

Parallelisierung

u
Eigene grundlegende Datenstrukturen

Mes h

Pool

Octree S ignalCounterTree Faces
Vertices
Edges

PooledLis t

Pool

Pool

Der Pool
ist ein vorreservierter Speicherbereich in Form eines Arrays

Pool

Der Pool
... dessen Gr¨ße zu Anfang bekannt sein muss
o

Pool

Der Pool
o
... sich jedoch ggf. noch vergr¨ßern l¨sst.
o a

Pool

Der Pool
o
o a
stellt einen einfache aber schnelle Speicherverwaltung dar

Pool

Der Pool
o
o a
stellt einen einfache aber schnelle Speicherverwaltung dar
ersetzt Aufrufe von new und delete

Pool als Speicherwaltung

Statt:
Foo * c r e a t e F o o ( ) {
return new Foo();
}

void d e l e t e F o o ( Foo * f o o ) {
delete foo;
}

Pool als Speicherwaltung

Statt:
Foo * c r e a t e F o o ( ) {
return new Foo();
}

void d e l e t e F o o ( Foo * f o o ) {
delete foo;
}

... haben wir:
Foo * c r e a t e F o o ( Pool< Foo > * p o o l ) {
return pool-¿newValue();
}

void d e l e t e F o o ( Pool< Foo > * p o o l , Foo * f o o ) {
pool-¿deleteValue( foo );
}

PooledList

Die PooledList
ist eine Listenimplementierung auf Basis des Pools

PooledList

Die PooledList
...mit konstanter Zugriﬀszeit auf die Elemente.

PooledList

Die PooledList
...mit konstanter Zugriﬀszeit auf die Elemente.

Implementierungsdetail: Pool und PooledList werden sowohl f¨ru
die Speicherverwaltung als auch als Datenstruktur verwendet.

Octree

Zur Erinnerung: Move-Schritt ben¨tigt Bezugspunkt
o

Octree

o
Problem: Finde den n¨chstgelegenen Nachbarn zu einem
a
gegebenen Punkt p

Octree

o
a
gegebenen Punkt p
L¨sung mit r¨umlicher Datenstruktur:
o a
1. Unterteile den Raum an den x-, y - und z-Achsen in 8
Unterr¨ume
a

Octree

o
a
gegebenen Punkt p
L¨sung mit rümlicher Datenstruktur:
o a
1. Unterteile den Raum an den x-, y - und z-Achsen in 8
Unterrüme
a
2. Befinden sich in einem Unterraum u mehr als k Punkte, so
wiederhole 1. f¨r u
u

Octree

Ergebnis: Eﬃziente Suche des n¨chsten Nachbarn in einer
a
globalen Datenstruktur

SignalCounterTree

Zur Erinnerung: Split-Schritt ben¨tigt Gewinner
o

SignalCounterTree

o
Move-Schritt erh¨ht “Signalz¨hler” des Vertex’
o a

SignalCounterTree

o
o a
Vertex mit h¨chstem Signalz¨hler ist Gewinner
o a

SignalCounterTree

o
o a
Vertex mit h¨chstem Signalz¨hler ist Gewinner
o a

Verwaltung der Signalz¨hler in Form des SignalCounterTrees
a
implementiert:
Rot-Schwarz-Baum
globale Datenstruktur

Zusammenfassung der vorhandenen Datenstrukturen

Octree ist global


Octree ist global
SCTree (SignalCounterTree) ist global


Octree ist global
Pool und PooledList werden als Datenstruktur verwendet
→ potentiell global


Octree ist global
Pool und PooledList werden als Datenstruktur verwendet
→ potentiell global

Parallelisierung des Verfahrens = Parallelisierung der
Implementierung

Parallelisierung - Bottom Up

Grundlegende Idee
Sperren aller grundlegenden Datenstrukturen
Keine Anpassung des Algorithmus
→ Parallelisierung ”abschaltbar”

Mes h

Pool

Octree S ignalCounterTree Faces
Vertices
Edges

PooledLis t

Pool


Grundlegender Ansatz:
Lesende Zugriﬀe parallel zulassen
Schreibende Zugriﬀe exklusiv ausf¨hren
u


u

→ Typisches Leser-Schreiber Problem


u

→ Typisches Leser-Schreiber Problem

L¨sung mit Boost.Thread
o
SharedLockable modelliert geteilten und exklusiven Zugriﬀ
Sicherer: Sperrobjekte benutzen


class T h r e a d s a f e
{
public :
int h a s I n d e x ( int i n d e x ) {
SharedLock lock( mMutex );
return ( mValueCount <= i n d e x ) ;
}

int s e t V a l u e S a f e ( int i n d e x , int v a l u e ) {
ExclusiveLock lock( mMutex );
if ( h a s I n d e x ( i n d e x ) ) {
mValues [ i n d e x ] = v a l u e ;
return ( true )
}

return ( false ) ;
}
};

Parallelisierung - Bottom Up - Problemfall Rekursion

class T h r e a d s a f e
{
public :
int h a s I n d e x ( int i n d e x ) {
SharedLock lock( mMutex );
return ( h a s I n d e x I m p l ( i n d e x ) ) ;
}

int s e t V a l u e S a f e ( int i n d e x , int v a l u e ) {
ExclusiveLock lock( mMutex );
return ( s e t V a l u e S a f e I m p l ( i n d e x , v a l u e ) ) ;
}

private :
int h a s I n d e x I m p l ( int i n d e x ) {
return ( mValueCount <= i n d e x ) ;
}
int s e t V a l u e S a f e I m p l ( int i n d e x , int v a l u e ) {
/* U s e s h a s I n d e x I m p l ( ) i n i m p l e m e n t a t i o n */
}
};


public uint indexOf(Val*)

private uint indexOfImpl(Val*)
public void resizeFastArray(uint)
private uint deletionsToAddress(uint) private uint biggerDeletionIndex(uint, uint, uint)

private void resizeFastArrayImpl(uint)
public void increaseFastArray(float) private void increaseFastArrayImpl(float)
private Val* getValImpl(const uint) private uint deletionsToIndex(uint) private void sortDeleted()

public Val* getVal(const uint)

private Val* getNewValImpl()
public Val* getNewVal()

Usercode public void delVal(Val*) private void delValImpl(Val*) private void increaseDeletedStack() private void resizeDeletedStack(uint)

public void freeArray()
private void freeArrayImpl()
public void initFastArray(uint)
private void initFastArrayImpl(uint, uint, bool)

public void initFastArray(uint, uint)

public bool isDeleted(Val*)
isDeletedImpl
public bool isValid(Val*) private bool isValidImpl(Val*)


public uint indexOf(Val*)

private uint indexOfImpl(Val*)
public void resizeFastArray(uint)
private uint deletionsToAddress(uint) private uint biggerDeletionIndex(uint, uint, uint)

private void resizeFastArrayImpl(uint)
public void increaseFastArray(float) private void increaseFastArrayImpl(float)
private Val* getValImpl(const uint) private uint deletionsToIndex(uint) private void sortDeleted()

public Val* getVal(const uint)

private Val* getNewValImpl()
public Val* getNewVal()

Usercode public void delVal(Val*) private void delValImpl(Val*) private void increaseDeletedStack() private void resizeDeletedStack(uint)

public void freeArray()
private void freeArrayImpl()
public void initFastArray(uint)
private void initFastArrayImpl(uint, uint, bool)

public void initFastArray(uint, uint)

public bool isDeleted(Val*)
isDeletedImpl
public bool isValid(Val*) private bool isValidImpl(Val*)

getNearestPoint

addPt reinsert getNearestXPoints

initialAddPt addPtCore getNearestXPointsCore

initialAddPtCore minimisationCascadeAlternativ getAverageDepth constructor getPointsInQRadius removeVec checkNode

addPtToNode correctBox createNode notMoreThenXChildren removeVecCore getPointsInQRadiusCore getAverageListLength getCenter getEdgeBoxSize deletePotentialEmptyNodes getNumOfNodes ptInBox getNumOfPts freePointsInRadiusList freeXPointsList getListForNearestPointsSearch resizeInRadiusSList addToList

NodeWriter NodeReader Reader Writer ListReader ListWriter

Parallelisierung - Bottom Up - Problemefall Rekursion

Erster Ansatz:
¨
Oﬀentliche Methoden setzen eine Sperre und delegieren die
eigentliche Arbeit an eine private Methode
Private Methoden rufen niemals ¨ﬀentliche Methoden auf
o


Erster Ansatz:
¨
o
¨
→ Umfangreiche Anderungen am Code


Erster Ansatz:
¨
o
¨
→ Inkonsistente Zust¨nde durch zu kurze Sperren
a


Erster Ansatz:
¨
o
¨
a

Zweiter Ansatz:
Rekursive Mutexe verwenden


Erster Ansatz:
¨
o
¨
a

Zweiter Ansatz:
→ Noch langsamer


Erster Ansatz:
¨
o
¨
a

Zweiter Ansatz:
→ Noch langsamer
a

Parallelisierung - Bottom Up - Probleme allgemein

Hüfiges Sperren und Entsperren von Mutexen
a
Effektives Sperren balancierter Büme ein offenes Problem
a


a
a

→ Lock auch langsam wenn keine Kollisionen auftreten


a
a

→ Lock auch langsam wenn keine Kollisionen auftreten
→ Kein Verhindern unerwarteter destruktiver Operationen

Parallelisierung - Erzeuger-Verbraucher

Problem: Versucht Parallelismus implizit zu nutzen



L¨sung: M¨glichkeiten des SGC Algorithmus ausnutzen
o o
”Sperrbereiche” in denen ein Thread exklusiv arbeitet
→ Potenziell sehr viel weniger Sperrvorg¨nge n¨tig
a o



o o
a o

Grundlegende Idee
Einen Thread f¨r Verwaltungsaufgaben
u
n weitere Threads f¨r die ”eigentliche Arbeit”
u



o o
a o

Grundlegende Idee
Einen Thread f¨r Verwaltungsaufgaben
u
n weitere Threads f¨r die ”eigentliche Arbeit”
u

→ Klassisches Erzeuger-Verbraucher Problem

Parallelisierung - Worker, Jobs und WorkerManager

WorkerManager
Boos t::Thread
+ getNextAvailableJob() : Job

S patialLocker Worker
+ lock( vec3d pos , ﬂoat radius ) : bool
+ unlock( vec3d pos ) : bool + execute() : void

Job
WorkingS et
+ is S tatic() : bool

Parallelisierung - getNextAvailableJob()

Grundidee: WorkerManager-Thread erzeugt Jobs auf ”Vorrat”
→ getNextAvailableJob() nur noch eine pop Operation

Pop Move Move Split Move Move Move Split Collapse ... Push




Erzeugte Jobs sperren Bereich bis zu ihrer Finalisierung
→ Wahrscheinlichkeit der erfolgreichen Joberstellung sinkt




Erzeugte Jobs sperren Bereich bis zu ihrer Finalisierung
→ Wahrscheinlichkeit der erfolgreichen Joberstellung sinkt

Optimierung f¨r kleine Meshes notwendig
u
→ Nur ein Thread
→ Erstellt Jobs ”On Demand”

Parallelisierung - Auswahl der Strategie

Umschaltung auf “große” Strategie erfolgt zu sp¨t
a
M¨glichkeit der Parallelit¨t wird nicht ausgenutzt
o a

Parallelisierung - Auswahl der Strategie

Umschaltung auf “große” Strategie erfolgt zu sp¨t
a
M¨glichkeit der Parallelit¨t wird nicht ausgenutzt
o a

Umschaltung auf “große” Strategie erfolgt zu fr¨h
u
Es ist gar kein Platz f¨r mehrere Threads
u
→ Overhead durch r¨umliche Sperrungen
a


Erkenntnis: Vorhandene globale Datenstrukturen ungeeignet
f¨r Parallelisierung
u


Erkenntnis: Vorhandene globale Datenstrukturen ungeeignet
f¨r Parallelisierung
u
Aufgabe: Implementierung neuer Datenstrukturen f¨r
u
Pool und PooledList
Octree
SCTree

Paralleler Octree

Idee: Einf¨hrung einer Ebene, auf der gelockt wird
u

Paralleler Octree

u
oberhalb der Ebene sind generell nur lesende Zugriﬀe erlaubt

Paralleler Octree

u
oberhalb der Ebene sind generell nur lesende Zugriﬀe erlaubt
unterhalb der Ebene darf sich in jedem Unterbaum nur ein
Thread beﬁnden

Aus SCTree wird SCMap

Zur Erinnerung: SCTree ist ein RBTree (→ balanciert!)


Notwendigkeit: komplett neue Datenstruktur


Wir wissen: Gr¨ßtes Element wird am h¨uﬁgsten gesucht
o a


o a
Außerdem haben Beobachtungen ergeben:


o a
Es gibt obere und untere Schranken f¨r Signale
u


o a
Es gibt obere und untere Schranken f¨r Signale
u
Signale sind ann¨hernd normalverteilt
a


Implementierung als geordnete Hashtabelle:
Hashfunktion ist Normalverteilungsapproximation


Lage des gr¨ßten Elements kann g¨nstig mitgespeichert
o u
werden (→ echte konstante Zugriﬀszeit)


o u
Anzahl der Buckets frei w¨hlbar
a


o u
Anzahl der Buckets frei w¨hlbar
a
Durchschnittliche Gr¨ße der Buckets frei w¨hlbar
o a
→ sehr ﬂexibel

Parallelisierung - SpatialLocker

Veranschaulichung der Sperrbereiche:


Aufgaben des SpatialLockers:


Verwaltung aller gesperrten Bereiche


Pr¨ft, ob in einem Bereich gearbeitet werden darf
u


u

Allgemeine Problematik ist die Gr¨ße des Sperrbereichs:
o


u

o
Bei zu großen Sperrbereichen: Ablehnung neuer Jobs (→
Programmstillstand)


u

o
Programmstillstand)
¨
Bei zu kleinen Sperrbereichen: Unerwartete Uberschneidungen
(→ Programmabsturz)


u

o
Programmstillstand)
¨
Bei zu kleinen Sperrbereichen: Unerwartete Uberschneidungen
(→ Programmabsturz)

Ist der Sperrbereich gut gew¨hlt, so treten keine unerwarteten
a
¨
Uberschneidungen auf
→ parallelen Zugriﬀe auf das selbe Pool-/PooledList-Objekt
sind ausgeschlossen

Parallelisierung - Gegen¨berstellung
u

Parallelisierung im Straßenverkehr

u

Parallelisierung im Straßenverkehr - Bottom Up

u

Parallelisierung im Straßenverkehr - Sperrbereiche

Ergebnis - Zeitgewinn

Ausf¨hrungszeit = 50% SmallMeshStrategy + 50%
u
LargeMeshStrategy

Ergebnis - Zeitgewinn

Ausf¨hrungszeit = 50% SmallMeshStrategy + 50%
u
LargeMeshStrategy
10% Zeitgewinn mit jedem zus¨tzlichen Kern
a

Ergebnis - Parametrisierung

Parameter signiﬁkant



Vermeidung von gesperrten Mutexen



Vermeidung von gesperrten Mutexen nein




Sperrebene beim Octree




Sperrebene beim Octree nein





Bucketgr¨ße der SCMap
o





o nein





o nein

Max. Anzahl an vorerstellten Jobs





o nein

Max. Anzahl an vorerstellten Jobs nein





o nein


Zeitpunkt der Umstellung auf Large-Mesh-Strategy





o nein


Zeitpunkt der Umstellung auf Large-Mesh-Strategy ja





o nein



Anteil verworfene Jobs





o nein



Anteil verworfene Jobs ja

Ergebnis - Fazit

Implizite Parallelisierung geht mit C++ nicht
→ funktionale Programmiersprachen sind hier eindeutig
vorteilhaft

Ergebnis - Fazit

vorteilhaft
Nebenl¨uﬁge Anwendungen ben¨tigen saubere Struktur
a o
→ neben Geschwindigkeit auch Strukturierung

Ergebnis - Fazit

vorteilhaft
Nebenl¨uﬁge Anwendungen ben¨tigen saubere Struktur
a o
→ neben Geschwindigkeit auch Strukturierung
Parallelisierung sollte von Beginn an Teil des Softwaredesigns
sein

Ergebnis - Fazit

Bei Datenstrukturen gilt:

Ergebnis - Fazit

Probabilistische Datenstrukturen sind vorteilhaft
→ z.B. Hashmaps oder Skiplisten anstelle von balancierten
B¨umen
a

Ergebnis - Fazit

B¨umen
a
Modell und Implementierung k¨nnen stark voneinander
o
abweichen

Ergebnis - Fazit

B¨umen
a
Modell und Implementierung k¨nnen stark voneinander
o
abweichen
Dar¨berhinaus sollte die Ebene des Locks frei w¨hlbar sein
u a

Ergebnis - Oﬀene Fragen

Optimale Parametrisierung noch unbekannt

Ergebnis - Oﬀene Fragen

Optimale Parametrisierung noch unbekannt
Eﬀektive Strategie zur Joberstellung noch nicht gefunden
→ Jobs werden erstellt und teilweise direkt wieder verworfen

Parallelisierung des Growing Cells Meshing Algorithmus

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (19)

Parallelisierung des Growing Cells Meshing Algorithmus