parallelisierung des growing cells meshing algorithmus

Parallelisierung des Growing Cells MeshingAlgorithmus

Marcus Riemer, Florian Held

Fachhochschule WedelUniversity of Applied Sciences Wedel

WS 2011

Parallelisierung des Smart Growing Cells Algorithmus

Notwendige KenntnisseI Programmierung & Elementare Datenstrukturen

I VorlesungenI Programmstrukturen 2 ausreichendI Algorithmen und Datenstrukturen in C optimal

I InhaltlichI Baume, Listen und Dynamische Arrays

Hilfreiche KenntnisseI Grundlagen Threadprogrammierung

I Vorlesung ProzessprogrammierungI Inhaltlich

I Elementare Probleme (Erzeuger-Verbraucher, Leser-Schreiber)I Thread, Mutex, Lock

Gliederung

Einfuhrung

Surface ReconstructionAllgemeinSmart Growing Cells

ParallelisierungBedingungen1. Ansatz: Bottom Up2. Ansatz: Erzeuger-VerbraucherParallele DatenstrukturenGegenuberstellung

Ergebnis

Surface Reconstruction

Reales Objekt ⇒ Punktwolke ⇒ Mesh

Surface Reconstruction - Dimensionen

I Etwa 9.826.000 Punkte als EingabeI Etwa 4.000.000 Dreiecke im ErgebnismeshI 132 Minuten bei 2,6 Ghz und 8 Gb RAM

Eines der eher kleineren Modelel, die zu verarbeiten sind ...

I Etwa 9.826.000 Punkte als Eingabe

I Etwa 4.000.000 Dreiecke im Ergebnismesh

I 132 Minuten bei 2,6 Ghz und 8 Gb RAM

Gliederung

Einfuhrung

Ergebnis

Surface Reconstruction - Probleme

Moglichkeiten der Verknupfung

Surface Reconstruction

Zu analysierende Punktwolke

Smart Growing Cells Algorithmus

Ausgangssituation

Smart Growing Cells Algorithmus

Gebildetes Neuronales Netz

Smart Growing Cells Algorithmus - Schritte

(a) Move / Glatten

(b) Split

(c) Collapse

(a) Move / Glatten

(b) Split

(c) Collapse

(a) Move / Glatten

(b) Split

(c) Collapse

Smart Growing Cells Algorithmus - Ablauf

Ablauf einer Rekonstruktion

Gliederung

Einfuhrung

Ergebnis

Parallelisierung

Eignung des Verfahrens fur die ParallelisierungI Robust gegenuber Veranderungen der Reihenfolge und

Verteilung der Operationen

I Große des Meshes ∼ Anzahl moglicher Threads

Theorie: Standardprozess einfach mehrfach ausfuhren

Parallelisierung

Verteilung der OperationenI Große des Meshes ∼ Anzahl moglicher Threads

Parallelisierung

Eignung der Implementierung fur die Parallelisierung

I Hochgradig optimiertI Nutzung von vorreserviertem SpeicherI Eigene grundlegende Datenstrukturen

Octree

PooledLis t

SignalCounterTree

FacesVerticesEdges

Parallelisierung

Eignung der Implementierung fur die ParallelisierungI Hochgradig optimiert

I Nutzung von vorreserviertem SpeicherI Eigene grundlegende Datenstrukturen

Octree

PooledLis t

SignalCounterTree

FacesVerticesEdges

Parallelisierung

Eignung der Implementierung fur die ParallelisierungI Hochgradig optimiertI Nutzung von vorreserviertem Speicher

I Eigene grundlegende Datenstrukturen

Octree

PooledLis t

SignalCounterTree

FacesVerticesEdges

Parallelisierung

Eignung der Implementierung fur die ParallelisierungI Hochgradig optimiertI Nutzung von vorreserviertem SpeicherI Eigene grundlegende Datenstrukturen

Octree

PooledLis t

SignalCounterTree

FacesVerticesEdges

Parallelisierung

Eignung der Implementierung fur die ParallelisierungI Hochgradig optimiertI Nutzung von vorreserviertem SpeicherI Eigene grundlegende Datenstrukturen

Octree

PooledLis t

SignalCounterTree

FacesVerticesEdges

Der Pool

I ist ein vorreservierter Speicherbereich in Form eines Arrays

I ... dessen Große zu Anfang bekannt sein muss

I ... sich jedoch ggf. noch vergroßern lasst.

