Parallelization - Seminar Large Scale Processing for Multimedia Analysis

ParallelisierungLSP4MAT Crash-Kurs

SeminarDr. Harald Sack / Dr. Peter Tröger

Jörg Waitelonis / Magnus Knuth / Christian HentschelBernhard Quehl / Haojin Yang

Hasso-Plattner-Institut für SoftwaresystemtechnikUniversität Potsdam

Wintersemester 2011/2012

Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam

Ausgangspunkt2

Feature ExtractionExtrahieren der für die Analyse notwendigen Eigenschaften des Videos

AnalyseAnwenden einer Rechenvorschrift zur Ermittlung des Ergebnisses

Ergebnis

HardCut Detectiondiffi = ∑(framei) - ∑(framei+1) diffi > threshold

?yes/no

Object Detectionsifti = SIFT(framei) isObject(sifti) yes/no

Scale Invariant Feature Transform trainierter Klassifikator

mehr als 10.000 Videos(zum Teil in HD Formaten)

- DVCPRO Codec (50/100Mbit/s)- 22GB/h bzw. 44GB/h


3

Die Herausforderung

Eine sehr große Menge an Videos in maximaler Geschwindigkeit analysieren.

(a) mehrere Maschinen arbeiten an unterschiedlichen Videos gleichzeitig(b) eine Maschine arbeitet an unterschiedlichen Videos gleichzeitig(c) eine Maschine arbeitet an einem Video parallel(d) mehrere Maschinen arbeiten an einem Video parallel

Sehr vereinfacht!Dazu nächste Woche mehr.

also: Parallelisieren über mehrere Maschinen (ScaleOut)Parallelisieren auf einer Maschine (ScaleUp)

Intuitive Möglichkeiten ?

Heute ...

Gruppe Eingabe Verarbeitungsaufgabe Ausgabe

1) Basic Feature Extraction

Video-Dateien

1a) Zerlegung von Videoströmen 1b) Feature-Ermittlung pro Bild

1c) Steuerung der Weiterverarbeitung

• Einzelbilder pro Video

• Basis-Features pro Bild

• Jobs

2) Face Clustering

Bilder aller Videos

2a) Gesichter pro Bild erkennen

2b) Feature pro Gesicht extrahieren

2c) Clustering der Features

• ermittelte Cluster

• Cluster-Zuordnung pro Bild

3) Text Detection

Basis-Features aller Videos

3a) Bounding Boxes pro Bild erkennen

3b) OCR pro Bounding Box

•Bounding Boxes pro Bild

•Text-Inhalte pro Bild

4) Scene Cut Detection

Aufeinander folgende Bilder pro Video

4a) Features (Histogramm, Pixel Differenz etc) pro Bildpaar extrahieren

4b) Sortierung / Analyse der Features

• Liste der Schnitte im Video

• Pro Schnitt: Index, Frame, Dauer, Typ

5) Visual Concept Detection

Bilder aller Videos

5a) Codebook pro Bild ermitteln

5b) Bild bzgl. des Codebook auswerten, Histogramm ermitteln

5c) SVM mit Histogramm trainieren

5d) SVM-Klassifikation aller Bilder

• Visuelle Konzepte pro Bild

6) Mahout Features von Bildern

6a) Parallelisierte SVM auf Basis von Mahout

Potentiell unvollständig


Parallele AusführungWo ?■ Im Prozessor (ILP, Many-Core Prozessoren)■ Multiple Prozessoren in einer Maschine (multiprocessing)■ Multiple Maschinen (Verteiltes Rechnen)

Wie ?■ Datenparallelität - Gleiche Operation auf unterschiedlichen Daten■ Task-Parallelität - Verschiedene Operationen zur gleichen Zeit■ Flussparallelität - Überlappende Operationen auf Datenstrom (Pipeline)

Warum ?■ „Lineare Beschleunigung“ (Speedup)□ n-mal mehr Ressourcen führen dazu, das die Applikation die gleiche

