1.1 --- a/0__Papers/year1report/report.tex	Fri Jun 15 18:59:03 2012 +0200
     1.2 +++ b/0__Papers/year1report/report.tex	Mon Apr 15 12:38:12 2013 +0200
     1.3 @@ -1,12 +1,12 @@
     1.4  
     1.5 -\documentclass[11pt,a4paper]{article}
     1.6 +\documentclass[12pt,a4paper]{article}
     1.7  
     1.8  \usepackage[german]{babel}
     1.9  \usepackage{fullpage}
    1.10  \usepackage[utf8]{inputenc}
    1.11  
    1.12  \begin{document}
    1.13 -
    1.14 +\setlength{\parindent}{0px} \setlength{\parskip}{1 em}
    1.15  
    1.16  \title{Hardwarebeschleunigung von paralleler Ablaufplanung für Multicoresysteme\\Zwischenbericht zum 1. Jahr}
    1.17  \author{Nina Engelhardt}
    1.18 @@ -14,48 +14,76 @@
    1.19  \maketitle
    1.20  
    1.21  
    1.22 -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.
    1.23 +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 Virtualzed Master-Slave System, kurz VMS, ein Framework dass es ermöglicht, Laufzeitumgebungen für verschiedenste parallele Programmiermodelle mit nur wenig Aufwand zu implementieren.
    1.24  
    1.25  \section{Ausgeführte Arbeiten}
    1.26  
    1.27 -In den ersten 6 Monaten habe ich wie geplant das VMS-System analysiert. VMS umfasst die Grundlegende Struktur, die allen Laufzeitumgebungen (Runtimes) 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 Laufzeitumgebungsentwickler nur noch die jeweilige Semantik der parallelen Umgebung hinzufügen. Diese wird in Form eines Plugins bereitgestellt, das zwei Teile enthält: einen Assigner, der entscheidet, welche Aufgaben als nächstes bearbeitet werden, und einen Request Handler, der die Implementation der parallelen Konstrukte liefert.
    1.28 +In den ersten 6 Monaten habe ich wie geplant das VMS-System analysiert. VMS umfasst die Grundlegende Struktur, die allen Laufzeitumgebungen (\emph{Runtimes}) gemein ist: sie beinhaltet den Wechsel zwischen Programm- und Umgebungscode und die Möglichkeit, eine zeitliche Ordnung zwischen zwei Codepunkten in zwei virtuellen Prozessoren zu garantieren (semantikfreie Synchronisation). Auf dieser Basis muss der Laufzeitumgebungsentwickler nur noch die jeweilige Semantik der parallelen Umgebung hinzufügen. Diese wird in Form eines Plugins bereitgestellt, das zwei Teile enthält: einen \emph{Assigner}, der entscheidet, welche Aufgaben als nächstes bearbeitet werden, und einen \emph{Request Handler}, der die Implementation der parallelen Konstrukte liefert.
    1.29  
    1.30 -Diese zweiteilige Struktur ermöglicht zwei Ansatzpunkte für die Beschleunigung: den VMS-Kern selbst -- Verbesserungen an dieser Stelle kommen allen Laufzeitumgebungen zu Gute -- und das jeweilige Plugin. VMS ist minimal gehalten und bietet nur wenige Möglichkeiten zur Verbesserung, jedoch haben Änderungen hier den größten Effekt. VMS ist außerdem, da es die grundlegendsten Elemente zusammenfasst, bereits sehr nah an der existierenden Hardware und die häufigen Aufgaben sind gut unterstützt. Zusätzliche Beschleunigung kann hier nur durch sehr ressourcenintensive Lösungen (z.B. zusätzliche Registersätze für schnellen Kontextwechsel) erwartet werden.
    1.31 -Beschleuniger für Pluginfunktionen haben deutlich mehr Spielraum, besonders für Sprachen mit komplexen, hardwarefernen Konstrukten (und dies sind die besonders interessanten, weil sie sich der Struktur des Problems nähern und damit dem Programmierer die Arbeit abnehmen, das Problem in Hardwarenahe Konzepte umzudenken bzw. übersetzen zu müssen.) Da die Pluginfunktionen aber Sprachspezifisch sind, kommen Beschleunigungen an dieser Stelle nur dem Teil der Programme zugute, die in dieser Sprache geschrieben sind. Die Herausforderung wird also sein, Hardwareelemente zu finden, die möglichst flexible und vielfältige Verwendung finden können. Haupsächlich wird aber die Programmiersprache StarSs anvisiert werden, die hier im Fachgebiet AES häufig Verwendung findet.
    1.32 +Diese zweiteilige Struktur ermöglicht zwei Ansatzpunkte für die Beschleunigung: den VMS-Kern selbst -- Verbesserungen an dieser Stelle kommen allen Laufzeitumgebungen zu gute -- und das jeweilige Plugin. VMS ist minimal gehalten und bietet nur wenige Möglichkeiten zur Verbesserung, jedoch haben Änderungen hier den größten Effekt. Die von VMS gelieferten grundlegenden Elemente sind sehr nah an der existierenden Hardware, deshalb sind die meisten häufigen Aufgaben bereits gut unterstützt. Zusätzliche Beschleunigung kann hier nur durch sehr ressourcenintensive Lösungen (z.B. zusätzliche Registersätze für schnellen Kontextwechsel) erwartet werden.
    1.33 +Beschleuniger für Pluginfunktionen haben deutlich mehr Spielraum, besonders für Sprachen mit komplexen, hardwarefernen Konstrukten. Diese Sprachen sind von großer Bedeutung, weil sie sich der Struktur des Problems nähern und damit dem Programmierer die Arbeit abnehmen, das Problem in Hardwarenahe Konzepte umzudenken bzw. übersetzen zu müssen. Da die Pluginfunktionen aber Sprachspezifisch sind, kommen Beschleunigungen an dieser Stelle nur dem Teil der Programme zugute, die in dieser Sprache geschrieben sind. Die Herausforderung wird also sein, Hardwareelemente zu finden, die möglichst flexible und vielfältige Verwendung finden können. Haupsächlich wird aber die Programmiersprache OmpSs anvisiert werden, da sie im Fachgebiet Architektur Eingebetteter Systeme bereits verwendet wird.
    1.34  
    1.35 -VMS ist die praktische Ausformulierung eines Modells des Parallelismus, die von Dr. Sean Halle unter dem Namen ``Holistic Model of Parallel Computation''[~] vorgeschlagen wurde. Dieses Modell isoliert die schedulingrelevanten Teile eines Programms und legt das Augenmerk besonders auf die Effekte von Scheduling Decisions auf die Performance.
    1.36 +VMS ist die praktische Ausformulierung eines Modells des Parallelismus, die von Dr. Sean Halle unter dem Namen ``Holistic Model of Parallel Computation''\cite{bib:holistic} vorgeschlagen wurde. Dieses Modell isoliert die schedulingrelevanten Teile eines Programms und legt das Augenmerk besonders auf die Effekte von Scheduling Decisions auf die Performance.
    1.37  
    1.38 -Während meiner Analyse von VMS stieß ich auf mehrere unklare Stellen in der Theorie, und habe diese in Zusammenarbeit mit Dr. Halle ausgearbeitet. Insbesondere habe ich das Modell um das Konzept der Schichten erweitert, das dem Umstand Rechnung trägt, dass in einem System meistens mehrere hierarchisch untergeordnete Scheduler existieren. So werden die Arbeitseinheiten, über die die Laufzeitumgebung als Eins entscheidet, möglicherweise vom Betriebssystem noch einmal unterbrochen und verteilt, spätestens aber vom Prozessor in kleinere Einheiten -- Assemblerbefehle -- zerteilt, und auf unterschiedliche Funktionseinheiten aufgeteilt. Im Fall von Out-of-order Prozessoren wird deutlich, das auch dies parallele Aufgabenverteilung ist, und das Holistische Modell auch auf diese anwendbar ist. Zur Zeit arbeiten wir an einem Journal Article der das Holistische Modell detailliert darlegt. 
    1.39 +Während meiner Analyse von VMS stieß ich auf mehrere Problemstellen in der Theorie, und habe diese in Zusammenarbeit mit Dr. Halle gelöst. Insbesondere habe ich das Modell um das Konzept der Schichten erweitert, das dem Umstand Rechnung trägt, dass in einem System meistens mehrere hierarchisch untergeordnete Scheduler existieren. So werden die Arbeitseinheiten, über die die Laufzeitumgebung als Eins entscheidet, möglicherweise vom Betriebssystem noch einmal unterbrochen und verteilt, spätestens aber vom Prozessor in kleinere Einheiten -- Assemblerbefehle -- zerteilt, und auf unterschiedliche Funktionseinheiten aufgeteilt. Wenn man an Out-of-order Prozessoren denkt, wird deutlich, das auch dies parallele Aufgabenverteilung ist. Das Holistische Modell ist auch auf diese anwendbar. Zur Zeit arbeiten wir an einem Zeitschriftenartikel der das Holistische Modell detailliert darlegt. 
    1.40  
    1.41 -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.
    1.42 +Zu den Errungenschaften des Holistischen Modells gehören auch zwei grafische Darstellungen, die \emph{Unit Constraint Collection} und der \emph{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 (\emph{units}) die im Programm definiert werden, und die Randbedingungen (\emph{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.
    1.43  
    1.44 -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.
    1.45 +Nachdem ich bereits für die Analyse des Laufzeitverhaltens Messschnittstellen in VMS eingefügt hatte, habe ich diese Infrastruktur wiederverwendet, um aus den gewonnenen Daten die räumliche und zeitliche Platzierung der Arbeitseinheiten für den 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), modifiziert, um die Constraints zu erfassen, die für die Konstruktion der UCC und des CG notwendig sind. Schließlich erstellte ich ein Programm, das diese Aufzeichnungen entgegennehmen und UCC \& CG darstellen kann.
    1.46  
    1.47 -Quasi mit dem ersten Lauf 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 Lastenverteiler ausführt, als erster Arbeit zugeteilt bekam, und diese Arbeit dann den Verteiler für längere Zeit unterbrach, bevor er weiteren Kernen Arbeit zuteilen konnte. 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.
    1.48 -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.
    1.49 +Quasi mit dem ersten Lauf 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 Lastenverteiler ausführt, als erster Arbeit zugeteilt bekam, und diese Arbeit dann den Verteiler für längere Zeit unterbrach, bevor er weiteren Kernen Arbeit zuteilen konnte. All dies war in den vorherigen, statistischen Analysen 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) zur Visualisierung hinzugefügt hatte, wurden auch weniger offensichtliche 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.
    1.50 +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 \cite{bib:perftune}, den ich voraussichtlich im August für die PPoPP-2013 Konferenz einreichen werde.
    1.51  
    1.52 -\newpage
    1.53 +%\newpage
    1.54  
    1.55  \section{Zukünftige Aktivitäten}
    1.56  Wegen der Arbeit an zwei unvorhergesehenen Veröffentlichungen hat sich die Arbeit an der Hardwareplattform etwas verzögert, sie hat aber mein Verständnis des Problems vertieft und einige neue Blickwinkel eröffnet, die auch in das Design der Plattform einfließen.
    1.57  Aufgrund der gewonnenen Erkentnisse verändert sich mein Plan wie folgt:
    1.58  
    1.59  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 den verschiedenen Möglichkeiten der Verteilung zuwenden. 
    1.60 -Dabei wird mir das BeeFarm-multiprozessorsystem [http://www.bscmsrc.eu/sites/default/files/beefarm.pdf] als Grundlage dienen. Dieses System ist auf MIPS Prozessoren basiert, die eine Coprozessorschnittstelle enthalten, über die zusätzliche Hardwarekomponenten einfach integriert werden können. 
    1.61 +Dabei wird mir das BeeFarm-Multiprozessorsystem\cite{bib:beefarm} als Grundlage dienen, das am Fachgebiet zur Verfügung steht. Dieses System ist auf MIPS Prozessoren basiert, die eine Coprozessorschnittstelle enthalten, über die zusätzliche Hardwarekomponenten einfach integriert werden können. 
    1.62  
    1.63 -Der erste Schritt wird sein, VMS und die darauf basierten Laufzeitumgebungen (insbesondere StarSs) auf die BeeFarm-Platform zu portieren. Diese reine Software-Implementierung wird die Vergleichsbasis, gegenüber der der Effekt der unterschiedlichen Hardware\-beschleuniger\-konfigurationen gemessen werden kann.
    1.64 +Der erste Schritt wird sein, VMS und die darauf basierten Laufzeitumgebungen (insbesondere OmpSs) auf die BeeFarm-Platform zu portieren. Diese reine Software-Im\-ple\-men\-tie\-rung wird die Vergleichsbasis, gegenüber der der Effekt der unterschiedlichen Hard\-ware\-be\-schleu\-ni\-ger\-kon\-fi\-gu\-ra\-tio\-nen gemessen werden kann.
    1.65  
    1.66  Als nächstes muss ein beschleunigender Coprozessor für die Plugins erstellt werden. Dabei ist bei der Auswahl der Beschleuniger immer zu berücksichtigen, dass spezialisiertere, weniger flexible Hardware schneller ist als programmierbare, multifunktionale Hardware -- jedoch nur seltener anwendbar.
    1.67  
    1.68 -StarSs hat die komplizierteste Laufzeitaktivität unter den verfügbaren Plugins, daher werde ich hier zuerst ansetzen. Wie erwartet besteht der Großteil der StarSs-Runtimeaktivität aus dem Nachschlagen in Hashtabellen; diese werden ebenso im SSR-Plugin für die Kommunikation von Nachrichten verwendet. Hashtabellen und ähnliche Assoziativspeicher werden auch anderweitig in vielen Bereichen benutzt, von Routing in Netzwerkprotokollen [http://ccr.sigcomm.org/online/files/sigcomm302-estan.corrected.pdf] bis zu Graph-basierten Algorithmen [http://www.doc.ic.ac.uk/~natasha/fpt11bb.pdf]. Da die einfache Implementierbarkeit von VMS-Plugins besonders der Entwicklung von Domain-Spezifischen Sprachen (und den entsprechenden Laufzeitumgebungen) zugutekommt, ist es wahrscheinlich, dass ein Hashtabellenbeschleuniger auch vielen zukünftigen Plugins von Nutzen sein wird.
    1.69 +OmpSs hat die komplizierteste Laufzeitaktivität unter den verfügbaren Plugins, daher werde ich hier zuerst ansetzen. Wie erwartet besteht der Großteil der OmpSs-Runtimeaktivität aus dem Nachschlagen in Hashtabellen; diese werden ebenso im SSR-Plugin für die Kommunikation von Nachrichten verwendet. Hashtabellen und ähnliche Assoziativspeicher werden auch anderweitig in vielen Bereichen benutzt, von Routing in Netzwerkprotokollen \cite{bib:routing} bis zu Graph-basierten Algorithmen \cite{bib:graph}. Da die einfache Implementierbarkeit von VMS-Plugins besonders der Entwicklung von Domain-Spezifischen Sprachen (und den entsprechenden Laufzeitumgebungen) zugutekommt, ist es wahrscheinlich, dass ein Hashtabellenbeschleuniger auch vielen zukünftigen Plugins von Nutzen sein wird.
    1.70  
    1.71 -Überraschenderweise stellte sich auch heraus, dass das Zuteilen von Speicherplatz über \emph{malloc} relativ viel Zeit in Anspruch nimmt. Da diese Funktion in sehr vielen Laufzeitumgebungen vorkommt, und häufig in der sequentiellen oder minder parallelen Vorbereitungsphase des Programms vor dem Start der eigentlichen parallelen Arbeit benutzt wird, könnte eine Beschleunigung hier einen großen Einfluss haben.
    1.72 +Zudem stellte sich auch heraus, dass das Allozieren von Speicher über \emph{malloc} relativ viel Zeit in Anspruch nimmt. Da diese Funktion in sehr vielen Plugins enthalten ist, und häufig in der sequentiellen oder minder parallelen Vorbereitungsphase des Programms vor dem Start der eigentlichen parallelen Arbeit benutzt wird, könnte eine Beschleunigung hier einen großen Einfluss haben.
    1.73  
    1.74  Neben der Auswahl ist auch die Anzahl und Platzierung der Beschleuniger abzuwägen.
    1.75 -Im Falle von StarSs gibt es zwei zeitintensive Abläufe mit sehr unterschiedlicher Verteilbarkeit: Die Erstellung von neuen Tasks ist strikt sequentiell definiert, mit nur einem einzigen ``Master'', der neue Tasks in Auftrag geben darf. Die Zugriffsrechte der Tasks auf Ein- und Ausgangsspeicherzonen werden durch die Reihenfolge, in der sie in Auftrag gegeben wurden, bestimmt. Dieser Ablauf findet zwangsläufig nur in einem Kern statt, und ist der einzige, der neue Einträge in der Hashtabelle erstellen kann, sodass es sinnvoll erscheint, hierfür einen speziellen Coprozessor zu erstellen, der nur zu einem designierten ``Master-Kern'' hinzugefügt wird.
    1.76 -Der zweite Ablauf findet zum Ende jedes Tasks statt. Er gibt die Ein- und Ausgangsspeicherzonen auf die der Task Zugriffsrechte hatte frei und prüft nach, welche wartenden Tasks durch diese Freigaben laufbereit werden. Unter den laufbereiten Tasks muss dann einer ausgewählt und auf dem freigewordenen Kern gestartet werden. Dieser Ablauf ist der rechenintensivste in der StarSs-Laufzeitumgebung, sodass hier ein Hardwarebeschleuniger dringend notwendig ist. Er könnte entweder zentralisiert stattfinden -- die ``Arbeiter-Kerne'' müssten dann den Abschluss eines Tasks an den Master melden und auf die Zuteilung eines neuen Tasks warten -- oder dezentral auf dem Kern, der den Task beendet hat. Eine zu starke Zentralisierung führt schnell zu Engpässen, insbesondere für Programme, die viele kurze Tasks enthalten. Auf der anderen Seite wäre es aber sehr ressourcenaufwändig, jedem Kern einen Coprozessor für diesen Ablauf zur Verfügung zu stellen, und dieser wäre unbenutzt während der gesamten Rechenzeit, die im Programm verbracht wird (und dies ist die ``nützliche'' Zeit, und daher hoffentlich die überwältigende Mehrheit). An dieser Stelle wird es also ein interessanter Punkt sein, zu messen, wie viele Kerne sich einen Coprozessor teilen können, ohne dass es zu größeren Verzögerungen kommt.
    1.77 +Im Falle von OmpSs gibt es zwei zeitintensive Abläufe mit sehr unterschiedlicher Verteilbarkeit: Die Erstellung von neuen Tasks ist strikt sequentiell definiert, ausgehend von nur einem einzigen ``Master'', der neue Tasks in Auftrag geben darf. Die Zugriffsrechte der Tasks auf Ein- und Ausgangsspeicherzonen werden durch die Reihenfolge, in der sie in Auftrag gegeben wurden, bestimmt. Dieser Ablauf findet zwangsläufig nur in einem Kern statt, und ist der einzige, der neue Einträge in der Hashtabelle erstellen kann. Aus diesem Grund erscheint es sinnvoll, hierfür einen speziellen Coprozessor zu erstellen, der nur zu einem designierten ``Master-Kern'' hinzugefügt wird.
    1.78 +Der zweite Ablauf findet zum Ende jedes Tasks statt. Er gibt die Ein- und Ausgangsspeicherzonen auf die der Task Zugriffsrechte hatte frei und prüft, welche wartenden Tasks durch diese Freigaben laufbereit werden. Unter den laufbereiten Tasks wählt er einen aus und startet ihn auf dem freigewordenen Kern. Hier wäre Hardwarebeschleunigung dringend notwendig, da dieser Ablauf der rechenintensivste in der OmpSs-Laufzeitumgebung ist. Er könnte entweder zentralisiert stattfinden -- die ``Arbeiter-Kerne'' müssten dann den Abschluss eines Tasks an den Master melden und auf die Zuteilung eines neuen Tasks warten -- oder dezentral auf dem Kern, der den Task beendet hat. Eine zu starke Zentralisierung führt schnell zu Engpässen, insbesondere für Programme, die viele kurze Tasks enthalten. Auf der anderen Seite wäre es aber sehr ressourcenaufwändig, jedem Kern einen Coprozessor für diesen Ablauf zur Verfügung zu stellen. Zudem bliebe dieser ungenutzt während der gesamten Rechenzeit, die im Programm verbracht wird (und dies ist die ``nützliche'' Zeit, und daher idealerweise die überwältigende Mehrheit). An dieser Stelle wird es also ein interessanter Punkt sein, zu messen, wie viele Kerne sich einen Coprozessor teilen können, ohne dass es zu größeren Verzögerungen kommt.
    1.79  
    1.80 -Die StarSs-Laufzeitumgebung muss anschließend so angepasst werden, dass sie von den neuen Coprozessoren gebrauch machen kann. Anhand mehrerer bereits in StarSs existierender Programme, darunter Standardbenchmarks und ein H.264 Videoencoder, kann dann die Performance evaluiert werden. Um die Kosten der größeren Flexibilität zu evaluieren, kann des weiteren der StarSs-spezifische Hardwarescheduler Nexus++ herangezogen werden, der hier im Fachgebiet entwickelt wurde, und sämtliche im vorigen Absatz beschriebenen Abläufe übernimmt.
    1.81 +Die übrigen Schritte bleiben unverändert. Die OmpSs-Laufzeitumgebung muss anschließend so angepasst werden, dass sie von den neuen Coprozessoren gebrauch machen kann. Anhand mehrerer bereits in OmpSs existierender Programme, darunter Standardbenchmarks und ein H.264 Videoencoder, kann dann die Performance evaluiert werden. Um die Kosten der größeren Flexibilität zu evaluieren, kann des weiteren der OmpSs-spezifische Hardwarescheduler Nexus++ herangezogen werden, der hier im Fachgebiet entwickelt wurde, und sämtliche im vorigen Absatz beschriebenen Abläufe übernimmt.
    1.82 +
    1.83 +Zusammengefasst ergibt sich daraus der folgende Zeitplan:
    1.84 +
    1.85 +\begin{table}[h]
    1.86 +\begin{tabular}{|l|c|}
    1.87 +\hline
    1.88 +VMS und OmpSs-Plugin auf BeeFarm portieren & 3 Monate\\
    1.89 +\hline
    1.90 +Hardwarebeschleuniger implementieren & 6 Monate\\
    1.91 +\hline
    1.92 +Varianten erstellen & 3 Monate\\
    1.93 +\hline
    1.94 +Integration in VMS-OmpSs & 3 Monate\\
    1.95 +\hline
    1.96 +Test, Performanceevaluation, Optimierung & 3 Monate\\
    1.97 +\hline
    1.98 +Niederschrift & 6 Monate\\
    1.99 +\hline
   1.100 +\end{tabular}
   1.101 +\end{table}
   1.102 +
   1.103 +\begin{thebibliography}{9}
   1.104 +\bibitem{bib:perftune} Nina Engelhardt, Sean Halle, Ben Juurlink; \emph{Integrated Performance Tuning Using Semantic Information Collected by Instrumenting the Language Runtime}; in progress
   1.105 +\bibitem{bib:holistic} Sean Halle, Albert Cohen; \emph{Support of Collective Effort Towards Performance Portability}; Proceedings of 3rd USENIX Workshop on Hot Topics in Parallelism, May 2011
   1.106 +\bibitem{bib:beefarm} Nehir Sonmez, Oriol Arcas, Gokhan Sayilar, Osman S. Unsal, Adrián Cristal, Ibrahim Hur, Satnam Singh, and Mateo Valero; \emph{From plasma to beefarm: design experience of an FPGA-based multicore prototype}; Proceedings of the 7th international conference on Reconfigurable computing: architectures, tools and applications (ARC'11), 2011
   1.107 +\bibitem{bib:routing} Lorenzo De Carli, Yi Pan, Amit Kumar, Cristian Estan, Karthikeyan Sankaralingam; \emph{PLUG: Flexible Lookup Modules for Rapid Deployment of New Protocols in High-speed Routers}; SIGCOMM, August 2009
   1.108 +\bibitem{bib:graph} Betkaoui, B., Thomas, D.B., Luk, W., Przulj, N.; \emph{A framework for FPGA acceleration of large graph problems: Graphlet counting case study}; International Conference on Field-Programmable Technology (FPT), 2011 
   1.109 +\end{thebibliography}
   1.110  
   1.111  \end{document}
   1.112  
   1.113 @@ -84,4 +112,4 @@
   1.114  -- what I'm going to do next
   1.115  -build hardware, but instead of putting accelerators only on 1 master core, experiment with how often to replicate accelerators
   1.116  -assemblage of lm32 cores, each w/ non-coherent cache
   1.117 --starss? w/ message passing for in/out
   1.118 +-OmpSs? w/ message passing for in/out

     2.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     2.2 +++ b/2__Other/cv/Makefile	Mon Apr 15 12:38:12 2013 +0200
     2.3 @@ -0,0 +1,16 @@
     2.4 +TARGET=cv-nina-engelhardt.pdf
     2.5 +
     2.6 +all: $(TARGET)
     2.7 +
     2.8 +%.pdf: %.ps
     2.9 +	ps2pdf14 $<
    2.10 +
    2.11 +%.ps: %.dvi
    2.12 +	dvips -Ppdf -G0 $< -o $@
    2.13 +
    2.14 +%.dvi: %.tex
    2.15 +	latex $<
    2.16 +
    2.17 +clean:
    2.18 +	rm -f *.log *.aux $(TARGET) *.ps *.dvi
    2.19 +

     3.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     3.2 +++ b/2__Other/cv/cv-commands.tex	Mon Apr 15 12:38:12 2013 +0200
     3.3 @@ -0,0 +1,71 @@
     3.4 +% Set of commands used by cv.tex
     3.5 +
     3.6 +\usepackage[dvipsnames,usenames]{color}
     3.7 +\usepackage{simplemargins}
     3.8 +\usepackage{graphicx}
     3.9 +\setleftmargin{2.0cm}
    3.10 +\setrightmargin{2.0cm}
    3.11 +\settopmargin{2.5cm}
    3.12 +\setbottommargin{0cm}
    3.13 +%\renewcommand\familydefault{\sfdefault}
    3.14 +
    3.15 +
    3.16 +% starting commands
    3.17 +\newfont{\myfonta}{cmr10 at 9pt}
    3.18 +\newfont{\myfontb}{cmr10 at 10pt}
    3.19 +\newfont{\myfontc}{cmr10 at 15pt}
    3.20 +\newfont{\myfontd}{cmr10 at 12pt}
    3.21 +
    3.22 +\newcommand{\largeskip}[0]{\vspace{2.5mm}\\}
    3.23 +\newcommand{\shortskip}[0]{\vspace{0.4mm}\\}
    3.24 +
    3.25 +% small caps
    3.26 +\newcommand{\smcp}[1]{\sc{\myfonta{#1}}}
    3.27 +\renewcommand{\textsc}[1]{\smcp{#1}}
    3.28 +
    3.29 +\newcommand{\header}[3]{
    3.30 +\hspace{0cm}
    3.31 +\begin{tabular}{p{8cm}p{9cm}}
    3.32 +{\raggedright {\headline {#1}}
    3.33 +\\\vspace*{2mm}
    3.34 +\headline{#2}} 
    3.35 +& 
    3.36 +\raggedleft{#3}
    3.37 +\end{tabular}}
    3.38 +
    3.39 +
    3.40 +\newcommand{\blocktitle}[1]{
    3.41 +\parbox{\textwidth}{
    3.42 +	\vspace{2mm}
    3.43 +	\noindent
    3.44 +	\textcolor{MidnightBlue}{
    3.45 +{\myfontd {#1}
    3.46 +	\vspace*{1mm}
    3.47 +	\hrule}
    3.48 +	\vspace*{3mm}
    3.49 +	\noindent
    3.50 +} } }
    3.51 +
    3.52 +\newcommand{\headline}[1]{{\myfontc{#1}}}
    3.53 +\newcommand{\setmainfont}[0]{\myfontb}
    3.54 +
    3.55 +%%%%%%
    3.56 +
    3.57 +\newenvironment{resumeblock}[1]{\blocktitle{#1}\begin{tabular}{p{4cm}p{13cm}}}{\end{tabular}}
    3.58 +\newcommand{\resumeitem}[2]{\noindent\raggedright{\textsc{#1}} & #2}
    3.59 +
    3.60 +%%%%%%
    3.61 +
    3.62 +\newcommand{\interest}[2]{
    3.63 +\includegraphics[height=12pt]{#1}
    3.64 +~\raisebox{1mm}{#2}}
    3.65 +
    3.66 +%%%%%%
    3.67 +
    3.68 +\newenvironment{interestsblock}[1]
    3.69 +{\blocktitle{#1}\begin{tabular}{p{10cm}p{10cm}}}
    3.70 +{\end{tabular}}
    3.71 +
    3.72 +\setlength{\parindent}{0mm}
    3.73 +\pagestyle{empty}
    3.74 +

     4.1 Binary file 2__Other/cv/cv-nff-latex.zip has changed

     5.1 Binary file 2__Other/cv/cv-nina-engelhardt.pdf has changed

     6.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     6.2 +++ b/2__Other/cv/cv-nina-engelhardt.tex	Mon Apr 15 12:38:12 2013 +0200
     6.3 @@ -0,0 +1,99 @@
     6.4 +\documentclass[a4paper,12pt]{article}
     6.5 +\usepackage[utf8]{inputenc}
     6.6 +\usepackage[english]{babel}
     6.7 +
     6.8 +\include{cv-commands}
     6.9 +\linespread{1.1}
    6.10 +\hyphenation{de-du-cing} 
    6.11 +
    6.12 +\begin{document}
    6.13 +
    6.14 +\setmainfont
    6.15 +
    6.16 +\header
    6.17 +{Nina Engelhardt}
    6.18 +{\small PhD Student at TU Berlin}
    6.19 +{Age: 25 years old\\
    6.20 +Nationality: German\\
    6.21 +Address: Kulmer Str. 19, 10783 Berlin, Germany\\
    6.22 +Tel: +49 30 314 22288\\
    6.23 +Email: nina.engelhardt@aes.tu-berlin.de}
    6.24 +
    6.25 +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    6.26 +
    6.27 +\begin{resumeblock}{Education}
    6.28 +\resumeitem{2010}{Master of Science in Computer Science obtained with 14.23/20 points.}\\
    6.29 +\resumeitem{2008}{Bachelor of Science in Computer Science obtained with 16.04/20 points.}\\
    6.30 +\resumeitem{2007--2011}{Student at École Normale Supérieure de Cachan - Antenne de Bretagne\\& Computer Science program (in cooperation with Université Rennes 1).} \\
    6.31 +\resumeitem{2005--2007}{Attended preparatory classes at Lycée Janson de Sailly.} \\
    6.32 +\resumeitem{2005}{Baccalauréat scientifique (French high school diploma) obtained with 15.55/20 points.\\
    6.33 +&Abitur (German high school diploma) obtained with 635/840 points (1,8).\\
    6.34 +	%& Very good spoken \& written English and French. Currently studying Japanese since Oct 2007.
    6.35 +	} 
    6.36 +\largeskip
    6.37 +\end{resumeblock}
    6.38 +
    6.39 +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    6.40 +
    6.41 +\begin{resumeblock}{Skills}
    6.42 +
    6.43 +\resumeitem{Languages}{Native German. Fluent in written and spoken French and English. Intermediate Japanese.}
    6.44 +\shortskip
    6.45 +
    6.46 +\resumeitem{Programming Languages}{C, VHDL, Python, Java, C++, Caml}
    6.47 +\largeskip
    6.48 +
    6.49 +\end{resumeblock}
    6.50 +
    6.51 +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    6.52 +
    6.53 +\begin{resumeblock}{Professional experience}
    6.54 +\resumeitem{July 2011 - now}{PhD student in the Embedded Systems Architecture group at Technische Universität Berlin under Ben Juurlink. ``Hardware Acceleration for Parallel Scheduling on Multicore Systems.''}
    6.55 +\shortskip
    6.56 +
    6.57 +\resumeitem{October 2010 - June 2011}{Internship at the Institut für Technische Informatik der Universität Potsdam under Christophe Bobda. Computation pattern detection in LLVM bytecode for ASIP synthesis.}
    6.58 +\shortskip
    6.59 +
    6.60 +\resumeitem{February-July 2010}{Master's thesis at CAIRN, IRISA Rennes under Steven Derrien. ``Application of multimode HLS techniques to ASIP synthesis.''}
    6.61 +\shortskip
    6.62 +
    6.63 +\resumeitem{June-July 2009}{Fourth year internship at Zuse Institut Berlin under Thomas Steinke. Parallelizing a power simulator on SMP and GPU.}
    6.64 +\shortskip
    6.65 +
    6.66 +\resumeitem{June-July 2008}{Third year internship at CAPS, IRISA Rennes under Pierre Michaud. Examined possibilities of deducing a processor's power distribution from measurements by the internal temperature sensors.}
    6.67 +\shortskip
    6.68 +
    6.69 +\end{resumeblock}
    6.70 +
    6.71 +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    6.72 +
    6.73 +\begin{resumeblock}{Academic achievements}
    6.74 +
    6.75 +\resumeitem{2010}{Ranked 9th in Computer Science Master exams at Université Rennes 1}
    6.76 +\shortskip
    6.77 +
    6.78 +\resumeitem{2008}{Full score at TOEIC.}
    6.79 +\shortskip
    6.80 +
    6.81 +\resumeitem{2008}{Ranked 4th in Computer Science Bachelor exams at Université Rennes 1}
    6.82 +\shortskip
    6.83 +
    6.84 +\resumeitem{2007}{Passed the ENS entrance examinations and was ranked 37th out of 1,399 students.}
    6.85 +\shortskip
    6.86 +
    6.87 +\resumeitem{2004}{3rd place at Germany's national foreign language contest.}
    6.88 +\largeskip % why is the following block too high?
    6.89 +
    6.90 +\end{resumeblock}
    6.91 +
    6.92 +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    6.93 +
    6.94 +%\begin{interestsblock}{Interests \& activities}
    6.95 +%	\interest{idea}{Political philosophy and Foreign Affairs} &
    6.96 +%	\interest{gnu}{Free Software Movement}\\
    6.97 +%	&\\
    6.98 +%	\interest{hack}{Solving problems} &
    6.99 +%	\interest{bike}{Cycling!} 
   6.100 +%\end{interestsblock}
   6.101 +
   6.102 +\end{document}

     7.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     7.2 +++ b/2__Other/cv/cv-nina-engelhardt_de.tex	Mon Apr 15 12:38:12 2013 +0200
     7.3 @@ -0,0 +1,103 @@
     7.4 +\documentclass[a4paper,12pt]{article}
     7.5 +\usepackage[utf8]{inputenc}
     7.6 +\usepackage[german]{babel}
     7.7 +
     7.8 +\include{cv-commands}
     7.9 +\linespread{1.1}
    7.10 +\hyphenation{de-du-cing} 
    7.11 +
    7.12 +\begin{document}
    7.13 +
    7.14 +\setmainfont
    7.15 +
    7.16 +\header
    7.17 +{Nina Engelhardt}
    7.18 +{\small Geb. 23. 07. 1987 in Berlin}
    7.19 +{Kurmärkische Str. 5-7\\
    7.20 +10783 Berlin\\
    7.21 +nina.engelhardt@omnium-gatherum.de}
    7.22 +
    7.23 +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    7.24 +
    7.25 +\begin{resumeblock}{Studium}
    7.26 +\resumeitem{2010}{Master of Science in Informatik (Abschlussnote 14,23/20)}
    7.27 +\shortskip
    7.28 +\resumeitem{2008}{Bachelor of Science in Informatik (Abschlussnote 16,06/20)}
    7.29 +\shortskip
    7.30 +\resumeitem{2007--2010}{Informatikstudentin an der ENS Cachan Antenne de Bretagne.}
    7.31 +\shortskip
    7.32 +\resumeitem{2005--2007}{Classes préparatoires im Lycée Janson de Sailly in Paris.}
    7.33 +\shortskip
    7.34 +\resumeitem{2005}{Baccalauréat scientifique (Abschlussnote 15,55/20) \\
    7.35 +&Abitur (Abschlussnote 1,8)\\} 
    7.36 +\largeskip
    7.37 +\end{resumeblock}
    7.38 +
    7.39 +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    7.40 +
    7.41 +\begin{resumeblock}{Kenntnisse}
    7.42 +
    7.43 +\resumeitem{Sprachen}{Verhandlungs- und vertragssicher in Wort und Schrift in Französisch und Englisch. Grundkenntnisse in Japanisch.}
    7.44 +\shortskip
    7.45 +
    7.46 +\resumeitem{Programmiersprachen}{Caml, Java, C, C++, Antlr, Bash, Python\\}
    7.47 +%\shortskip
    7.48 +%
    7.49 +%\resumeitem{Betriebssysteme}{Mac OS X, Linux}
    7.50 +%\shortskip
    7.51 +%
    7.52 +%\resumeitem{Weiteres}{\LaTeX, Adobe Photoshop}
    7.53 +\largeskip
    7.54 +
    7.55 +\end{resumeblock}
    7.56 +
    7.57 +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    7.58 +
    7.59 +\begin{resumeblock}{Berufliche Erfahrungen}
    7.60 +
    7.61 +\resumeitem{Februar-Juli 2010}{Masterarbeit in der Forschergruppe CAIRN, IRISA Rennes. ``Application of multimode HLS techniques to ASIP synthesis.''}
    7.62 +\shortskip
    7.63 +
    7.64 +\resumeitem{Juni-Juli 2009}{Praktikum am Zuse Institut Berlin. ``Kernel evaluation on GPUs''}
    7.65 +\shortskip
    7.66 +
    7.67 +\resumeitem{Juni-Juli 2008}{Praktikum in der Forschergruppe CAPS, IRISA Rennes. ``Possibilities of deducing a processor's power distribution from measurements by the internal temperature sensors.''}
    7.68 +\shortskip
    7.69 +
    7.70 +\resumeitem{July-August 2003}{Freiwillige Helferin in der Camphill Communities East Anglia Lebensgemeinschaft für Behinderte Personen.\\}
    7.71 +\largeskip
    7.72 +
    7.73 +\end{resumeblock}
    7.74 +
    7.75 +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    7.76 +
    7.77 +\begin{resumeblock}{Bedeutende Leistungen}
    7.78 +
    7.79 +\resumeitem{2010}{Rang 8 im Masterexamen.}
    7.80 +\shortskip
    7.81 +
    7.82 +\resumeitem{2008}{100\% im TOEIC.}
    7.83 +\shortskip
    7.84 +
    7.85 +\resumeitem{2008}{Rang 4 im Bachelorexamen.}
    7.86 +\shortskip
    7.87 +
    7.88 +\resumeitem{2007}{Rang 37 von 1,399 im Eintrittsexamen der ENS Cachan.}
    7.89 +\shortskip
    7.90 +
    7.91 +\resumeitem{2004}{3. Platz im Bundesfremdsprachenwettbewerb mit den Sprachen Französisch und Englisch.}
    7.92 +\largeskip % why is the following block too high?
    7.93 +
    7.94 +\end{resumeblock}
    7.95 +
    7.96 +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
    7.97 +
    7.98 +%\begin{interestsblock}{Interests \& activities}
    7.99 +%	\interest{idea}{Political philosophy and Foreign Affairs} &
   7.100 +%	\interest{gnu}{Free Software Movement}\\
   7.101 +%	&\\
   7.102 +%	\interest{hack}{Solving problems} &
   7.103 +%	\interest{bike}{Cycling!} 
   7.104 +%\end{interestsblock}
   7.105 +
   7.106 +\end{document}

     8.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     8.2 +++ b/2__Other/cv/simplemargins.sty	Mon Apr 15 12:38:12 2013 +0200
     8.3 @@ -0,0 +1,88 @@
     8.4 +% simplemargins.sty
     8.5 +%
     8.6 +%   by Jonathan Kamens (jik@GZA.COM)
     8.7 +%   March 15, 1993
     8.8 +%
     8.9 +% This is something that non-hacker-type \LaTeX users have needed for
    8.10 +% a long time.  It's just really stupid to have to explain how all of
    8.11 +% the page dimensions work, and how to use \setlength and \addtolength
    8.12 +% to change them, evey time someone who doesn't really care about it
    8.13 +% wants to change their margins.  This file gives them the ability to
    8.14 +% do that easily.
    8.15 +%
    8.16 +% \setleftmargin{dimen} sets the left margin to that width
    8.17 +% \setrightmargin{dimen} sets the right margin to that width
    8.18 +% \settopmargin{dimen} sets the top margin to that width
    8.19 +% \setbottommargin{dimen} sets the bottommargin to that width
    8.20 +% \setallmargins{dimen} sets all four margins to that width
    8.21 +% 
    8.22 +% \setpagewidth{dimen} sets the page width to that width
    8.23 +% \setpageheight{dimen} sets the page height to that width
    8.24 +% 
    8.25 +% The page is assumed to be 8.5 x 11 when this file is initially
    8.26 +% loaded.  If this is not the case, then use
    8.27 +% 
    8.28 +% 	\setlength{\smpagewidth}{dimen}
    8.29 +%	\setlength{\smpageheight}{dimen}
    8.30 +% 
    8.31 +% after loading simplemargins to set the actual page width and height,
    8.32 +% before using any of the other simplemargins command (*including*
    8.33 +% \setpagewidth or \setpageheight, which depend on the previous values
    8.34 +% for \smpagewidth and \smpageheight).
    8.35 +
    8.36 +\typeout{Simplemargins margin control commands <15 Mar 93>.}
    8.37 +
    8.38 +\newlength{\smpagewidth}
    8.39 +\newlength{\smpageheight}
    8.40 +
    8.41 +\setlength{\smpagewidth}{8.5in}
    8.42 +\setlength{\smpageheight}{11in}
    8.43 +
    8.44 +\newcommand{\setpagewidth}[1]{
    8.45 +	\addtolength{\smpagewidth}{-#1}
    8.46 +	\addtolength{\textwidth}{-\smpagewidth}
    8.47 +	\setlength{\smpagewidth}{#1}
    8.48 +}
    8.49 +\newcommand{\setpageheight}[1]{
    8.50 +	\addtolength{\smpageheight}{-#1}
    8.51 +	\addtolength{\textheight}{-\smpageheight}
    8.52 +	\setlength{\smpageheight}{#1}
    8.53 +}
    8.54 +\newcommand{\setleftmargin}[1]{
    8.55 +	\addtolength{\textwidth}{\oddsidemargin}
    8.56 +	\addtolength{\textwidth}{1in}
    8.57 +	\addtolength{\textwidth}{-#1}
    8.58 +	\setlength{\oddsidemargin}{-1in}
    8.59 +	\addtolength{\oddsidemargin}{#1}
    8.60 +	\setlength{\evensidemargin}{\oddsidemargin}
    8.61 +}
    8.62 +\newcommand{\setrightmargin}[1]{
    8.63 +	\setlength{\textwidth}{\smpagewidth}
    8.64 +	\addtolength{\textwidth}{-\oddsidemargin}
    8.65 +	\addtolength{\textwidth}{-1in}
    8.66 +	\addtolength{\textwidth}{-#1}
    8.67 +}
    8.68 +\newcommand{\settopmargin}[1]{
    8.69 +	\addtolength{\textheight}{\topmargin}
    8.70 +	\addtolength{\textheight}{1in}
    8.71 +	\addtolength{\textheight}{\headheight}
    8.72 +	\addtolength{\textheight}{\headsep}
    8.73 +	\addtolength{\textheight}{-#1}
    8.74 +	\setlength{\topmargin}{-1in}
    8.75 +	\addtolength{\topmargin}{-\headheight}
    8.76 +	\addtolength{\topmargin}{-\headsep}
    8.77 +	\addtolength{\topmargin}{#1}
    8.78 +}
    8.79 +\newcommand{\setbottommargin}[1]{
    8.80 +	\setlength{\textheight}{\smpageheight}
    8.81 +	\addtolength{\textheight}{-\topmargin}
    8.82 +	\addtolength{\textheight}{-1in}
    8.83 +	\addtolength{\textheight}{-\footskip}
    8.84 +	\addtolength{\textheight}{-#1}
    8.85 +}
    8.86 +\newcommand{\setallmargins}[1]{
    8.87 +	\settopmargin{#1}
    8.88 +	\setbottommargin{#1}
    8.89 +	\setleftmargin{#1}
    8.90 +	\setrightmargin{#1}
    8.91 +}

     9.1 Binary file 2__Other/jsps_proposal/promotionsabsicht.odt has changed

    10.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
    10.2 +++ b/2__Other/jsps_proposal/research plan	Mon Apr 15 12:38:12 2013 +0200
    10.3 @@ -0,0 +1,34 @@
    10.4 +15. Research Plan in Japan
    10.5 +a.  Present research related to research plan
    10.6 +
    10.7 +I am currently working on a PhD in the domain of runtimes for parallel programming models. The object of my research is to improve the VMS runtime framework. VMS addresses the productivity gap between sequential and parallel programming. The difficulty of parallel programming is reduced when the programming model offers high-level concepts that closely match the application's concepts. However, the more specialized a programming model is, the less users it has, and so less effort can be spent on developing the model due to diminishing returns (it becomes useless when the time to write the runtime is larger than the extra time it takes to write the applications in a less suitable model).
    10.8 +
    10.9 +VMS brings the simplicity of sequential programming to the development of parallel runtimes by providing a base layer that takes charge of the most difficult aspect, synchronization. Building on this, the runtime writer only needs to provide specific methods in the form of a plugin to support a certain programming model. These plugin methods are easy to write because they need to be neither thread-safe nor reentrant.
   10.10 +
   10.11 +I have been evaluating the performance of the current VMS implementation. It was designed for cache-coherent shared memory machines not exceeding a dozen cores and performs well on these machines, offering comparable performance to the default runtime libraries for models such as OmpSs. However, some of the assumptions in the VMS abstractions are unsuited to larger and/or distributed systems. Preparing for the research to take place during the exchange period, additional benchmarks using different combinations of features will be developed to evaluate the runtime's performance, and establish a baseline to compare improvements to. Next, a distributed version of VMS will be developed. The goal is to have a first working implementation ready that will be improved using the combined knowledge of distributed systems at TokyoTech and parallel runtimes at TU Berlin.
   10.12 +
   10.13 +b.  Purpose of proposed research
   10.14 +
   10.15 +Often, a significant part of the runtime overhead is spent on ensuring compatibility with a wide range of features of the programming model, or even with other programming models, even though most of these features will not be used in this particular application. If the runtime could know if these features were needed or not, it would be possible to reduce overhead by eliding the unnecessary functionalities.
   10.16 +
   10.17 +The proposed research will enable building modularized runtimes that can load a reduced feature set based on the developer's indication of which features they wish to use. A further aim is to allow development of  hardware support that can be flexibly used by replacing selected runtime models with ones taking advantage of special-purpose hardware when it is available.
   10.18 +
   10.19 +c.  Proposed plan
   10.20 +
   10.21 +Main tasks during the research stay:
   10.22 +	- Define a set of basic abstractions suited to distributed systems that enable plugins for many different programming models. These abstractions should support several goals:
   10.23 +		1. Generality: allow implementation of different types of programming models (thread-based, task-based, dataflow, ...)
   10.24 +		2. Simplicity: present only very few basic abstractions that can be quickly understood
   10.25 +		3. Modularity: encourage separation of the different runtime functionalities. Modularity enables two approaches to boost performance. One is to selectively load only the necessary functionalities for a specific application, eschewing overhead due to preparing features that are never actually used. The other is to make it easier to integrate specialized hardware that can support specific runtime functions.
   10.26 +
   10.27 +Possibly offer simplified abstractions for common models (thread- and task-based programming models in particular).
   10.28 +
   10.29 +	- Develop a modularized plugin for the OmpSs programming model using the new abstractions. This programming model will serve as case study to evaluate the suitability of the abstractions both from a productivity and from a performance perspective.
   10.30 +
   10.31 +d.  Expected results and impacts
   10.32 +
   10.33 +The expected immediate benefit is to have a runtime whose overhead is proportional to the featureset actually used by the application. This allows the usage of powerful programming models for a larger group of applications.
   10.34 +
   10.35 +This work will also enable important future research both at TokyoTech and TU Berlin. Future plans are to use the improved VMS platform to develop runtimes that can automatically adjust task size to different systems' capabilities (number of cores, computation vs. communication speed, etc). It will also serve to develop a set of hardware accelerators for schedulers.
   10.36 +
   10.37 +The embedded systems of tomorrow are increasingly resembling the high-performance systems of today, and both domains share the drive to extract maximum performance from the systems. Combining the experience and techniques from both domains is profitable for both sides.