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 ...

Surface Reconstruction - Dimensionen

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

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

Surface Reconstruction - Dimensionen

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

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

Surface Reconstruction - Dimensionen

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

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

Surface Reconstruction - Dimensionen

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

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

Gliederung

Einfuhrung

Surface ReconstructionAllgemeinSmart Growing Cells

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

Ergebnis

Surface Reconstruction - Probleme

Moglichkeiten der Verknupfung

Surface Reconstruction - Probleme

Moglichkeiten der Verknupfung

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

Smart Growing Cells Algorithmus - Schritte

(a) Move / Glatten

(b) Split

(c) Collapse

Smart Growing Cells Algorithmus - Schritte

(a) Move / Glatten

(b) Split

(c) Collapse

Smart Growing Cells Algorithmus - Ablauf

Ablauf einer Rekonstruktion

Gliederung

Einfuhrung

Surface ReconstructionAllgemeinSmart Growing Cells

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

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

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

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

Theorie: Standardprozess einfach mehrfach ausfuhren

Parallelisierung

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

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

Theorie: Standardprozess einfach mehrfach ausfuhren

Parallelisierung

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

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

Theorie: Standardprozess einfach mehrfach ausfuhren

Parallelisierung

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

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

Theorie: Standardprozess einfach mehrfach ausfuhren

Parallelisierung

Eignung der Implementierung fur die Parallelisierung

I Hochgradig optimiertI Nutzung von vorreserviertem SpeicherI Eigene grundlegende Datenstrukturen

Mesh

Octree

PooledLis t

Pool

SignalCounterTree

Pool

FacesVerticesEdges

Parallelisierung

Eignung der Implementierung fur die ParallelisierungI Hochgradig optimiert

I Nutzung von vorreserviertem SpeicherI Eigene grundlegende Datenstrukturen

Mesh

Octree

PooledLis t

Pool

SignalCounterTree

Pool

FacesVerticesEdges

Parallelisierung

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

I Eigene grundlegende Datenstrukturen

Mesh

Octree

PooledLis t

Pool

SignalCounterTree

Pool

FacesVerticesEdges

Parallelisierung

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

Mesh

Octree

PooledLis t

Pool

SignalCounterTree

Pool

FacesVerticesEdges

Parallelisierung

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

Mesh

Octree

PooledLis t

Pool

SignalCounterTree

Pool

FacesVerticesEdges

Pool

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

Pool

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

Pool

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

Pool

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

Pool

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

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

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

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.

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

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

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

Unterraume

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

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

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

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

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

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

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

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

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

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

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

Parallelisierung - Bottom Up

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

Mesh

Octree

PooledLis t

Pool

SignalCounterTree

Pool

FacesVerticesEdges

Parallelisierung - Bottom Up

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

Parallelisierung - Bottom Up

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

Parallelisierung - Bottom Up

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

Parallelisierung - Bottom Up

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 */}

} ;

Parallelisierung - Bottom Up - Problemfall Rekursion

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

addPt

freeXPointsList resizeInRadiusSListfreePointsInRadiusList getListForNearestPointsSearch

Parallelisierung - Bottom Up - Problemfall Rekursion

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

addPt

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

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

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

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

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

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

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

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

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

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

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

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

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

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 - 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 - 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

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

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 gesucht

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

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

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 Signale

I Signale sind annahernd normalverteilt

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

Aus SCTree wird SCMap

Implementierung als geordnete Hashtabelle:I Hashfunktion ist Normalverteilungsapproximation

Aus SCTree wird SCMap

Implementierung als geordnete Hashtabelle:I Hashfunktion ist Normalverteilungsapproximation

Aus SCTree wird SCMap

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

Aus SCTree wird SCMap

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

Aus SCTree wird SCMap

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

Aus SCTree wird SCMap

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

Aus SCTree wird SCMap

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:

Parallelisierung - SpatialLocker

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

Parallelisierung - SpatialLocker

I Aufgaben des SpatialLockers:I Verwaltung aller gesperrten Bereiche

I 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

Parallelisierung - SpatialLocker

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

Parallelisierung - SpatialLocker

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

Parallelisierung - SpatialLocker

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

Parallelisierung - SpatialLocker

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

Parallelisierung - SpatialLocker

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

Parallelisierung - Gegenuberstellung

Parallelisierung im Straßenverkehr

Parallelisierung - Gegenuberstellung

Parallelisierung im Straßenverkehr - Bottom Up

Parallelisierung - Gegenuberstellung

Parallelisierung im Straßenverkehr - Sperrbereiche

Gliederung

Einfuhrung

Surface ReconstructionAllgemeinSmart Growing Cells

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

Ergebnis

Ergebnis - Zeitgewinn

I Ausfuhrungszeit = 50% SmallMeshStrategy + 50%LargeMeshStrategy

I 10% Zeitgewinn mit jedem zusatzlichen Kern

Ergebnis - Zeitgewinn

I Ausfuhrungszeit = 50% SmallMeshStrategy + 50%LargeMeshStrategy

I 10% Zeitgewinn mit jedem zusatzlichen Kern

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 - 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