Aufgabe in n-mal weniger Zeit löst■ „Lineare Skalierbarkeit“ (Scaleup)□ n-mal mehr Ressourcen führen dazu, das die Applikation ein n-mal

größeres Problem in der gleichen Zeit löst

5


Wo ? - Parallele Hardware6

Rechenkern

ProcessProcessProcessProcessInstruktions-strom

ProcessProcessProcessProcessInstruktions-strom

RechenkernRechenkern

Rechenkern

Speicher

Knoten

Netz

wer

k

Instruktions-strom

ProcessProcessProcessProcessInstruktion

Compiler (SSE, MMX, ...)

Threads (OpenMP, TBB)Work Items(CUDA, OpenCL)

Prozesse


Wo ? - Kombinationen7

Processor

Process

Processor

Process

Mes

sage

Mes

sage

Mes

sage

Mes

sage

Data Data

Processor

Process

Shared Data

Processor

Process

Data Data

Processor

Process

Shared Data

Processor

Process

Data Data

Processor

Process

Shared Data

Processor

Process

Data Data

Processor

Process

Shared Data

Processor

Process

Data Data

Processor

Process

Shared Data

Processor

Process

Data Data

Mes

sM

ess

Mes

sM

ess

Mes

sM

ess

Mes

sM

ess

Mes

sM

ess

Mes

sM

ess


Wo ? - Heterogene FSOC Hardware8 ■ HP DL980 G7 - 3, CPU: 8 x Xeon 8-Core, RAM: 64 GB

■ HP DL980 G7 - 2, CPU: 8 x Xeon 8-Core, RAM: 128 GB

■ HP DL980 G7 - 1, CPU: 8 x Xeon 8-Core, RAM: 2048 GB

■ Fujitsu RX600 S5 1, CPU: 4 x Xeon 6-Core, RAM: 256 GB

■ Fujitsu RX600 S5 2, CPU: 4x Xeon 8-Core, RAM: 1024 GB

■ Fujitsu RX200 S5 1, CPU: 2x Xeon QuadCore, RAM: 12 GB



■ FluiDyna Typhoon, CPU: 2 x Xeon QuadCore, RAM: 24 GB RAM, GPU: 4 x NVIDIA Tesla C2050 (3GB GDDR5)

■ EMC² VNX 5700, HDD: 131 x 650 GB, SSD: 15 x 200 GB

■ EMC² Celerra NS-960, HDD: 135 x 450 GB, SSD: 9 x 400 GB


Wie ? - Task vs. Thread

■ Gängigster Ansatz zur Parallelisierung ist „multi-threading“

□ Generierung nebenläufiger Aktivitäten im Betriebssystem

□ Synchronisierung der Ausführung mit Betriebssystemschnittstellen - Mutex, Semaphore, Bedingungsvariablen, Barrieren

□ Bereitstellung notwendiger Daten im gemeinsamen Speicher

□ Applikation muss sich der Ausführungshardware anpassen

■ Verallgemeinerung: Task-Modell

□ Task == nicht-unterbrechbare Aufgabe, eigener Stack + Register

□ Kooperatives Modell, Task gibt Kontrolle ab

□ Als Objekt oder Statement modelliert

□ Scheduling durch Task-Bibliothek auf einem Pool von Threads

□ ,yield‘ statt ,context switch‘

□ Beispiele: OpenMP, Intel Thread Building Blocks, ...

9


Bsp: OpenMP

■ Spracherweiterung für C, C++ und Fortran

□ Portable nebenläufige Programmierung mit Threads

□ Abstraktion von Task-Parallelität und Schleifen-Parallelität

□ Abgeleitet von Parallelisierung durch Compiler-Pragmas (HPF)

■ Programmiermodell: Fork-Join-Parallelität

□ Master-Task spannt eine Menge paralleler Kontrollflüsse für eine begrenzte Code-Region auf

□ Tasks synchronisieren sich wieder an gemeinsamen Punkt (Barriere)