I stellt einen einfache aber schnelle Speicherverwaltung dar

I ersetzt Aufrufe von new und delete

Der Pool

Pool als Speicherwaltung

Statt:

Foo* c r ea t eFoo ( ) {return new Foo();

void de l e t eFoo ( Foo* f oo ) {delete foo;

... haben wir:

Foo* c r ea t eFoo ( Pool< Foo > * poo l ) {return pool-¿newValue();

void de l e t eFoo ( Pool< Foo > * pool , Foo* f oo ) {pool-¿deleteValue( foo );

Pool als Speicherwaltung

Statt:

Foo* c r ea t eFoo ( ) {return new Foo();

void de l e t eFoo ( Foo* f oo ) {delete foo;

... haben wir:

Foo* c r ea t eFoo ( Pool< Foo > * poo l ) {return pool-¿newValue();

void de l e t eFoo ( Pool< Foo > * pool , Foo* f oo ) {pool-¿deleteValue( foo );

PooledList

Die PooledList

I ist eine Listenimplementierung auf Basis des Pools

I ...mit konstanter Zugriffszeit auf die Elemente.

Implementierungsdetail: Pool und PooledList werden sowohl furdie Speicherverwaltung als auch als Datenstruktur verwendet.

PooledList

Die PooledList

PooledList

Die PooledList

Octree

I Zur Erinnerung: Move-Schritt benotigt Bezugspunkt

I Problem: Finde den nachstgelegenen Nachbarn zu einemgegebenen Punkt p

I Losung mit raumlicher Datenstruktur:1. Unterteile den Raum an den x-, y - und z-Achsen in 8

Unterraume2. Befinden sich in einem Unterraum u mehr als k Punkte, so

wiederhole 1. fur u

Octree

wiederhole 1. fur u

Octree

Unterraume

2. Befinden sich in einem Unterraum u mehr als k Punkte, sowiederhole 1. fur u

Octree

wiederhole 1. fur u

Octree

wiederhole 1. fur u

Octree

I Ergebnis: Effiziente Suche des nachsten Nachbarn in einerglobalen Datenstruktur

Octree

I Ergebnis: Effiziente Suche des nachsten Nachbarn in einerglobalen Datenstruktur

SignalCounterTree

I Zur Erinnerung: Split-Schritt benotigt Gewinner

I Move-Schritt erhoht “Signalzahler” des Vertex’

I Vertex mit hochstem Signalzahler ist Gewinner

I Verwaltung der Signalzahler in Form des SignalCounterTreesimplementiert:

I Rot-Schwarz-BaumI globale Datenstruktur

SignalCounterTree

Zusammenfassung der vorhandenen Datenstrukturen

I Octree ist global

I SCTree (SignalCounterTree) ist global

I Pool und PooledList werden als Datenstruktur verwendet→ potentiell global

Parallelisierung des Verfahrens 6= Parallelisierung derImplementierung

I Octree ist global

Parallelisierung - Bottom Up

Grundlegende IdeeI Sperren aller grundlegenden DatenstrukturenI Keine Anpassung des Algorithmus→ Parallelisierung ”abschaltbar”

Octree

PooledLis t

SignalCounterTree

FacesVerticesEdges

Grundlegender Ansatz:

I Lesende Zugriffe parallel zulassen

I Schreibende Zugriffe exklusiv ausfuhren

→ Typisches Leser-Schreiber Problem

Losung mit Boost.Thread

I SharedLockable modelliert geteilten und exklusiven Zugriff

I Sicherer: Sperrobjekte benutzen

class Threadsa f e{public :

int ha s I ndex ( int i n d e x ) {SharedLock lock( mMutex );

return ( mValueCount <= index ) ;}

int s e tVa l u eSa f e ( int i ndex , int v a l u e ) {ExclusiveLock lock( mMutex );

if ( ha s I ndex ( i nd ex ) ) {mValues [ i nd ex ] = va l u e ;return ( true )

return ( false ) ;}

Parallelisierung - Bottom Up - Problemfall Rekursion

class Threadsa f e{public :

int ha s I ndex ( int i n d e x ) {SharedLock lock( mMutex );

return ( ha s I ndex Imp l ( i nd e x ) ) ;}

int s e tVa l u eSa f e ( int i ndex , int v a l u e ) {ExclusiveLock lock( mMutex );

return ( s e tVa l u eSa f e Imp l ( index , v a l u e ) ) ;}

private :int ha s I ndex Imp l ( int i n d e x ) {

return ( mValueCount <= index ) ;}int s e tVa l u eSa f e Imp l ( int i ndex , int v a l u e ) {

/* Uses ha s I ndex Imp l ( ) i n imp l ementa t i on */}

Usercode

public Val* getNewVal()

public void delVal(Val*)

public void initFastArray(uint, uint)

public void initFastArray(uint)

public void increaseFastArray(float)

public void resizeFastArray(uint)

public bool isDeleted(Val*)

public Val* getVal(const uint)

public uint indexOf(Val*)

public bool isValid(Val*)

public void freeArray()

private Val* getNewValImpl()

private void delValImpl(Val*)

private void initFastArrayImpl(uint, uint, bool)

private void increaseFastArrayImpl(float)private void resizeFastArrayImpl(uint)

isDeletedImpl

private Val* getValImpl(const uint)

private uint indexOfImpl(Val*)

private bool isValidImpl(Val*)

private void freeArrayImpl()

private uint deletionsToIndex(uint) private void sortDeleted()

private uint biggerDeletionIndex(uint, uint, uint)

private void increaseDeletedStack() private void resizeDeletedStack(uint)

private uint deletionsToAddress(uint)

constructor

createNode

WriterReaderNodeWriter

getNearestPoint

getNearestXPoints

NodeReader

getNearestXPointsCore

getEdgeBoxSizegetCenter ptInBox

reinsert

addPtCore

removeVec

addPtToNode

minimisationCascadeAlternativ

deletePotentialEmptyNodesremoveVecCorecorrectBox addToList

ListWriterListReader

checkNode

getPointsInQRadiusCore

getPointsInQRadius

getNumOfNodes getNumOfPtsgetAverageListLengthnotMoreThenXChildren

getAverageDepth

initialAddPt

initialAddPtCore

freeXPointsList resizeInRadiusSListfreePointsInRadiusList getListForNearestPointsSearch

Usercode

public Val* getNewVal()

public void delVal(Val*)

public void initFastArray(uint, uint)

public void initFastArray(uint)

public void increaseFastArray(float)

public void resizeFastArray(uint)

public bool isDeleted(Val*)

public Val* getVal(const uint)

public uint indexOf(Val*)

public bool isValid(Val*)

public void freeArray()

private Val* getNewValImpl()

private void delValImpl(Val*)

private void initFastArrayImpl(uint, uint, bool)

private void increaseFastArrayImpl(float)private void resizeFastArrayImpl(uint)

isDeletedImpl

private Val* getValImpl(const uint)

private uint indexOfImpl(Val*)

private bool isValidImpl(Val*)

private void freeArrayImpl()

private uint deletionsToIndex(uint) private void sortDeleted()

private uint biggerDeletionIndex(uint, uint, uint)

private void increaseDeletedStack() private void resizeDeletedStack(uint)

private uint deletionsToAddress(uint)

constructor

createNode

WriterReaderNodeWriter

getNearestPoint

getNearestXPoints

NodeReader

getNearestXPointsCore

getEdgeBoxSizegetCenter ptInBox

reinsert

addPtCore

removeVec

addPtToNode

minimisationCascadeAlternativ

deletePotentialEmptyNodesremoveVecCorecorrectBox addToList

ListWriterListReader

checkNode

getPointsInQRadiusCore

getPointsInQRadius

getNumOfNodes getNumOfPtsgetAverageListLengthnotMoreThenXChildren

getAverageDepth

initialAddPt

initialAddPtCore

freeXPointsList resizeInRadiusSListfreePointsInRadiusList getListForNearestPointsSearch

Parallelisierung - Bottom Up - Problemefall Rekursion

Erster Ansatz:

I Offentliche Methoden setzen eine Sperre und delegieren dieeigentliche Arbeit an eine private Methode

I Private Methoden rufen niemals offentliche Methoden auf

→ Umfangreiche Anderungen am Code→ Inkonsistente Zustande durch zu kurze Sperren

Zweiter Ansatz:

I Rekursive Mutexe verwenden

→ Noch langsamer→ Inkonsistente Zustande durch zu kurze Sperren

Erster Ansatz:

→ Umfangreiche Anderungen am Code

→ Inkonsistente Zustande durch zu kurze Sperren

Zweiter Ansatz:

Erster Ansatz:

Zweiter Ansatz:

Erster Ansatz:

Zweiter Ansatz:

Erster Ansatz:

Zweiter Ansatz:

→ Noch langsamer

→ Inkonsistente Zustande durch zu kurze Sperren

Erster Ansatz:

Zweiter Ansatz:

Parallelisierung - Bottom Up - Probleme allgemein

I Haufiges Sperren und Entsperren von Mutexen

I Effektives Sperren balancierter Baume ein offenes Problem

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

→ Lock auch langsam wenn keine Kollisionen auftreten

→ Kein Verhindern unerwarteter destruktiver Operationen

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

Parallelisierung - Erzeuger-Verbraucher

Problem: Versucht Parallelismus implizit zu nutzen

Losung: Moglichkeiten des SGC Algorithmus ausnutzen

I ”Sperrbereiche” in denen ein Thread exklusiv arbeitet→ Potenziell sehr viel weniger Sperrvorgange notig

Grundlegende Idee

I Einen Thread fur Verwaltungsaufgaben

I n weitere Threads fur die ”eigentliche Arbeit”

→ Klassisches Erzeuger-Verbraucher Problem

Grundlegende Idee

Parallelisierung - Worker, Jobs und WorkerManager

Worker

+ execute() : void

Boost::ThreadWorkerManager

+ getNextAvailableJob() : Job

SpatialLocker

+ lock( vec3d pos , float radius ) : bool+ unlock( vec3d pos ) : bool

WorkingSetJob

+ isStatic() : bool

Parallelisierung - getNextAvailableJob()

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

Move Move Split Move Move Move Split Collapse ... PushPop

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

I Optimierung fur kleine Meshes notwendig→ Nur ein Thread→ Erstellt Jobs ”On Demand”

Parallelisierung - Auswahl der Strategie

Umschaltung auf “große” Strategie erfolgt zu spat

I Moglichkeit der Parallelitat wird nicht ausgenutzt

Umschaltung auf “große” Strategie erfolgt zu fruh

I Es ist gar kein Platz fur mehrere Threads→ Overhead durch raumliche Sperrungen

Parallelisierung - Auswahl der Strategie

Umschaltung auf “große” Strategie erfolgt zu spat

I Moglichkeit der Parallelitat wird nicht ausgenutzt

Umschaltung auf “große” Strategie erfolgt zu fruh

I Es ist gar kein Platz fur mehrere Threads→ Overhead durch raumliche Sperrungen

Parallele Datenstrukturen

I Erkenntnis: Vorhandene globale Datenstrukturen ungeeignetfur Parallelisierung

I Aufgabe: Implementierung neuer Datenstrukturen furI Pool und PooledListI OctreeI SCTree

Parallele Datenstrukturen

I Erkenntnis: Vorhandene globale Datenstrukturen ungeeignetfur Parallelisierung

I Aufgabe: Implementierung neuer Datenstrukturen furI Pool und PooledListI OctreeI SCTree

Paralleler Octree

I Idee: Einfuhrung einer Ebene, auf der gelockt wird

I oberhalb der Ebene sind generell nur lesende Zugriffe erlaubtI unterhalb der Ebene darf sich in jedem Unterbaum nur ein

Thread befinden

Paralleler Octree

I Idee: Einfuhrung einer Ebene, auf der gelockt wirdI oberhalb der Ebene sind generell nur lesende Zugriffe erlaubt

I unterhalb der Ebene darf sich in jedem Unterbaum nur einThread befinden

Paralleler Octree

I Idee: Einfuhrung einer Ebene, auf der gelockt wirdI oberhalb der Ebene sind generell nur lesende Zugriffe erlaubtI unterhalb der Ebene darf sich in jedem Unterbaum nur ein

Thread befinden

Paralleler Octree

I Idee: Einfuhrung einer Ebene, auf der gelockt wirdI oberhalb der Ebene sind generell nur lesende Zugriffe erlaubtI unterhalb der Ebene darf sich in jedem Unterbaum nur ein

Thread befinden

Aus SCTree wird SCMap

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

I Notwendigkeit: komplett neue Datenstruktur

I Wir wissen: Großtes Element wird am haufigsten gesuchtI Außerdem haben Beobachtungen ergeben:

I Es gibt obere und untere Schranken fur SignaleI Signale sind annahernd normalverteilt

I Wir wissen: Großtes Element wird am haufigsten gesucht

I Außerdem haben Beobachtungen ergeben:I Es gibt obere und untere Schranken fur SignaleI Signale sind annahernd normalverteilt

I Es gibt obere und untere Schranken fur Signale

I Signale sind annahernd normalverteilt

Implementierung als geordnete Hashtabelle:I Hashfunktion ist Normalverteilungsapproximation

Implementierung als geordnete Hashtabelle:

I Hashfunktion ist Normalverteilungsapproximation

I Lage des großten Elements kann gunstig mitgespeichertwerden (→ echte konstante Zugriffszeit)

I Anzahl der Buckets frei wahlbar

I Durchschnittliche Große der Buckets frei wahlbar

→ sehr flexibel

Parallelisierung - SpatialLocker

Veranschaulichung der Sperrbereiche:

I Aufgaben des SpatialLockers:

I Verwaltung aller gesperrten BereicheI Pruft, ob in einem Bereich gearbeitet werden darf

I Allgemeine Problematik ist die Große des Sperrbereichs:I Bei zu großen Sperrbereichen: Ablehnung neuer Jobs (→

Programmstillstand)I Bei zu kleinen Sperrbereichen: Unerwartete Uberschneidungen

(→ Programmabsturz)

I Ist der Sperrbereich gut gewahlt, so treten keine unerwartetenUberschneidungen auf

→ parallelen Zugriffe auf das selbe Pool-/PooledList-Objektsind ausgeschlossen

I Aufgaben des SpatialLockers:I Verwaltung aller gesperrten Bereiche

I Pruft, ob in einem Bereich gearbeitet werden darf

I Aufgaben des SpatialLockers:I Verwaltung aller gesperrten BereicheI Pruft, ob in einem Bereich gearbeitet werden darf

I Allgemeine Problematik ist die Große des Sperrbereichs:

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

I Bei zu kleinen Sperrbereichen: Unerwartete Uberschneidungen(→ Programmabsturz)

Programmstillstand)

I Bei zu kleinen Sperrbereichen: Unerwartete Uberschneidungen(→ Programmabsturz)

Parallelisierung - Gegenuberstellung

Parallelisierung im Straßenverkehr

Parallelisierung im Straßenverkehr - Bottom Up

Parallelisierung im Straßenverkehr - Sperrbereiche

Gliederung

Einfuhrung

Ergebnis

Ergebnis - Zeitgewinn

I Ausfuhrungszeit = 50% SmallMeshStrategy + 50%LargeMeshStrategy

I 10% Zeitgewinn mit jedem zusatzlichen Kern

Ergebnis - Parametrisierung

Parameter signifikant

Vermeidung von gesperrten Mutexen nein

Sperrebene beim Octree nein

Bucketgroße der SCMap nein

Max. Anzahl an vorerstellten Jobs nein

Zeitpunkt der Umstellung auf Large-Mesh-Strategy ja

Anteil verworfene Jobs ja

Vermeidung von gesperrten Mutexen

Sperrebene beim Octree

Bucketgroße der SCMap

Max. Anzahl an vorerstellten Jobs

Zeitpunkt der Umstellung auf Large-Mesh-Strategy

Anteil verworfene Jobs

Ergebnis - Fazit

I Implizite Parallelisierung geht mit C++ nicht→ funktionale Programmiersprachen sind hier eindeutigvorteilhaft

I Nebenlaufige Anwendungen benotigen saubere Struktur→ neben Geschwindigkeit auch Strukturierung

I Parallelisierung sollte von Beginn an Teil des Softwaredesignssein

Ergebnis - Fazit

Bei Datenstrukturen gilt:

I Probabilistische Datenstrukturen sind vorteilhaft→ z.B. Hashmaps oder Skiplisten anstelle von balanciertenBaumen

I Modell und Implementierung konnen stark voneinanderabweichen

I Daruberhinaus sollte die Ebene des Locks frei wahlbar sein

Ergebnis - Fazit

Ergebnis - Offene Fragen

I Optimale Parametrisierung noch unbekannt

I Effektive Strategie zur Joberstellung noch nicht gefunden→ Jobs werden erstellt und teilweise direkt wieder verworfen

Ergebnis - Offene Fragen

I Optimale Parametrisierung noch unbekannt

I Effektive Strategie zur Joberstellung noch nicht gefunden→ Jobs werden erstellt und teilweise direkt wieder verworfen

parallelisierung des growing cells meshing algorithmus

Technology

kleineren modelel

gb rameines

bottom up2

verfahrens fur

optimali inhaltlichi

ausreichendi algorithmen

operationeni groe

gegenuber veranderungen