parallelization - seminar large scale processing for multimedia analysis
DESCRIPTION
Slides for Seminar Introduction into Parallelization for Master Seminar 'Large Scale Processing for Multimedia Analysis Technologies', Hasso-Plattner-Institute Potsdam, winter semester 2011/12TRANSCRIPT
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
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
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
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
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
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
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
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
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
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
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
■ Fujitsu RX300 S5 1, CPU: 1x Xeon QuadCore, RAM: 12 GB
■ Fujitsu RX300 S5 2, CPU: 1x 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
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
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
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
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
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
Wie ? - Datenparallelität am Beispiel von Map / Reduce
11
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
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
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
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
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
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
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
Cluster-Systeme zur Stapelverarbeitung
15
Gemeinsames Dateisystem
Submission Host Execution
Slot
Scheduler
QueueingPriorisierungJob-Beschreibung
Matchmaking, Job startenStatus
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
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
(from arstechnica.com)
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
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
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
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
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
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
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
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
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
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
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 ?
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
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
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
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
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
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
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
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
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
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
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
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
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
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
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
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
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
Zusammenführung32
(Foster)
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
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
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
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
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
Seminar: LSP4MAT, Hasso-Plattner-Institut, Universität Potsdam
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