10

Parallel Regions

Master Thread


Wie ? - Datenparallelität am Beispiel von Map / Reduce

11


OpenCV12 • Bibliothek zur Verarbeitung von Einzelbildern

• Windows / Linux / MacOS X / Android

• C++ / Python bindings

• Optimiert für Intel - Prozessoren (z.B. SSE)

• Bereits für Mehrkernarchitekturen mit Intel TBB optimiert

• Transparent für die High-Level-Funktionen eingesetzt

• Optional - OpenCV muss mit Intel TBB - Bibliothek gebaut werden

• GPU Modul

• nur CUDA Unterstützung, GPU-typische Besonderheiten (z.B. Startzeit)

• nicht alle Algorithmen portiert

• muss direkt angesteuert werden


Analyse

■ Massiv heterogene Hardware im FSOC-Lab

□ Vielschichtige Möglichkeiten zur parallelen Ausführung von Code

■Wenig Chancen zur feingranularen Parallelisierung

□ OpenCV - Team kann das vermutlich besser

□ Aufwand für neuartige Analysealgorithmen zu hoch

■ Viele Chancen für grobgranulare Task- und Datenparallelität

□ Klare Abhängigkeiten bzgl. des Datenfluss - Videos, Bilder, Features

□ Bilder bzw. Features können zumeist entkoppelt analysiert werden

■ Menge von SMP-Maschinen + SSH => suboptimale Plattform

■ Idee: Maschinen zu einer homogenen Plattform kombinieren = Cluster

□ Jeder grobgranulare Schritt ist eine Programmausführung = Job

□ Programm + STDIN + STDOUT + Dateien

13


Cluster - Systeme

■ Markt für große SMP-Systeme ist vergleichsweise klein

□ Hoher Preis, wenig Nutzer

■ Cluster als preiswerte Alternative

□ DM-MIMD Ansatz

□ Parallele Verarbeitung mit standardisierter Hardware

□ Nutzer als Hersteller

□ Koordinierung hauptsächlich durch Software

□ Vergleichsweise hohe Kommunikationskosten (Latenz, Bandbreite)

□ Zielt auf grobgranulare parallele Aufgabenstellungen ab

■ Akzeptierte Standards für Nachrichtenaustausch zwischen Prozessen


Cluster-Systeme zur Stapelverarbeitung

15

Gemeinsames Dateisystem

Submission Host Execution

Slot

Scheduler

QueueingPriorisierungJob-Beschreibung

Matchmaking, Job startenStatus


Condor■ ,Idle Time Computing‘ Umgebung der University of Wisconsin

□ Prof. Miron Livny, Center for High Throughput Computing

□ Entwickelt seit 1985

□ HPC vs. HTC / Idle Time Computing

□ Dokumentation unter http://www.cs.wisc.edu/condor

■ Konzept der Stapelverarbeitung (batch processing)

□ Beschreibung der Ressourcenanforderung in Datei,Übergabe an de Scheduler

□ Beinhaltet Name der auszuführenden Datei, Anforderungen an die Zielmaschine, zu berücksichtigende Dateien

□ Scheduler verwaltet globale Warteschlange aller Jobs

■ Knoten können beliebig ihre Verfügbarkeit ändern

■ Kann potentiell in Cloud-Umgebungen skalieren

16

http://www.cs.wisc.edu/condor

http://www.cs.wisc.edu/condor

(from arstechnica.com)


Condor

■ Typischer Ablauf im Scheduler

□ Maschine im Zustand ,Idle‘ finden, die die Anforderungen erfüllt(,Matchmaking‘)

□ [Eingabedaten zum Execution Host übertragen (,stage-in‘)]

□ Job als Programm im lokalen Pfad ausführen

□ [Ausgabedaten zum Submission Host übertragen (,stage-out‘)]

■ Universe - Konzept

□ Klassen von Jobs - Standard, Vanilla, Java, ...

□ Bereitstellung der korrekten Ausführungsumgebung

