1.1 Binary file 0__Papers/year1report/report.pdf has changed

     2.1 --- a/0__Papers/year1report/report.tex	Fri Jun 08 14:19:26 2012 +0200
     2.2 +++ b/0__Papers/year1report/report.tex	Tue Jun 12 18:00:25 2012 +0200
     2.3 @@ -6,15 +6,14 @@
     2.4  \usepackage[utf8]{inputenc}
     2.5  
     2.6  \begin{document}
     2.7 +
     2.8 +
     2.9  \title{Hardwarebeschleunigung von paralleler Ablaufplanung für Multicoresysteme\\Zwischenbericht zum 1. Jahr}
    2.10  \author{Nina Engelhardt}
    2.11  \date{\today}
    2.12  \maketitle
    2.13  
    2.14  
    2.15 -
    2.16 -\section{Aims}
    2.17 -
    2.18  Ziel meiner Arbeit ist es, durch speziell angepasste Hardware die Synchronisation und Aufgabenverteilung für parallele Programme auf Multicoresystemen zu verbessern. Als Grundlage dient dafür das VMS-System, ein Framework dass es ermöglicht, Laufzeitumgebungen für verschiedenste parallele Programmiermodelle mit nur wenig Aufwand zu implementieren.
    2.19  
    2.20  In den ersten 6 Monaten habe ich wie geplant das VMS-System analysiert. VMS umfasst die Grundlegende Struktur, die allen Laufzeitumgebungen gemein ist: sie beinhaltet den Wechsel zwischen Programm und Laufzeitumgebung, und die Möglichkeit, eine Zeitliche Ordnung zwischen zwei Codepunkten in zwei virtuellen Prozessoren zu garantieren (semantikfreie Synchronisation). Auf Basis dieser Elemente muss der/die Laufzeitumgebungsentwickler\_in nur noch die jeweilige Semantik der parallelen Umgebung hinzufügen, in Form eines Plugins, dass Handlers für jedes parallele Konstrukt und einen Assigner, der entscheidet, welche Aufgaben als nächstes bearbeitet werden, bereitstellt.
    2.21 @@ -28,7 +27,14 @@
    2.22  
    2.23  Zu den Errungenschaften des Holistischen Modells gehören auch zwei grafische Darstellungen, die Unit Constraint Collection und der Scheduling Consequence Graph, deren Ziel es ist, die Gründe der (guten oder schlechten) Performance eines parallelen Programms ersichtlich zu machen. Die Unit Constraint Collection (kurz UCC) zeigt die Arbeitseinheiten (units) die im Programm definiert werden und die Randbedingungen (constraints) ihrer Ausfürbarkeit, die vom Programm selbst ausgehen. Der Consequence Graph (CG) repräsentiert eine realisierte Ausführung des Programms und zeigt die räumliche und zeitliche Platzierung der Arbeitseinheiten, die der Scheduler gewählt hat, sowie die unterschiedlichen Randbedingungen, die diese Wahl eingeschränkt haben. Diese können vom Programm selbst stammen, sich aus Ressourcenbegrenzungen ergeben, oder durch Beschränkungen der Laufzeitumgebung entstehen.
    2.24  
    2.25 +Nachdem ich VMS bereits zum Zweck der Analyse des Laufzeitverhaltens instrumentalisiert hatte, habe ich diese Infrastruktur wiederverwendet, um aus den gewonnenen Daten die räumliche und zeitliche Platzierung der Arbeitseinheiten im Consequence Graph abzuleiten. Zusätzlich habe ich ein VMS-Plugin, das synchrones Senden und Empfangen von Nachrichten zwischen Threads in einem Programm unterstützt (synchronous send-receive, kurz SSR), instrumentalisiert, um die Constraints zu erfassen, die für die Konstruktion der UCC und des CG notwendig sind. Schließlich erstellte ich ein kleines Programm, das diese Aufzeichnungen entgegennehmen und UCC \& CG darstellen kann.
    2.26  
    2.27 +Quasi mit dem ersten Blick stellte sich heraus, dass die Matrixmultiplikation, die ich seit Monaten als Testapplikation verwendete, einige Performanceprobleme hatte. So hatte z.B. der applikationseigene Lastenverteiler einen Bug, sodass von 40 Prozessorkernen nur 3 den Großteil der Arbeit zugeteilt bekamen, und 10 weitere einen kleinen Teil, die 27 restlichen jedoch gar keine. Des weiteren wurde die Arbeit so verteilt, dass der Kern, der den Verteiler ausführt, als erster Arbeit zugeteilt bekam, und diese Arbeit dann den Verteiler für längere Zeit unterbricht, bevor dieser weiteren Kernen Arbeit zuteilen kann. All dies war in den Statistiken nicht aufgefallen, in der Visualisierung jedoch offensichtlich. Als ich noch eine detailliertere Aufteilung des Overheads, der für eine bestimmte Arbeitseinheit aufgewendet wird, und mehrere Metriken (Takte, Befehle, Cache Misses) hinzugefügt hatte, wurden auch subtilere Effekte sichtbar. Dabei stellte sich z.B. heraus, dass die zentralisierte Architektur von VMS, das alle Informationen die die Laufzeitumgebung über den Zustand des Programms bereithalten muss in einem gemeinsamen Pool speicherte, auf den nur ein Kern gleichzeitig zugreifen kann, einen größeren Engpass als erwartet darstellte.
    2.28 +Da mir keine äquivalenten Performance-debugging Tools bekannt waren, und mehrere Mitarbeiter des Fachgebiets bereits händeringend nach solchen gesucht hatten, habe ich über dieses Tool einen weiteren Artikel verfasst [Anhang?], den ich voraussichtlich im August für die PPoPP-2013 Konferenz einreichen werde.
    2.29 +
    2.30 +Aufgrund der gewonnenen Erkentnisse verändert sich mein Plan wie folgt:
    2.31 +
    2.32 +Da die Vermutung, dass ein zentralisiertes System, in dem ein Master-Kern die Aufgabenverteilung für das gesamte System übernimmt, die beste Lösung sein würde, nicht so gesichert wie am Anfang erscheint, werde ich mich stärker für die verschiedenen Möglichkeiten der Parallelisierung interessieren. 
    2.33  
    2.34  \end{document}
    2.35