■ ClassAd

□ Internes Condor-Format zur Beschreibung von Ressourcen

■Wenn notwendig, leichte Unterstützung von Workflows

■ Startzeit für Job im Bereich von mehreren Sekunden !

18


Condor@FSOC

■ condorsh.fsoc.hpi.uni-potsdam.de

□ Normalerweise Ausgangspunkt zum Abschicken von Jobs

□ SSH, Heimatverzeichnis via NFS, keine große Rechenleistung

□ Notwendige Programme zum Kompilieren von eigenen Tools

■ Gesamter Pool hat einheitliches Dateisystem

□ Pfade gelten auf jeder Maschine - kein Dateitransfer in Condor nötig

□ Keine Pfade in die Programme kodieren, lieber Kommandozeilenargumente bzw. STDIN / STDOUT einsetzen

■ Knoten für die Ausführung laufen mit X64-Linux

□ Aktueller Kern, Ubuntu

□ Ausnahmen (Tesla GPUs, Windows) in Arbeit, müssen dann per Matchmaking in Condor direkt angesteuert werden

■Wichtige Werkzeuge: condor_q, condor_status, condor_wait, condor_submit, condor_rm

19


Condor - Beispielskript

■ Mit condor_submit die Skriptdatei an den Scheduler schicken

■Weitere Optionen unter http://bit.ly/swHP3i

■ Mit condor_q die Warteschlange der eigenen Jobs überprüfen

■ Mit condor_status die belegten Slots und verfügbaren Architekturen anschauen

■ Mit condor_rm Jobs aud der Warteschlange entfernen

20

Universe=vanillaExecutable=/bin/hostnameOutput=condorout$(PROCESS).txtLog=condorlog.txtRequirements = OpSys == "LINUX"Queue 50

http://bit.ly/swHP3i

http://bit.ly/swHP3i



Video-Dateien





• Jobs

2) Face Clustering

Bilder aller Videos






3) Text Detection













Bilder aller Videos









Gruppe 1 vs. den Rest

■ Alle Gruppen teilen sich ein Share im FSOC-Storage-System

■ Gruppe 1

□ generiert Condor-Jobs basierend auf der initialen Extraktion

□ organisiert die Datenablage entsprechend (Verzeichnisse etc.)

□ berücksichtigt Ressourcenanforderungen der anderen Gruppen(GPU, Mindestanzahl Kerne und Speicher, Software etc.)

■ Gruppe 2 - 5

□ Entwickeln Prototypen, die als Kommandozeilenapplikation unter X64 Linux laufen

□ Kümmern sich um Paketierung der Bibliotheken (statisches Linken, LD_LIBRARY_PATH etc.)

□ Verwenden als Ein- und Ausgabe ausschliesslich Dateien

■ Gruppe 6: TBD, zunächst lokal mit 1-Node-Hadoop testen

■ Dozenten stellen initiale Eingabedateien für alle Gruppen bereit

22


Wie ? - Granularität23 Prozesse auf verschiedenen Maschinen ?

Prozesse auf einer Maschine ?Threads auf einer Maschine ?

Alles gleichzeitig ?

Wo liegen die Daten ?Welche Kommunikation wird gebraucht ?

Wird es dann überhaupt schneller ?


Methodik zur Parallelisierung [Breshears]

■ Parallele Lösung muss sequentielle Konsistenz beibehalten

■ “Mentale Simulation” der parallelen Ausführung durchführen

■ Menge der Berechnungen pro Task muss den Overhead für Datenverteilung und Scheduling kompensieren

■ Granularität

□ Menge der Berechnungen, bevor Synchronisation nötig wird

□ Overhead der feingranularen Lösung vs. Nebenläufigkeit der grobgranularen Lösung

□ Nur durch iteratives Probieren lösbar

□ Abhängig von der Hardware - Granularität konfigurierbar machen

■ Ausführungsreihenfolge bedingt durch Berechnungs- und/oder Datenabhängigkeiten

24


Methodik zur Parallelisierung [Foster]■ Problemspezifikation in einem Algorithmus lösen, der

Nebenläufigkeit, Skalierbarkeit und Datenlokalität erreicht

■ Beste parallele Lösung unterscheidet sich typischerweise massiv von der seriellen Variante

■ 4 methodische Schritte

□ Partitionierung - Daten und Berechnung maximal partitionieren

□ Kommunikation - Notwendige Koordination der Ausführung definieren (Datenaustausch, Berechnungsreihenfolge)

□ Zusammenführung - Berücksichtigung von Performanz und Implementierungsaufwand

□ Abbildung - Prozessorauslastung maximieren, Kommunikation minimieren

■ Bedingt meist Backtracking bei der Lösungsfindung

25


Partitionierung

■ Ermittlung der Möglichkeiten zur Parallelisierung

■ Feingranulare Dekomposition, um Lösungsraum zu ermitteln

■ Gute Aufteilung behält Berechnungen und Daten zusammen

□ Zunächst Datenpartitionierung - ,domain decomposition‘

□ Zunächst Aufgabenpartitionierung - ,functional decomposition‘

□ Dann jeweils anderen Aspekt betrachten

□ Komplementäre Herangehensweisen

□ Versteckte Strukturierung des Algorithmus identifizieren

■ Hier noch keine Performanzoptimierung betreiben

□ Replikation von Daten oder Berechnung vermeiden

□ Aufteilung ohne Fokus auf eine spezifische Zielplattform(SMP System, Cluster, weitverteiltes System, ...)

■ Resultiert in multiplen gültigen Lösungsvarianten

26


Partitionierung■ Datenpartitionierung

□ Definiere kleine Datenfragmente, dann definiere die zugehörigen Berechnungen

□ Verschiedene Berechnungsschritte auf den gleichen Daten getrennt betrachten

□ Daumenregel: Erst auf die großen und häufig genutzten Strukturen konzentrieren

□ Geeignet besonders bei signifikanter Überlappung von Daten in den Berechnungen

■ Funktionale Partitionierung

□ Berechnung in disjunkte Teile zerlegen, notwendige Daten zunächst ignorieren

□ Beispiel: Producer / Consumer - Muster

27


Checkliste - Partitionierung

■ Checkliste für das resultierende Schema

□ Größenordnung mehr Tasks als Prozessoren ?-> Flexibilität für nächste Schritte sicherstellen

□ Redundante Berechnungen und Datenspeicherungen vermieden ?-> Skalierbarkeit sicherstellen

□ Tasks von vergleichbarer Größe ?-> Vereinfacht die spätere Nutzung der Ressourcen

□ Skaliert die Anzahl der Tasks mit der Problemgröße ?-> Skalierendes Verhalten mit größerer Menge von Ressourcen

■ Schlechte Partitionierung muß durch grobe Performanzabschätzung erkannt werden

■ Eventuell muss Aufgabenstellung umformuliert werden

28


Kommunikation

■ Verbindungen zwischen Datenkonsumenten und -produzenten finden

■ Art und Menge der Nachrichten auf diesen Verbindungen definieren

■ Datenpartitionierung

□ Typischerweise komplexe Kommunikationsgraphen (Abhängigkeiten)

□ Eventueller Rückschritt zu anderer Partitionierung nötig

■ Funktionale Partitionierung

□ Kommunikation kann leicht aus Datenfluss zwischen den Tasks abgeleitet werden

■ Typische Muster

□ Lokale vs. globale Kommunikation (Anzahl Nachbarn)

□ Unstrukturierte vs. strukturierte Kommunikation (z.B. Baum)

□ Statische vs. dynamische Struktur

□ Synchrone vs. asynchrone Kommunikation

29


Kommunikation

■ Berechnung und Kommunikation verteilen, Kontrollfluss des Algorithmus nicht zentralisieren

□ Schlechtes Beispiel: Zentraler Manager zur Koordinierung

□ ,Teile-und-herrsche‘ als Grundansatz

■ Unstrukturierte Kommunikation kann nur schlecht optimiert werden

■ Checkliste

□ Haben alle Tasks ungefähr den gleichen Kommunikationsaufwand ?-> Hot Spots verteilen oder replizieren

□ Ist nebenläufige Kommunikation zwischen den Tasks möglich ?

□ Ist nebenläufige Berechnung zwischen den Tasks möglich ?

30


Zusammenführung

■ An diesem Punkt sollte korrekter paralleler Algorithmus definiert sein

■ Noch keine Spezialisierung für Ausführungsumgebung

■ Entscheidungen zu Partitionierung und Kommunikation überdenken

□ Tasks zusammenlegen (Overhead und Kommunikation einsparen)

□ Daten oder Berechnungen replizieren (Kommunikation einsparen)

■ Resultierende Menge an Tasks sollte noch immer größer als die Menge der Prozessoren sein

■ Drei gegensätzliche Optimierungen

□ Kommunikation reduzieren durch grobgranularere Tasks(weniger Daten, weniger Nachrichten)

□ Flexibilität bzgl. der Ausführungsplattform sicherstellen

□ Aufwand für Parallelisierung beschränken

■ Optimal: Granularität konfigurierbar gestalten

31


Zusammenführung32

(Foster)


Checkliste - Zusammenführung

■ Kommunikationskosten durch bessere Lokalität reduzieren ?

■ Lohnt sich redundante Berechnung unter Berücksichtigung aller Kosten?

■Wird durch Datenreplikation die Problemgröße / Anzahl der genutzten Prozessoren reduziert ?

■ Hat der gleiche Task bei größerer Skalierung noch immer das gleiche Verhältnis zwischen Berechnung und Kommunikation ?

■ Agieren größere Tasks noch immer mit ausreichender Nebenläufigkeit ?

■ Skaliert die Anzahl der Tasks mit der Problemgröße ?

■Wie weit kann die Anzahl der Tasks verringert werden, ohne Lastverteilung, Skalierbarkeit oder Entwicklungsaufwand zu strapazieren

■ Bringt die Parallelisierung verbesserte Leistung ?

33


Abbildung

■ Nur relevant für verteilte Systeme

□ SM-MIMD Systeme haben Betriebssystem für Scheduling

■ Verringerung der Ausführungszeit durch ...

□ Platzierung nebenläufiger Tasks auf verschiedenen Knoten

□ Platzierung stark kommunizierender Tasks auf einem Knoten

■ Gegenläufige Strategien, durch Ressourceneinschränkungen beeinflußt

□ ,Bin Packing‘

■ Typischerweise Lastbalanzierung durch Heuristiken

□ In Hardware für Netzwerkanfragen

□ In Software für dynamisch verteilte Applikationsläufe - ,Cluster‘

34



Video-Dateien





• Jobs

2) Face Clustering

Bilder aller Videos






3) Text Detection













Bilder aller Videos









Nächste Schritte

■ Besprechung innerhalb der Gruppe

□ Ist die Verarbeitungsaufgabe wirklich klar ?

□ Analyse des Ist-Zustand, basierend auf Konsultation

□ Initiale Testdaten evaluieren

□ Methodische Analyse der Parallelisierungsmöglichkeiten

□ Design eines Prototypen entwickeln, vorstellen, dann (!) bauen

■ Administratives

□ FSOC-Zugang kommt per eMail, benötigt VPN-Einwahl

□ Technische Wünsche (Software etc.) an Peter Tröger

□ Mit Condor vertraut machen

□ Rechtzeitig um Konsultationstermine bemühen

□ Nachsicht üben - das FSOC-Labor ist im ,Fluss‘

□ Neuigkeiten zu den Ausführungsressourcen im Veranstaltungs-Blog

36

Parallelization - Seminar Large Scale Processing for Multimedia Analysis

Technology