DE212021000487U1

DE212021000487U1 - Aufgabenplanung zur Laufzeit durch Nachahmungslernen für heterogene Systeme mit vielen Kernen

Info

Publication number: DE212021000487U1
Application number: DE212021000487.3U
Authority: DE
Original assignee: Arizona Board of Regents of University of Arizona; Carnegie Mellon University; University of Texas System; University of Arizona; Arizona State University ASU
Current assignee: Arizona Board of Regents of University of Arizona; Carnegie Mellon University; University of Texas System; University of Arizona; Arizona State University ASU
Priority date: 2020-10-22
Filing date: 2021-10-22
Publication date: 2023-07-10
Anticipated expiration: 2031-10-23
Also published as: US20230401092A1; TW202236141A; WO2022087415A1

Abstract

Ein Rahmenwerk für die Anwendungsplanung, das Folgendes umfasst:
einen heterogenen System-on-Chip (SoC)-Simulator, der so konfiguriert ist, dass er eine Vielzahl von Planungsalgorithmen für eine Vielzahl von Anwendungsaufgaben simuliert; und
ein Orakel, das so konfiguriert ist, dass es Aktionen für die Aufgabenplanung während der Laufzeit vorhersagt; und
einen Richtliniengenerator für Imitationslernen (IL), der so konfiguriert ist, dass er IL-Richtlinien für die Aufgabenplanung während der Laufzeit auf einem heterogenen SoC erzeugt, wobei die IL-Richtlinien unter Verwendung des Orakels und des SoC-Simulators trainiert werden.

Description

Unterstützung durch die Regierung
Diese Erfindung wurde mit staatlicher Unterstützung unter FA8650-18-2-7860 von der Defense Advanced Research Projects Agency gemacht. Die Regierung hat bestimmte Rechte an der Erfindung.
Verwandte Anwendungen
Diese Anmeldung beansprucht die Vorteile der vorläufigen Patentanmeldung mit der Seriennummer 63/104.260 , die am 22. Oktober 2020 eingereicht wurde und deren Offenbarung hiermit durch Bezugnahme in vollem Umfang aufgenommen wird.
Bereich der Offenlegung
Die vorliegende Offenbarung bezieht sich auf die Planung von Anwendungsaufgaben in Computersystemen.
Hintergrund
Homogene Multi-Core-Architekturen haben die Parallelität auf Thread- und Datenebene erfolgreich genutzt, um eine Leistung und Energieeffizienz zu erreichen, die über die Grenzen von Single-Core-Prozessoren hinausgeht. Während die Mehrzweckverarbeitung eine flexible Programmierung ermöglicht, leidet sie im Vergleich zu Speziallösungen unter erheblichen Leistungs- und Energieeffizienzproblemen. Bereichsspezifische Architekturen wie Grafikprozessoren (GPUs) und Prozessoren für neuronale Netze gelten als einige der vielversprechendsten Lösungen zur Verringerung dieser Lücke. Domänenspezifische Systems-on-Chip (DSSoCs), ein konkretes Beispiel für diese neue Architektur, kombinieren auf sinnvolle Weise Mehrzweckkerne, Spezialprozessoren und Hardwarebeschleuniger. DSSoCs nähern sich der Effizienz von Lösungen mit festen Funktionen für einen bestimmten Bereich an, während die Flexibilität der Programmierung für andere Bereiche erhalten bleibt.
Der Erfolg von DSSoCs hängt entscheidend davon ab, dass zwei miteinander verknüpfte Anforderungen erfüllt werden. Erstens müssen die verfügbaren Verarbeitungselemente (PEs) zur Laufzeit optimal genutzt werden, um die eingehenden Anwendungsaufgaben auszuführen. So kann es beispielsweise funktionieren, alle Tasks auf Allzweck-Cores zu verteilen, was jedoch die Vorteile der Spezial-PEs schmälert. Ebenso könnte eine statische Zuordnung von Aufgaben zu PEs die parallelen Instanzen derselben Aufgabe unnötigerweise abwürgen. Zweitens muss die Beschleunigung der domänenspezifischen Anwendungen für die Anwendungsentwickler unbemerkt bleiben, damit DSSoCs praktikabel sind.
Das Aufgabenplanungsproblem umfasst die Zuweisung von Aufgaben an PEs und die Anordnung ihrer Ausführung, um die Optimierungsziele zu erreichen, z. B. die Minimierung der Ausführungszeit, der Verlustleistung oder des Energieverbrauchs. Zu diesem Zweck werden Anwendungen durch mathematische Modelle abstrahiert, wie z. B. gerichtete azyklische Graphen (DAG) und synchrone Datengraphen (SDG), die sowohl die Attribute der einzelnen Aufgaben (z. B. erwartete Ausführungszeit) als auch die Abhängigkeiten zwischen den Aufgaben erfassen. Die Planung dieser Aufgaben auf die verfügbaren PEs ist ein bekanntes NP-komplettes Problem. Ein optimaler statischer Zeitplan kann für kleine Problemgrößen mit Hilfe von Optimierungstechniken wie der gemischt-ganzzahligen Programmierung (MIP) und der beschränkten Programmierung (CP) gefunden werden. Diese Ansätze sind aus zwei grundlegenden Gründen nicht auf die Laufzeitplanung anwendbar. Erstens verlieren statisch berechnete Zeitpläne in einer dynamischen Umgebung, in der Aufgaben aus mehreren Anwendungen parallel laufen und sich die PE-Auslastung dynamisch ändert, an Bedeutung. Zweitens kann die Ausführungszeit dieser Algorithmen und damit ihr Overhead selbst bei kleinen Problemgrößen mit einigen Dutzend Aufgaben unerschwinglich sein. Daher werden in der Praxis für homogene Systeme eine Reihe von heuristischen Schedulern wie Shortest Job First (SJF) und Complete Fair Scheduler (CFS) verwendet. Diese Algorithmen bieten einen Kompromiss zwischen der Qualität der Zeitplanungsentscheidungen und dem Rechenaufwand.
Zusammenfassung
Die Laufzeitplanung von Aufgaben unter Verwendung von Imitationslernen (IL) für heterogene Systeme mit vielen Kernen wird vorgestellt. Domänenspezifische Systems-on-Chip (DSSoCs), eine Klasse von heterogenen Many-Core-Systemen, gelten als ein wichtiger Ansatz, um die Leistungs- und Energieeffizienzlücke zwischen kundenspezifischen Hardware-Beschleunigern und programmierbaren Prozessoren zu schließen. Die Ausschöpfung des vollen Potenzials dieser Architekturen hängt entscheidend davon ab, dass die Anwendungen zur Laufzeit optimal auf die verfügbaren Ressourcen verteilt werden. Bestehende optimierungsbasierte Techniken können dieses Ziel aufgrund der kombinatorischen Natur des Aufgabenplanungsproblems zur Laufzeit nicht erreichen. In einem hier beschriebenen beispielhaften Aspekt wird die Planung als Klassifizierungsproblem dargestellt, und es wird ein hierarchischer IL-basierter Planer vorgeschlagen, der von einem Orakel lernt, um die Leistung mehrerer domänenspezifischer Anwendungen zu maximieren. Umfangreiche Evaluierungen mit sechs Streaming-Anwendungen aus den Bereichen drahtlose Kommunikation und Radar zeigen, dass der vorgeschlagene IL-basierte Scheduler eine Offline-Orakel-Policy mit mehr als 99 % Genauigkeit für leistungs- und energiebasierte Optimierungsziele approximiert. Darüber hinaus erreicht er eine fast identische Leistung wie das Orakel mit einem geringen Laufzeit-Overhead und passt sich erfolgreich an neue Anwendungen, Many-Core-Systemkonfigurationen und Laufzeitvariationen der Anwendungsmerkmale an.
Eine beispielhafte Ausführungsform stellt ein Verfahren zur Laufzeit-Aufgabenplanung in einem heterogenen Multi-Core-Rechnersystem bereit. Das Verfahren umfasst das Erhalten einer Anwendung, die eine Vielzahl von Aufgaben umfasst, das Erhalten von IL-Richtlinien für die Aufgabenplanung und das Planen der Vielzahl von Aufgaben auf einem heterogenen Satz von Verarbeitungselementen gemäß den IL-Richtlinien.
Eine weitere beispielhafte Ausführungsform stellt einen Rahmen für die Anwendungsplanung bereit. Das Anwendungs-Scheduling-Framework umfasst einen heterogenen System-on-Chip (SoC)-Simulator, der so konfiguriert ist, dass er eine Vielzahl von Scheduling-Algorithmen für eine Vielzahl von Anwendungsaufgaben simuliert. Der Anwendungsplanungsrahmen umfasst ferner ein Orakel, das so konfiguriert ist, dass es Aktionen für die Aufgabenplanung während der Laufzeit vorhersagt, und einen IL-Richtliniengenerator, der so konfiguriert ist, dass er IL-Richtlinien für die Aufgabenplanung während der Laufzeit auf einem heterogenen SoC erzeugt, wobei die IL-Richtlinien unter Verwendung des Orakels und des SoC-Simulators trainiert werden.
Diejenigen, die auf dem Gebiet der Technik erfahren sind, werden den Umfang der vorliegenden Offenbarung zu schätzen wissen und zusätzliche Aspekte davon erkennen, nachdem sie die folgende detaillierte Beschreibung der bevorzugten Ausführungsformen in Verbindung mit den begleitenden Zeichnungsfiguren gelesen haben.
Figurenliste
Die beigefügten Zeichnungen, die Bestandteil dieser Beschreibung sind, veranschaulichen verschiedene Aspekte der Offenbarung und dienen zusammen mit der Beschreibung zur Erläuterung der Grundsätze der Offenbarung.

ist ein schematisches Diagramm eines beispielhaften gerichteten azyklischen Graphen (DAG) zur Modellierung einer Streaming-Anwendung mit sieben Anwendungsaufgaben.
ist ein Beispiel für einen Zeitplan der DAG aus auf einem heterogenen System mit vielen Kernen.
ist ein schematisches Diagramm eines beispielhaften Rahmens für Imitationslernen (IL) zur Aufgabenplanung in einem heterogenen System mit vielen Kernen.
ist ein schematisches Diagramm einer beispielhaften Konfiguration einer anderen heterogenen Multi-Core-Plattform, die für Scheduler-Evaluierungen verwendet wird.
ist eine grafische Darstellung, in der die durchschnittliche Laufzeit pro Planungsentscheidung für verschiedene Anwendungen mit einem Constraint Programming (CP)-Solver mit einer einminütigen Zeitüberschreitung (CP_1-min), einem CP-Solver mit einer fünfminütigen Zeitüberschreitung (CP_5-min) und einem ETF-Scheduler (earliest task first) verglichen wird.
ist eine grafische Darstellung, in der die durchschnittliche Ausführungszeit der Anwendungen für verschiedene Anwendungen mit Orakel, IL (vorgeschlagen) und IL-Richtlinien mit Teilmengen von Merkmalen verglichen wird.
ist eine grafische Darstellung, in der die durchschnittliche Auftragsausführungszeit zwischen Orakel, CP-Lösungen und IL-Richtlinien zur Planung einer Arbeitslast mit einer Mischung aus sechs Streaming-Anwendungen verglichen wird.
ist eine grafische Darstellung, in der die durchschnittliche Verlangsamung von IL-LOO und der vorgeschlagenen Strategie mit DAgger-Load-One-Out (IL-LOO-DAgger) mit dem Orakel verglichen wird.
ist eine grafische Darstellung der durchschnittlichen Auftragsausführungszeiten für die Orakel-, Baseline-IL- sowie IL-LOO- und IL-LOO-DAgger-Iterationen, wobei eine WiFi-Senderanwendung (WiFi-TX) weggelassen wurde.
ist eine grafische Darstellung der durchschnittlichen Auftragsausführungszeiten für die Orakel-, Baseline-IL- sowie IL-LOO- und IL-LOO-DAgger-Iterationen, wobei eine WiFi-Empfängeranwendung (WiFi-RX) weggelassen wurde.
ist eine grafische Darstellung der durchschnittlichen Auftragsausführungszeiten für die Orakel-, Baseline-IL- sowie IL-LOO- und IL-LOO-DAgger-Iterationen, wobei die Anwendung zur Entfernungserkennung (RangeDet) weggelassen wurde.
ist eine grafische Darstellung der durchschnittlichen Auftragsausführungszeiten für die Orakel-, Baseline-IL- sowie IL-LOO- und IL-LOO-DAgger-Iterationen, wobei eine Single-Carrier-Transmitter-Anwendung (SC-TX) weggelassen wurde.
ist eine grafische Darstellung der durchschnittlichen Auftragsausführungszeiten für die Orakel-, Baseline-IL- sowie IL-LOO- und IL-LOO-DAgger-Iterationen, wobei eine Anwendung mit einem Einzelträgerempfänger (SC-RX) ausgelassen wurde.
ist eine grafische Darstellung der durchschnittlichen Auftragsausführungszeiten für die Orakel-, Baseline-IL- sowie IL-LOO- und IL-LOO-DAgger-Iterationen, wobei eine zeitliche Abschwächungsanwendung (TempMit) weggelassen wurde.
ist eine grafische Darstellung einer IL-Policy-Evaluierung mit verschiedenen Multi-Core-Plattformkonfigurationen.
ist eine grafische Darstellung, in der die durchschnittliche Verlangsamung für jede der 50 verschiedenen Arbeitslasten (dargestellt als W-1, W-2 usw.) normalisiert auf IL-DAgger-Richtlinien mit dem Orakel verglichen wird.
ist eine grafische Darstellung der durchschnittlichen Ausführungszeit der Arbeitslast mit Orakeln und IL-Richtlinien für die Ziele Leistung, Energie-Verzögerungs-Produkt (EDP) und Energie-Verzögerungs-Produkt² (ED²P).
ist eine grafische Darstellung des durchschnittlichen Energieverbrauchs der Arbeitslast mit Orakeln und IL-Richtlinien für die Ziele Leistung, EDP und ED² P.
ist eine grafische Darstellung, die die durchschnittliche Ausführungszeit zwischen Orakel-, IL- und Reinforcement Learning (RL)-Politiken vergleicht, um eine Arbeitslast zu planen, die eine Mischung aus sechs realen Streaming-Anwendungen umfasst.
ist ein Blockdiagramm eines Computersystems 1300, das für die Implementierung von Laufzeit-Task-Scheduling mit IL gemäß den hier offengelegten Ausführungsformen geeignet ist.

Detaillierte Beschreibung
Die nachstehend beschriebenen Ausführungsformen stellen die notwendigen Informationen dar, die es dem Fachmann ermöglichen, die Ausführungsformen in die Praxis umzusetzen, und veranschaulichen die beste Art der Umsetzung der Ausführungsformen. Nach dem Lesen der folgenden Beschreibung im Lichte der beigefügten Zeichnungen wird der Fachmann die Konzepte der Offenbarung verstehen und Anwendungen dieser Konzepte erkennen, die hier nicht speziell behandelt werden. Es sollte klar sein, dass diese Konzepte und Anwendungen in den Anwendungsbereich der Offenbarung und der beigefügten Ansprüche fallen.
Es versteht sich von selbst, dass, obwohl die Begriffe „erstes“, „zweites“ usw. hier zur Beschreibung verschiedener Elemente verwendet werden können, diese Elemente durch diese Begriffe nicht eingeschränkt werden sollten. Diese Begriffe werden nur verwendet, um ein Element von einem anderen zu unterscheiden. So kann beispielsweise ein erstes Element als zweites Element bezeichnet werden, und ebenso kann ein zweites Element als erstes Element bezeichnet werden, ohne dass dies den Rahmen der vorliegenden Offenbarung sprengen würde. Wie hierin verwendet, schließt der Begriff „und/oder“ alle Kombinationen eines oder mehrerer der aufgeführten Elemente ein.
Wenn ein Element wie eine Schicht, ein Bereich oder ein Substrat als „auf“ einem anderen Element liegend oder sich „auf” einem anderen Element erstreckend bezeichnet wird, kann es direkt auf dem anderen Element liegen oder sich direkt auf dieses erstrecken, oder es können auch dazwischenliegende Elemente vorhanden sein. Wird ein Element dagegen als „direkt auf“ oder sich „direkt auf” ein anderes Element erstreckend bezeichnet, sind keine dazwischenliegenden Elemente vorhanden. Wenn ein Element, wie z. B. eine Schicht, ein Bereich oder ein Substrat, als „über“ einem anderen Element liegend oder sich „über“ ein anderes Element erstreckend bezeichnet wird, kann es sich direkt über dem anderen Element befinden oder sich direkt über dieses erstrecken, oder es können auch dazwischenliegende Elemente vorhanden sein. Im Gegensatz dazu sind keine Zwischenelemente vorhanden, wenn ein Element als „direkt über“ oder „direkt über“ einem anderen Element liegend bezeichnet wird. Wenn ein Element als „verbunden“ oder „gekoppelt“ mit einem anderen Element bezeichnet wird, kann es direkt mit dem anderen Element verbunden oder gekoppelt sein oder es können Zwischenelemente vorhanden sein. Wird ein Element hingegen als „direkt verbunden“ oder „direkt gekoppelt“ mit einem anderen Element bezeichnet, sind keine Zwischenelemente vorhanden.
Relative Begriffe wie „unten“ oder „oben“ oder „oben“ oder „unten“ oder „horizontal“ oder „vertikal“ können hier verwendet werden, um die Beziehung eines Elements, einer Schicht oder eines Bereichs zu einem anderen Element, einer anderen Schicht oder einem anderen Bereich, wie in den Abbildungen dargestellt, zu beschreiben. Es versteht sich von selbst, dass diese und die oben genannten Begriffe neben der in den Abbildungen dargestellten Ausrichtung auch andere Ausrichtungen der Vorrichtung umfassen sollen.
Die hier verwendete Terminologie dient nur der Beschreibung bestimmter Ausführungsformen und ist nicht als Einschränkung der Offenbarung zu verstehen. Die hier verwendeten Singularformen „ein“, „ein“ und „die“ schließen auch die Pluralformen ein, sofern aus dem Kontext nicht eindeutig etwas anderes hervorgeht. Es versteht sich ferner, dass die Begriffe „umfasst“, „umfassend“, „beinhaltet“ und/oder „einschließlich“, wenn sie hier verwendet werden, das Vorhandensein bestimmter Merkmale, ganzer Zahlen, Schritte, Operationen, Elemente und/oder Komponenten spezifizieren, aber das Vorhandensein oder Hinzufügen eines oder mehrerer anderer Merkmale, ganzer Zahlen, Schritte, Operationen, Elemente, Komponenten und/oder Gruppen davon nicht ausschließen.
Sofern nicht anders definiert, haben alle hier verwendeten Begriffe (einschließlich technischer und wissenschaftlicher Begriffe) die gleiche Bedeutung, wie sie von einem Fachmann auf dem Gebiet, zu dem diese Offenbarung gehört, allgemein verstanden wird. Es versteht sich ferner, dass die hier verwendeten Begriffe so ausgelegt werden sollten, dass sie eine Bedeutung haben, die mit ihrer Bedeutung im Kontext dieser Spezifikation und des relevanten Stands der Technik übereinstimmt, und nicht in einem idealisierten oder übermäßig formalen Sinne interpretiert werden, sofern dies hier nicht ausdrücklich definiert ist.
Die Laufzeitplanung von Aufgaben unter Verwendung von Imitationslernen (IL) für heterogene Systeme mit vielen Kernen wird vorgestellt. Domänenspezifische Systems-on-Chip (DSSoCs), eine Klasse von heterogenen Many-Core-Systemen, gelten als ein wichtiger Ansatz, um die Leistungs- und Energieeffizienzlücke zwischen kundenspezifischen Hardware-Beschleunigern und programmierbaren Prozessoren zu verringern. Die Ausschöpfung des vollen Potenzials dieser Architekturen hängt entscheidend davon ab, dass die Anwendungen zur Laufzeit optimal auf die verfügbaren Ressourcen verteilt werden. Bestehende optimierungsbasierte Techniken können dieses Ziel aufgrund der kombinatorischen Natur des Aufgabenplanungsproblems zur Laufzeit nicht erreichen. In einem hier beschriebenen beispielhaften Aspekt wird die Planung als Klassifizierungsproblem dargestellt, und es wird ein hierarchischer IL-basierter Planer vorgeschlagen, der von einem Orakel lernt, um die Leistung mehrerer domänenspezifischer Anwendungen zu maximieren. Umfangreiche Evaluierungen mit sechs Streaming-Anwendungen aus den Bereichen drahtlose Kommunikation und Radar zeigen, dass der vorgeschlagene IL-basierte Scheduler eine Offline-Orakel-Policy mit mehr als 99 % Genauigkeit für leistungs- und energiebasierte Optimierungsziele approximiert. Darüber hinaus erreicht er eine fast identische Leistung wie das Orakel mit einem geringen Laufzeit-Overhead und passt sich erfolgreich an neue Anwendungen, Many-Core-Systemkonfigurationen und Laufzeitvariationen der Anwendungsmerkmale an.
I. Einführung
Die vorliegende Offenlegung befasst sich mit der folgenden anspruchsvollen Aufgabe: Kann eine Scheduler-Leistung erreicht werden, die nahe an die von optimalen MIP- und CP-Schedulern heranreicht, und zwar bei minimalem Laufzeit-Overhead im Vergleich zu den üblicherweise verwendeten Heuristiken? Außerdem wird dieses Problem im Zusammenhang mit heterogenen Verarbeitungselementen (PEs) untersucht. Ein Großteil des Schedulings in heterogenen Systemen mit vielen Kernen wird bis heute manuell abgestimmt. So überlässt beispielsweise OpenCL, ein weit verbreitetes Programmiermodell für heterogene Kerne, das Scheduling-Problem den Programmierern. Experten optimieren die Zuordnung von Aufgaben zu Ressourcen manuell auf der Grundlage ihrer Kenntnisse über die Anwendung(en), die Merkmale der heterogenen Cluster, die Datenübertragungskosten und die Plattformarchitektur. Die manuelle Optimierung leidet jedoch aus zwei Gründen unter der Skalierbarkeit. Erstens sind Optimierungen nicht für alle Anwendungen gut skalierbar. Zweitens ist ein hoher technischer Aufwand erforderlich, um die Lösungen an verschiedene Plattformarchitekturen und unterschiedliche Grade der Gleichzeitigkeit in Anwendungen anzupassen. Daher besteht ein dringender Bedarf an einer Methodik zur Bereitstellung optimierter Scheduling-Lösungen, die für eine Vielzahl von Anwendungen zur Laufzeit in heterogenen Many-Core-Systemen geeignet sind.
Die Zeitplanung wird traditionell als ein Optimierungsproblem betrachtet. In einem beispielhaften Aspekt ändert die vorliegende Offenlegung diese Perspektive, indem sie die Laufzeitplanung für heterogene Multicore-Plattformen als Klassifizierungsproblem formuliert. Diese Sichtweise und die folgenden Schlüsselerkenntnisse ermöglichen den Einsatz von Techniken des maschinellen Lernens (ML) zur Lösung dieses Problems:

Schlüsselerkenntnis 1: Man kann einen optimalen (oder nahezu optimalen) Scheduling-Algorithmus offline verwenden, ohne durch Rechenzeit und andere Laufzeit-Overheads eingeschränkt zu sein. Anschließend können die Eingaben in diesen Planer und seine Entscheidungen zusammen mit den relevanten Merkmalen aufgezeichnet werden, um ein Orakel zu erstellen.
Schlüsselerkenntnis 2: Man kann eine Strategie entwerfen, die das Orakel mit minimalem Aufwand approximiert, und diese Strategie zur Laufzeit verwenden.
Schlüsselerkenntnis 3: Man kann die Effektivität von ML nutzen, um aus dem Orakel mit verschiedenen Zielen zu lernen, z. B. Minimierung der Ausführungszeit und des Energieverbrauchs usw.

Die Verwirklichung dieser Vision erfordert die Bewältigung mehrerer Herausforderungen. Erstens muss ein Orakel in einer dynamischen Umgebung konstruiert werden, in der sich Aufgaben aus mehreren Anwendungen beliebig überschneiden können und jede eingehende Anwendungsinstanz einen anderen Systemzustand beobachtet. Die Suche nach optimalen Zeitplänen ist selbst offline eine Herausforderung, da das zugrunde liegende Problem NP-komplett ist. Diese Herausforderung wird durch die Konstruktion von Orakeln angegangen, die sowohl CP als auch eine rechenaufwändige Heuristik, genannt earliest task first (ETF), verwenden. ML verwendet informative Eigenschaften des Systems (Features), um die Kategorie in einem Klassifikationsproblem vorherzusagen.
Die zweite Herausforderung besteht darin, die minimale Menge an relevanten Merkmalen zu identifizieren, die zu einer hohen Genauigkeit bei minimalem Overhead führen kann. Für eine Multi-Core-Plattform mit sechzehn PEs wird ein kleiner Satz von 45 relevanten Merkmalen zusammen mit dem Orakel gespeichert, um den Laufzeit-Overhead zu minimieren. Dies ermöglicht es, eine komplexe Planungsentscheidung als einen Satz von Merkmalen darzustellen und dann den besten PE für die Aufgabenausführung vorherzusagen.
Die letzte Herausforderung besteht darin, das Orakel mit einem minimalen Implementierungsaufwand genau zu approximieren. Da es sich bei der Aufgabenplanung zur Laufzeit um ein sequentielles Entscheidungsproblem handelt, können Methoden des überwachten Lernens, wie lineare Regression und Regressionsbaum, nicht für ungesehene Zustände zur Laufzeit verallgemeinert werden. Verstärkungslernen (RL) und Nachahmungslernen (IL) sind für sequenzielle Entscheidungsprobleme effektiver. RL hat sich bei der Anwendung auf das Planungsproblem als vielversprechend erwiesen, leidet aber unter der langsamen Konvergenz und der Empfindlichkeit der Belohnungsfunktion. Im Gegensatz dazu nutzt IL das inhärente Wissen des Experten und erzeugt Strategien, die die Entscheidungen des Experten nachahmen.
Es wird ein IL-basierter Rahmen vorgeschlagen, der eingehende Anwendungen auf heterogenen Multi-Core-Systemen plant. Das vorgeschlagene IL-Rahmenwerk ist so formuliert, dass es verallgemeinert werden kann, d.h. es kann so angepasst werden, dass es von jedem Orakel lernt, das ein bestimmtes Ziel, wie z.B. Leistung und Energieeffizienz, eines beliebigen heterogenen System-on-Chip (SoC) optimiert (z.B. ein DSSoC). Der vorgeschlagene Rahmen wird mit sechs domänenspezifischen Anwendungen aus der drahtlosen Kommunikation und Radarsystemen evaluiert. Die vorgeschlagenen IL-Politiken approximieren das Orakel erfolgreich mit einer Genauigkeit von mehr als 99 %, erreichen eine schnelle Konvergenz und lassen sich auf unbekannte Anwendungen verallgemeinern. Darüber hinaus werden die Scheduling-Entscheidungen innerhalb von 1,1 Mikrosekunden (µs) getroffen (auf einem Arm A53-Kern), was besser ist als die CFS-Leistung (1,2 µs). Dies ist das erste IL-basierte Scheduling-Framework für heterogene Multi-Core-Systeme, das mehrere Anwendungen mit Streaming-Verhalten verarbeiten kann. Die wichtigsten Beiträge dieser Offenlegung sind wie folgt:

• Ein Rahmen für Nachahmungslernen zur Erstellung von Strategien für die Aufgabenplanung in heterogenen Multicore-Plattformen.
• Oracle-Design mit optimalen und heuristischen Schedulern für leistungs- und energiebezogene Optimierungsziele.
• Umfassende Evaluierung der vorgeschlagenen IL-Politiken zusammen mit einer Analyse der Latenz und des Speicher-Overheads.
• Leistungsvergleich von IL-Strategien mit Reinforcement Learning und optimalen Zeitplänen, die durch Constraint Programming ermittelt wurden.

Abschnitt II gibt einen Überblick über die Terminplanung mit gerichteten Acrylgraphen (DAG) und das Imitationslernen. In Abschnitt III wird die vorgeschlagene Methodik vorgestellt, gefolgt von einschlägigen Bewertungsergebnissen in Abschnitt IV. In Abschnitt V wird ein Computersystem vorgestellt, das in den hier beschriebenen Ausführungsformen verwendet werden kann.
II. Überblick über das Laufzeitplanungsproblem
Die und veranschaulichen das hier behandelte Laufzeitplanungsproblem. ist ein schematisches Diagramm einer beispielhaften DAG zur Modellierung einer Streaming-Anwendung 10 mit sieben Anwendungsaufgaben 12. ist ein Beispiel für einen Zeitplan der DAG 10 aus auf einem beispielhaften heterogenen Many-Core-System 14 (z. B. einem heterogenen SoC, wie einem DSSoC).
Es werden Streaming-Anwendungen 10 betrachtet, die mit DAGs modelliert werden können, wie z. B. die in gezeigte. Diese Anwendungen 10 verarbeiten Datenrahmen, die im Laufe der Zeit mit unterschiedlicher Geschwindigkeit eintreffen. Ein WiFi-Transmitter (WiFi-TX), eine der Domänenanwendungen 10, empfängt und kodiert beispielsweise Rohdatenrahmen, bevor sie über die Luft übertragen werden. Die Datenrahmen einer einzelnen Anwendung 10 oder mehrerer gleichzeitiger Anwendungen 10 können sich zeitlich überschneiden, während sie die Aufgaben 12 durchlaufen, aus denen die Anwendung 10 besteht. So kann z. B. Task-1 in mit der Verarbeitung eines neuen Rahmens beginnen, während andere Tasks 12 frühere Rahmen weiterverarbeiten. Die Verarbeitung eines Rahmens gilt als abgeschlossen, wenn die letzte Aufgabe 12 ohne Nachfolger (Aufgabe-7 in ausgeführt ist. Die Anwendung 10 ist formell definiert, um die Beschreibung der Scheduler zu erleichtern.
Definition 1: Ein Anwendungsgraph $G (_{App} T, E)$
ist ein DAG, in dem jeder Knoten $T_{i} \in T$
die Aufgaben 12 darstellt, aus denen die Anwendung 10 besteht. Gerichtete Kante e_ij ∈ ℇ von der Aufgabe T_i zu T_j zeigt, dass T_j nicht mit der Verarbeitung eines neuen Rahmens beginnen kann, bevor die Ausgabe von T_i T_j für alle T_i, $T_{j} E T .$
v_ij für jede Kante e_ij ∈ ℇ bezeichnet das Kommunikationsvolumen über diese Kante. Es wird verwendet, um die Kommunikationslatenz zu berücksichtigen.
Jede Aufgabe 12 in einem bestimmten Anwendungsgraphen G App kann auf verschiedenen PEs im Ziel-SoC ausgeführt werden. Die Ziel-SoCs sind formal wie folgt definiert:

Definition 2: Ein Architekturgraph G $G (_{Arch} P, L)$
ist ein gerichteter Graph, bei dem jeder Knoten $P_{i} \in P$
PEs darstellt, und $L_{i j} \in L$
die Kommunikationsverbindungen zwischen P_i und P_j im Ziel-SoC darstellt. Den Knoten und Verbindungen sind die folgenden Größen zugeordnet:
- • t_exe (P_i, T_j ) ist die Ausführungszeit der Aufgabe T_j auf PE $P_{i} \in P$
  wenn P_i die Aufgabe T_j ausführen kann (d. h. sie unterstützt).
- • t_comm (L_ij) ist die Kommunikationslatenz von P_i zu P_j für alle P_i, $P_{j} \in P .$
- • C(P)_i ∈ C ist der PE-Cluster $P_{i} \in P$
  gehört.

Bei dem in dargestellten heterogenen Mehrkernsystem 14 kann es sich um ein DSSoC handeln, wie es in Tabelle I beschrieben ist, wobei der Einfachheit halber von einem großen Kern-Cluster, einem LITTLE-Kern-Cluster und zwei Hardware-Beschleunigern mit jeweils einem einzigen PE ausgegangen wird. Die stromsparenden (LITTLE) und leistungsstarken (big) Allzweck-Cluster können die Ausführung aller Tasks 12 unterstützen, wie in der Spalte „Unterstützte Tasks“ in Tabelle I angegeben. Im Gegensatz dazu unterstützen die Hardwarebeschleuniger (Acc-1 und Acc-2) nur eine Teilmenge der Aufgaben 12. Tabelle I: DSSoC PEs und unterstützte Tasks

Cluster und PEs	Unterstützte Aufgaben
Leistungsstarke (große) Allzweckgeräte	1, 2, 3, 4, 5, 6, 7
Stromsparende (LITTLE) Mehrzweckgeräte	1, 2, 3, 4, 5, 6, 7
Hardware-Beschleuniger-1 (Acc-1)	3, 5
Hardware-Beschleuniger-2 (Acc-2)	2, 5, 6

Ein spezieller Fall des Planungsproblems ist in dargestellt. Task-6 wird auf dem großen Kern eingeplant (obwohl er auf Acc-2 schneller ausgeführt wird), da Acc-2 zum Zeitpunkt der Entscheidungsfindung nicht verfügbar ist. In ähnlicher Weise wird Task-4 auf dem LITTLE-Kern eingeplant (auch wenn er auf dem big-Kern schneller ausgeführt werden kann), da der big-Kern genutzt wird, wenn Task-4 zur Ausführung bereit ist. Im Allgemeinen bietet die Planung komplexer DAGs in heterogenen Multicore-Plattformen eine Vielzahl von Wahlmöglichkeiten, was das Problem der Laufzeitplanung sehr komplex macht. Die Komplexität nimmt weiter zu mit: (1) Überlappung von DAGs zur Laufzeit, (2) gleichzeitige Ausführung mehrerer Anwendungen und (3) Optimierung für Ziele wie Leistung, Energie usw.
ist eine schematische Darstellung eines beispielhaften IL-Rahmens 16 für die Planung von Aufgaben 12 in einem heterogenen System mit vielen Kernen 14. Die hier beschriebenen Ausführungsformen nutzen IL, wie in skizziert. IL wird auch als Lernen durch Demonstration bezeichnet und ist eine Adaption des überwachten Lernens für sequentielle Entscheidungsprobleme. Der Entscheidungsraum wird in verschiedene Entscheidungsepochen unterteilt, die als Zustände (
) Es gibt eine endliche Menge von Aktionen
für jeden Zustand $s \in S .$
IL verwendet Richtlinien, die jeden Zustand (s) auf eine entsprechende Aktion abbildet.
Definition 3: Oracle-Richtlinie (Experte) $π * (s) : S \to A$
bildet einen gegebenen Systemzustand auf die optimale Aktion ab. Beim Laufzeitplanungsproblem umfasst der Zustand die Menge der bereiten Aufgaben 12 und die Aktionen, die der Zuweisung von Aufgaben
zu PEs
. Angesichts des Orakels π* besteht das Ziel des Imitationslernens darin, eine Laufzeitpolitik zu erlernen, die sich dieser annähern kann. Ein Orakel wird offline konstruiert und approximiert die Laufzeitpolitik durch eine hierarchische Politik mit zwei Ebenen. Betrachten wir ein generisches heterogenes Many-Core-System 14 (z. B. ein heterogenes SoC) mit einer Reihe von Verarbeitungsclustern
, wie in dargestellt. Auf der ersten Ebene wählt eine IL-Richtlinie einen Verarbeitungscluster 18 (unter n Clustern) für die Ausführung einer Anwendungsaufgabe 12 aus.
Die First-Level-Policy ordnet die fertigen Aufgaben 12 einem der Verarbeitungscluster 18 in Czu, da jede PE 20 innerhalb desselben Verarbeitungsclusters 18 die gleichen statischen Parameter hat. Dann weist eine Richtlinie auf Clusterebene die Aufgaben 12 einer bestimmten PE 20 innerhalb dieses Verarbeitungsclusters 18 zu. Die Einzelheiten der Zustandsdarstellung, der Orakelgenerierung und des hierarchischen Richtlinienentwurfs werden im nächsten Abschnitt erläutert.
III. Vorgeschlagene Methodik und Ansatz

In diesem Abschnitt wird zunächst die Darstellung des Systemzustands vorgestellt, einschließlich der von den IL-Richtlinien verwendeten Merkmale. Anschließend werden der Prozess der Orakelgenerierung und der Entwurf der hierarchischen IL-Richtlinien vorgestellt. In Tabelle II sind die im Folgenden verwendeten Bezeichnungen aufgeführt. Tabelle II: Zusammenfassung der hier verwendeten Bezeichnungen.

T _j	Task-j		Set of Tasks
P _i	PE-i		Set of PEs
c	Cluster-c	C	Set of clusters
L _ij	Communication links between P_i to P_j		Set of communication links
t _exe (P _i, T _j )	Execution time of task T_j on PE P_i	t _comm (L _ij )	Communication latency from P_i to P_j
s	State-s		Set of states
v _jk	Communication volume from task T_j to T_k		Set of actions
	Static features		Dynamic features
π _C (s)	Apply cluster policy for state s	π _P,c (s)	Apply PE policy in cluster-c for state s
π	Policy	π*	Oracle policy
π ^G	Policy for many-core platform configuration G	π* ^G	Oracle for many-core platform configuration G

A. Darstellung des Systemzustands
Offline-Planungsalgorithmen sind NP-komplett, auch wenn sie auf statischen Merkmalen wie durchschnittlichen Ausführungszeiten beruhen. Die Komplexität der Laufzeitentscheidungen wird noch weiter erhöht, wenn das System mehrere Anwendungen plant, die ein Streaming-Verhalten aufweisen. Im Streaming-Szenario sehen die eingehenden Frames kein leeres System mit untätigen Prozessoren. Im Gegensatz dazu sind die PEs 20 unterschiedlich ausgelastet, und in den Warteschlangen der PEs 20 kann sich eine beliebige Anzahl von teilweise verarbeiteten Frames befinden. Da ein Ziel darin besteht, eine Reihe von Richtlinien zu erlernen, die für alle Anwendungen 10 und alle Streaming-Intensitäten verallgemeinert werden können, hängt die Fähigkeit, die Planungsentscheidungen zu erlernen, entscheidend von der Effektivität der Zustandsdarstellung ab. Der Systemzustand sollte sowohl statische als auch dynamische Aspekte der Aufgabenmenge 12, der Anwendungen 10 und der Zielplattform umfassen. Naive Darstellungen von DAGs umfassen Adjazenzmatrix und Adjazenzliste. Diese Darstellungen haben jedoch Nachteile, wie z. B. einen großen Speicherbedarf, sehr dünne Matrizen, die das Training überwachter Lerntechniken erschweren, und Skalierbarkeit für mehrere Streaming-Anwendungen 10. Im Gegensatz dazu werden die Faktoren, die die Planung von Aufgaben beeinflussen, in einem Streaming-Szenario sorgfältig untersucht und Merkmale konstruiert, die den Systemzustand genau darstellen. Die Merkmale, aus denen sich der Zustand zusammensetzt, lassen sich im Großen und Ganzen wie folgt kategorisieren:

Aufgabenmerkmale: Dieser Satz umfasst die Attribute der einzelnen Aufgaben 12. Sie können sowohl statisch sein, wie die durchschnittliche Ausführungszeit einer Aufgabe 12 auf einer bestimmten PE 20 (t_exe (P_i, T_j)), als auch dynamisch, wie die relative Reihenfolge einer Aufgabe 12 in der Warteschlange.
Merkmale der Anwendung: Dieser Satz beschreibt die Merkmale der gesamten Anwendung 10. Es handelt sich dabei um statische Merkmale, wie die Anzahl der Aufgaben 12 in der Anwendung 10 und die Vorrangsbedingungen zwischen ihnen.
PE-Merkmale: Dieser Satz beschreibt den dynamischen Zustand der PEs 20. Beispiele sind die frühesten verfügbaren Zeiten (Bereitschaft) der PEs 20 zur Ausführung von Aufgaben 12.

Die statischen Merkmale werden zum Zeitpunkt des Entwurfs festgelegt, während
die dynamischen Merkmale können nur zur Laufzeit berechnet werden. Die statischen Merkmale helfen bei der Ausnutzung des Entwurfszeitverhaltens. Zum Beispiel hilft t_exe (P_i; T_j) dem Planer, die erwartete Leistung verschiedener PEs 20 zu vergleichen. Die dynamischen Merkmale hingegen zeigen die Laufzeitabhängigkeiten zwischen den Aufgaben 12 und den Jobs sowie die Auslastungszustände der PEs 20. So ist beispielsweise der voraussichtliche Zeitpunkt, zu dem der Cluster c für die Verarbeitung zur Verfügung steht, eine unschätzbare Information, die nur zur Laufzeit verfügbar ist.

Zusammenfassend lässt sich sagen, dass die Merkmale einer Aufgabe 12 die Aufgabe 12 selbst und den Zustand der PEs 20 im System umfassend darstellen, um die Entscheidungen der Orakelpolitik effektiv zu lernen. Die spezifischen Arten von Merkmalen, die in dieser Arbeit zur Darstellung des Zustands verwendet werden, und ihre Kategorien sind in Tabelle III aufgeführt. Die statischen und dynamischen Merkmale werden als

F_{S}

und

F_{D}

bezeichnet. Dann wird der Systemzustand zu einem bestimmten Zeitpunkt k unter Verwendung der Merkmale in Tabelle III wie folgt definiert:

s_{k} = F_{S, k} \cup F_{D, k}

wobei F_S,k und F_D,k die statischen bzw. dynamischen Merkmale zu einem bestimmten Zeitpunkt k bezeichnen. Für einen SoC 18 mit sechzehn PEs 20, die zu fünf Verarbeitungsclustern 18 gruppiert sind, ergibt sich ein Satz von 45 Merkmalen für die vorgeschlagene IL-Technik.
Tabelle III: Arten von Merkmalen, die zur Zustandsdarstellung aus Sicht der Aufgabe T verwendet werden_j

Feature Type	Feature Description	Feature Categories
Static (F_S)	ID of task-j in the DAG	Task
	Execution time of a task T_j	Task PE
	Downward depth of task T_j in the DAG	Task Application
	IDs of predecessor tasks of task T_j	Task Application
	Application ID	Application
	Power consumption of task T_j in PE P_t	Task PE
Dynamic (F_D)	Relative order of task T_j in the ready queue	Task
	Earliest time when PEs in a cluster-c are ready for task execution	PE
	Clusters in which predecessor tasks of task T_j executed	Task
	Communication volume from task T_j to task T_k(v_jk)	Task

B. Oracle Generation
Das Ziel dieser Arbeit ist es, verallgemeinerte Planungsmodelle für Streaming-Anwendungen 10 verschiedener Typen zu entwickeln, die auf heterogenen Systemen mit vielen Kernen 14 ausgeführt werden. Die Allgemeingültigkeit des IL-basierten Scheduling-Rahmens 16 ermöglicht die Verwendung von IL mit einem beliebigen Orakel. Das Orakel kann ein beliebiger Scheduling-Algorithmus 22 sein oder verwenden, der eine beliebige Metrik optimiert, z. B. Ausführungszeit, Stromverbrauch und Gesamtenergie des SoC 18.
Um den Trainingsdatensatz zu generieren, werden die beiden optimalen Scheduling-Algorithmen 22 mit CP und Heuristiken implementiert. Diese Scheduling-Algorithmen 22 sind in einen SoC-Simulator 24 integriert, wie unter Evaluierungsergebnisse erläutert. Angenommen, eine neue Aufgabe T_j wird zum Zeitpunkt k bereit. Das Orakel wird aufgerufen, um die Aufgabe 12 in eine PE 20 einzuplanen. Die Orakelpolitik für diese Aktionsaufgabe 12 mit dem Systemzustand s_k kann wie folgt ausgedrückt werden: $π * (s_{k}) = P_{i}$
wobei $P_{i} \in P$
die PE T_j ist, für die der Zeitplan gilt, und s_k der in Gleichung 1 definierte Systemzustand ist. Nach jeder Planungsaktion wird die jeweilige Aufgabe 12, die geplant wird (T_j), der Systemzustand $s_{k} \in S$
und die Planungsentscheidung zu den Trainingsdaten hinzugefügt. Damit die Orakelrichtlinien für verschiedene Arbeitslastbedingungen verallgemeinert werden können, werden Arbeitslastmischungen unter Verwendung der Zielanwendungen 10 bei verschiedenen Datenraten erstellt, wie in Abschnitt IV-A beschrieben.
C. IL-basiertes Scheduling Framework
In diesem Abschnitt wird der hierarchische IL-basierte Scheduler für die Laufzeitplanung von Aufgaben auf heterogenen Multi-Core-Plattformen vorgestellt. Eine hierarchische Struktur ist besser skalierbar, da sie ein komplexes Scheduling-Problem in einfachere Probleme aufteilt. Darüber hinaus wird eine deutlich höhere Klassifizierungsgenauigkeit im Vergleich zu einem flachen Klassifikator erreicht (>93 % gegenüber 55 %), wie in Abschnitt IV-D näher erläutert.
Die hierarchischen IL-basierten Scheduler-Policies approximieren das Orakel mit zwei Ebenen, wie in Algorithmus 1 dargestellt. Die Politik der ersten Ebene $π_{C} (s) : S \to C$
ist ein grobkörniger Planer, der die Aufgaben 12 den Verarbeitungsclustern 18 zuweist. Dies ist eine natürliche Wahl, da die einzelnen PEs 20 innerhalb eines Verarbeitungsclusters 18 identische statische Parameter haben, d. h. sie unterscheiden sich nur durch ihre dynamischen Zustände. Die zweite Ebene (d. h. die feingranulare Planung) besteht aus einer speziellen Strategie $π_{P, c} (s) : S \to P$
für jedes Cluster $c \in C .$
Diese Richtlinien weisen die Eingangsaufgabe 12 einer PE 20 innerhalb ihres eigenen Verarbeitungsclusters 18 zu, d. h., $π_{P, c} (s) \in P^{c}, \forall_{c} \in C .$
Zur Erstellung der IL-Richtlinien werden handelsübliche maschinelle Lerntechniken wie Regressionsbäume und neuronale Netze eingesetzt. Die Anwendung dieser Richtlinien nähert sich den entsprechenden offline konstruierten Orakel-Richtlinien an.
Die IL-Politik leidet unter der Fehlerfortpflanzung, da die Zustands-Aktions-Paare im Orakel nicht unbedingt unabhängig und identisch verteilt (i.i.d) sind. Wenn die von den IL-Politiken in einer bestimmten Entscheidungsepoche getroffene Entscheidung von der des Orakels abweicht, ist auch der resultierende Zustand für die nächste Epoche anders als im Orakel. Daher akkumuliert sich der Fehler in jeder Entscheidungsepoche weiter. Dies kann bei der Aufgabenplanung zur Laufzeit auftreten, wenn die Richtlinien auf Anwendungen 10 angewendet werden, mit denen die Richtlinien nicht trainiert wurden. Dieses Problem wird durch einen Datenaggregationsalgorithmus (DAgger) 26 angegangen, der zur Verbesserung der IL-Richtlinien vorgeschlagen wurde. DAgger 26 fügt den Systemzustand und die Orakelentscheidung zu den Trainingsdaten hinzu, wenn die IL-Richtlinie eine falsche Entscheidung trifft. Dann werden die Richtlinien nach der Ausführung der Arbeitslast neu trainiert.
DAgger 26 ist nicht ohne weiteres auf das Laufzeitplanungsproblem anwendbar, da die Anzahl der Zustände unbegrenzt ist, da eine Planungsentscheidung zur Zeit t für den Zustand s (st ) zu einem beliebigen resultierenden Zustand s_t+1 führen kann. Mit anderen Worten, der Merkmalsraum ist kontinuierlich, und daher ist es nicht möglich, offline ein erschöpfendes Orakel zu erzeugen. Diese Herausforderung wird überwunden, indem ein Orakel on-thefly generiert wird. Genauer gesagt, wird der vorgeschlagene Rahmen in einen Simulator 24 integriert. Der als Orakel verwendete Offline-Scheduler wird für jede neue Aufgabe 12 dynamisch aufgerufen. Dann werden die Trainingsdaten mit allen Merkmalen, Orakelaktionen sowie den Ergebnissen der zu entwickelnden IL-Politik angereichert. Der Datenaggregationsprozess wird also als Teil der dynamischen Simulation durchgeführt.
Die hierarchische Natur des vorgeschlagenen IL-Rahmens 16 führt eine weitere Komplexität in die Datenaggregation ein. Das Ergebnis der Clusterpolitik kann richtig sein, während der PE-Cluster zu einer falschen Entscheidung gelangt (oder umgekehrt). Wenn die Cluster-Vorhersage korrekt ist, wird diese Vorhersage verwendet, um die PE-Politik dieses Clusters auszuwählen, wie in Algorithmus 2 dargelegt. Wenn die PE-Vorhersage ebenfalls korrekt ist, wird die Ausführung fortgesetzt; andernfalls werden die PE-Daten im Datensatz aggregiert. Stimmt die Cluster-Vorhersage jedoch nicht mit dem Orakel überein, wird zusätzlich zur Aggregation der Cluster-Daten ein fliegendes Orakel aufgerufen, um die PE-Richtlinie auszuwählen, dann wird die PE-Vorhersage mit dem Orakel verglichen und die PE-Daten werden im Falle einer falschen Vorhersage aggregiert.
IV. Ergebnisse der Bewertung
In Abschnitt IV-A werden die Bewertungsmethodik und der Aufbau vorgestellt. Abschnitt IV-B untersucht verschiedene maschinelle Lernklassifikatoren für IL. Die Bedeutung der vorgeschlagenen Merkmale wird in Abschnitt IV-C mit Hilfe eines Regressionsbaum-Klassifikators untersucht. Abschnitt IV-D präsentiert die Bewertung des vorgeschlagenen IL-Schedulers. Abschnitt IV-E analysiert die Generalisierungsfähigkeiten des IL-Schedulers. Die Leistungsanalyse mit mehreren Workloads wird in Abschnitt IV-F vorgestellt. Die Bewertung der vorgeschlagenen IL-Technik für energiebasierte Optimierungsziele wird in Abschnitt IV-G demonstriert. Abschnitt V-H präsentiert Vergleiche mit einem RL-basierten Scheduler und Abschnitt IV-I analysiert die Komplexität des vorgeschlagenen Ansatzes.
A. Bewertungsmethodik und Aufbau

Bereich Anwendungen: Die vorgeschlagene IL-Planungsmethodik wird anhand von Anwendungen aus den Bereichen drahtlose Kommunikation und Radarverarbeitung bewertet. Es werden die Anwendungen WiFi-TX, WiFi-Empfänger (WiFi-RX), Entfernungsmessung (RangeDet), Einträger-Sender (SC-TX), Einträger-Empfänger (SC-RX) und zeitliche Mitigation (TempMit) verwendet, wie in Tabelle IV zusammengefasst. Mit diesen Anwendungen werden Workload-Mixe erstellt und parallel ausgeführt. Tabelle IV: Merkmale der in dieser Studie verwendeten Anwendungen und die Anzahl der Frames jeder Anwendung im Workload

App	# of Tasks	Execution Time (µs)	Supported Clusters	Representation in workload
				#frames	#tasks
WiFi-TX	27	301	big. LITTLE, FFT	69	1863
WiFi-RX	34	71	big, LITTLE, FFT, Viterbi	111	3774
RangeDet	7	177	big. LITTLE, FFT	64	448
SC-TX	8	56	big, LITTLE	64	512
SC-RX	8	154	big, L1TTLE, Viterbi	91	728
TempMit	10	81	big. LITTLE, Matrix mult.	101	1010
TOTAL				500	8335

Heterogene SoC-Konfiguration: ist ein schematisches Diagramm einer beispielhaften Konfiguration einer anderen heterogenen Many-Core-Plattform 14, die für Scheduler-Evaluierungen verwendet wird. In Anbetracht der Art der Anwendungen wird ein SoC 18 (z. B. DSSoC) mit sechzehn PEs verwendet, einschließlich Beschleunigern für die rechenintensivsten Aufgaben; sie sind in fünf Cluster mit mehreren homogenen PEs unterteilt, wie in dargestellt. Um einen Kompromiss zwischen Leistung und Stromverbrauch bei gleichzeitiger Verwendung von Allzweckkernen zu ermöglichen, sind ein großer Cluster mit vier Arm A57-Kernen und ein LITTLE-Cluster mit vier Arm A53-Kernen enthalten. Darüber hinaus integriert der SoC 18 Beschleunigercluster für Matrixmultiplikation, Fast Fourier Transform (FFT) und Viterbi-Decoder, um die Rechenanforderungen der in Tabelle IV zusammengefassten Zielanwendungen zu erfüllen. Die Beschleunigerschnittstellen sind Joshua Mack, Nirmal Kumbhare, N. K. Anish, Umit Y. Ogras und Ali Akoglu, „User-Space Emulation Framework For Domain-Specific SoC Design", in 2020 IEEE International Parallel and Distributed Processing Symposium Workshops (IPDPSW), pp. 44-53, IEEE, 2020, entnommen, dessen Offenlegung hier vollständig berücksichtigt wird. Die Anzahl der Beschleunigerinstanzen in den einzelnen Clustern wird danach ausgewählt, wie stark sie von den Zielanwendungen genutzt werden. Zum Beispiel beinhalten drei der sechs Referenzanwendungen FFT, während die Anwendung zur Entfernungsmessung allein drei FFT-Operationen umfasst. Daher werden vier Instanzen von FFT-Hardwarebeschleunigern und zwei Instanzen von Viterbi- und Matrixmultiplikationsbeschleunigern eingesetzt, wie in dargestellt.
Simulationsrahmen: Der vorgeschlagene IL-Scheduler wird mit dem diskreten ereignisbasierten Simulationsrahmen bewertet, der in S.E. Arda et al., „DS3: A System-Level Domain-Specific System-an-Chip Simulation Framework," in IEEE Transactions on Computers, vol. 69, no. 8, pp. 1248-1262, 2020 (im Folgenden als „DS3“ bezeichnet, dessen Offenlegung hier durch Verweis in vollem Umfang enthalten ist), das an zwei kommerziellen SoCs validiert wurde: Odroid-XU3 und Zynq Ultrascale+ ZCU102. Dieser Rahmen ermöglicht Simulationen der als DAGs modellierten Zielanwendungen unter verschiedenen Planungsalgorithmen. Genauer gesagt, eine neue Instanz einer DAG trifft mit einer bestimmten Ankunftszeitrate und -verteilung ein, z. B. einer Exponentialverteilung. Nach der Ankunft jeder DAG-Instanz, die als Frame bezeichnet wird, ruft der Simulator den untersuchten Scheduler auf. Der Scheduler verwendet dann die Informationen in der DAG und den aktuellen Systemzustand, um die fertigen Aufgaben den Warteschlangen der PEs zuzuweisen. Der Simulator erleichtert die Speicherung dieser Informationen und der Scheduling-Entscheidung, um das Orakel zu konstruieren, wie in Abschnitt III-B beschrieben.
Die Ausführungszeiten und der Stromverbrauch für die Aufgaben in den Domänenanwendungen werden auf Odroid-XU3 und Zynq ZCU102 SoCs profiliert. Der Simulator verwendet diese Profiling-Ergebnisse, um die Ausführungszeit und den Stromverbrauch jeder Aufgabe zu bestimmen. Nachdem alle Tasks, die zum selben Frame gehören, ausgeführt wurden, ist die Verarbeitung des entsprechenden Frames abgeschlossen. Der Simulator verfolgt die Ausführungszeit und den Energieverbrauch für jeden Frame. Diese End-to-End-Werte liegen im Durchschnitt innerhalb von 3 % der Messungen auf Odroid-XU3 und Zynq ZCU102 SoCs.
Für Oracle verwendete Planungsalgorithmen und Vergleiche: Eine CP-Formulierung wird mit IBM ILOG CPLEX Optimization Studio entwickelt, um die optimalen Zeitpläne zu erhalten, wann immer es die Problemgröße erlaubt. Nach dem Eintreffen eines jeden Frames ruft der Simulator den CP-Solver auf, um den Zeitplan dynamisch als Funktion des aktuellen Systemzustands zu finden. Da der CP-Solver bei großen Eingaben (-100 Aufgaben) Stunden benötigt, wurden zwei Versionen mit einer Minute (CP_1-min) und fünf Minuten (CP_5-min) Zeitüberschreitung pro Zeitplanentscheidung implementiert. Wenn das Modell keinen optimalen Zeitplan findet, wird die beste Lösung verwendet, die innerhalb des Zeitlimits gefunden wurde.
ist eine grafische Darstellung, in der die durchschnittliche Laufzeit pro Planungsentscheidung für verschiedene Anwendungen mit CP_1-min, CP_5-min und dem ETF-Scheduler verglichen wird. Diese Abbildung zeigt, dass die durchschnittliche Zeit des CP-Solvers pro Scheduling-Entscheidung für die Benchmark-Anwendungen bei etwa 0,8 Sekunden bzw. 3,5 Sekunden liegt, basierend auf dem Zeitlimit. Folglich kann eine gesamte Simulation bis zu 2 Tage dauern, selbst mit einer Zeitüberschreitung.
Der heuristische ETF-Scheduler ist ebenfalls implementiert, der alle Aufgaben und möglichen Zuweisungen durchgeht, um die früheste Endzeit unter Berücksichtigung der Kommunikationsoverheads zu finden. Seine durchschnittliche Ausführungszeit liegt bei fast 0,3 ms, was für einen Laufzeit-Scheduler immer noch unerschwinglich ist, wie in gezeigt wird. Es ist jedoch zu beobachten, dass er besser als CP_1-min und geringfügig schlechter als CP_5-min abschneidet, wie in Abschnitt IV-D beschrieben.
Die Oracle-Generierung mit der CP-Formulierung ist aus zwei Gründen nicht praktikabel. Erstens ist es möglich, dass es bei kleinen Eingaben (z. B. weniger als zehn Aufgaben) mehrere (etablierte) optimale Lösungen gibt, und CP würde eine davon zufällig auswählen. Der andere Grund ist, dass CP bei großen Eingaben am Zeitlimit aufhört und die beste Lösung liefert, die bisher gefunden wurde, was suboptimal ist. Die von CP erzeugten suboptimalen Lösungen hängen von der Problemgröße und dem Zeitlimit ab. Im Gegensatz dazu ist ETF zur Laufzeit leichter zu imitieren und seine Ergebnisse liegen innerhalb von 8,2 % der CP_5-min Ergebnisse. Daher wird ETF als Orakelpolitik in den Auswertungen verwendet und die Ergebnisse der CP-Scheduler werden als Referenzpunkte verwendet. IL-Politiken für dieses Orakel werden in Abschnitt IV-B trainiert und ihre Leistung in Abschnitt IV-D bewertet.
B. Untersuchung verschiedener maschineller Lernklassifikatoren für IL
Es werden verschiedene ML-Klassifikatoren im Rahmen der IL-Methodik untersucht, um die Orakelpolitik anzunähern. Eine der wichtigsten Messgrößen für die Wahl der ML-Techniken ist die Klassifizierungsgenauigkeit der IL-Richtlinien. Gleichzeitig sollte die Richtlinie auch einen geringen Speicher- und Ausführungszeitaufwand haben. Die folgenden Algorithmen werden hinsichtlich ihrer Klassifizierungsgenauigkeit und Implementierungseffizienz bewertet: Regressionsbaum (RT), Support Vector Classifier (SVC), logistische Regression (LR) und ein mehrschichtiges neuronales Perzeptron-Netzwerk (NN) mit vier versteckten Schichten und 32 Neuronen in jeder versteckten Schicht.
Die Klassifizierungsgenauigkeit der untersuchten ML-Algorithmen ist in Tabelle V aufgeführt. Im Allgemeinen erreichen alle Klassifizierer eine hohe Genauigkeit bei der Auswahl des Clusters (erste Spalte). Auf der zweiten Ebene wählen sie den richtigen PE mit hoher Genauigkeit (>97 %) innerhalb der Hardware-Beschleuniger-Cluster. Bei den LITTLE- und Big-Clustern weisen sie jedoch eine geringere Genauigkeit und eine größere Streuung auf. Dies ist intuitiv, da die LITTLE- und Big-Cluster alle Arten von Aufgaben in den Anwendungen ausführen können, während die Beschleuniger weniger Aufgaben ausführen. In starkem Kontrast dazu führt eine flache Strategie, die die PE direkt vorhersagt, zu einer Trainingsgenauigkeit von bestenfalls 55 %. Daher konzentrieren sich die Ausführungsformen auf die vorgeschlagene hierarchische IL-Methodik.

Regressionsbäume (RT), die mit einer maximalen Tiefe von 12 trainiert wurden, erzielen die beste Genauigkeit für die Cluster- und PE-Richtlinien, mit mehr als 99,5 % Genauigkeit für di Tabelle V: Klassifizierungsgenauigkeit der trainierten IL-Policies mit verschiedenen Machine-Learning-Klassifikatoren

Classifier	Cluster Policy	LITTLE Policy	big Policy	MatMult Policy	FFT Policy	Viterbi Policy
RT	99.6	93.8	95.1	99.9	99.5	100
SVC	95.0	85.4	89.9	97.8	97.5	98.0
LR	89.9	79.1	72.0	98.7	98.2	98.0
NN	97.7	93.3	93.6	99.3	98.9	98.1

e Cluster- und Hardwarebeschleunigungsrichtlinien. RT erzielt auch eine Genauigkeit von 93,8 % und 95,1 % bei der Vorhersage von PEs innerhalb der LITTLE- bzw. Big-Cluster, was die höchste Genauigkeit unter allen evaluierten Klassifikatoren ist. Die Klassifizierungsgenauigkeit der NN-Strategien ist mit RT vergleichbar, wobei die Cluster-Vorhersagegenauigkeit mit 97,7 % etwas geringer ist. Im Gegensatz dazu werden SVC und LR aufgrund ihrer geringeren Genauigkeit von weniger als 90 % bzw. 80 % bei der Vorhersage von PEs innerhalb von LITTLE- und großen Clustern nicht bevorzugt.

RTs und NNs wurden ausgewählt, um die Latenzzeit und den Speicher-Overhead zu analysieren (aufgrund ihrer überlegenen Leistung). Die Latenzzeit von RT beträgt 1,1 µ s auf Arm Cortex-A15 in Odroid-XU3 und auf Arm Cortex-A53 in Zynq ZCU102, wie in Tabelle VI gezeigt. Im Vergleich dazu beträgt der Scheduling-Overhead von CFS, dem Standard-Linux-Scheduler, auf dem Zynq ZCU102 mit dem Linux-Kernel 4.9 1,2µ s und ist damit etwas größer als die hier vorgestellte Lösung. Der Speicher-Overhead einer RT-Richtlinie beträgt 19,33 KB. Die NN-Richtlinien verursachen einen Overhead von 14,4µ s auf dem Arm Cortex-A15-Cluster in Odroid-XU3 und 37µ s auf Arm Cortex-A53 in Zynq, mit einem Speicher-Overhead von 16,89 KB. NNs sind für den Einsatz in einer Online-Umgebung vorzuziehen, da ihre Gewichte mithilfe des Backpropagation-Algorithmus inkrementell aktualisiert werden können. Aufgrund der konkurrenzfähigen Klassifizierungsgenauigkeit und des geringeren Latenzaufwands von RTs im Vergleich zu NNs wird RT jedoch für den Rest der Evaluierungen gewählt. Tabelle VI: Ausführungszeit und Speicherkosten pro IL-Policy für Regressionsbaum- und neuronale Netzwerkklassifikatoren

Classifier Latency (µs) Storage (KB)

Odroid-XU3 (Arm A15) Zynq Ultrascale+ ZCU102 (Arm A53)

RT 1.1 1.1 19.3

NN 14.4 37 16.9
C. Feature Space Exploration mit Regressionsbaum-Klassifikator
In diesem Abschnitt wird die Bedeutung der für die Darstellung des Zustands gewählten Merkmale untersucht. Für diese Analyse werden die Auswirkungen der Eingangsmerkmale auf die Trainingsgenauigkeit mit dem RT-Klassifikator und die durchschnittliche Ausführungszeit nach einem systematischen Ansatz bewertet.

ist eine grafische Darstellung, in der die durchschnittliche Ausführungszeit der Anwendungen für verschiedene Anwendungen mit Orakel, IL (vorgeschlagen) und IL-Richtlinien mit Teilmengen von Merkmalen verglichen wird. Die Trainingsgenauigkeit mit Untergruppen von Merkmalen und die entsprechende Leistung des Schedulers sind in Tabelle VII bzw. dargestellt. Zunächst werden alle statischen Merkmale aus dem Trainingsdatensatz ausgeschlossen. Die Trainingsgenauigkeit für die Vorhersage des Clusters sinkt deutlich um 10 %. Da hierarchische KI-Richtlinien verwendet werden, führt eine falsche Entscheidung auf der ersten Ebene zu einem erheblichen Nachteil bei den Entscheidungen auf der nächsten Ebene. Zweitens werden alle dynamischen Merkmale vom Training ausgeschlossen. Dies führt zu einer ähnlichen Auswirkung für die Cluster-Politik (10 %), wirkt sich jedoch erheblich auf die für LITTLE, big und FFT konstruierten Politiken aus. Ein ähnlicher Trend ist zu beobachten, wenn die PE-Verfügbarkeitszeiten aus dem Merkmalssatz ausgeschlossen werden. Die Genauigkeit ist geringfügig höher, da die anderen dynamischen Merkmale zum Lernen der Planungsentscheidungen beitragen. Schließlich werden einige aufgabenbezogene Merkmale entfernt, wie z. B. die Abwärtstiefe, die Aufgaben- und die Anwendungskennung. In diesem Fall ist die Auswirkung auf die Genauigkeit der Cluster-Politik, da diese Merkmale den Knoten in der DAG beschreiben und die Cluster-Zuordnung beeinflussen. Tabelle VII: Trainingsgenauigkeit von IL-Politiken mit Teilmengen des vorgeschlagenen Feature-Sets

Features Exduded from Training	Cluster Policy	LITTLE Policy	big Policy	MatMut Policy	FFT Policy	Viterbi Policy
None	99.6	93.8	95.1	99.9	99.5	100
Static features	87.3	93.8	92.7	99.9	99.5	100
Dynamic features	88.7	52.1	57.6	94.2	70.5	98
PE availability times	92.2	51.1	61.5	94.1	66.7	98.1
Task ID, depth, app. ID	90.9	93.6	95.3	99.9	99.5	100

Wie in zu sehen ist, verschlechtert sich die durchschnittliche Ausführungszeit des Workloads erheblich, wenn nicht alle Merkmale berücksichtigt werden. Die gewählten Merkmale helfen also bei der Erstellung effektiver KI-Politiken, die das Oracle mit einer Genauigkeit von über 99 % in der Ausführungszeit approximieren.
D. IL-Scheduler Leistungsbewertung
In diesem Abschnitt wird die Leistung der vorgeschlagenen Strategie mit der von ETF Oracle, CP_1-min und CP_5-min verglichen. Da heterogene Multi-Core-Systeme in der Lage sind, mehrere Anwendungen gleichzeitig auszuführen, werden die Frames im Anwendungsmix (siehe Tabelle IV) mit steigenden Injektionsraten gestreamt. Ein normalisierter Durchsatz von 1,0 in entspricht beispielsweise 19,78 Frames/ms. Da die Bilder schneller eingespeist werden, als sie verarbeitet werden können, gibt es zu jedem Zeitpunkt viele sich überschneidende Bilder.
Zunächst werden die IL-Richtlinien mit allen sechs Referenzanwendungen trainiert, was als Baseline-IL-Scheduler bezeichnet wird. IL-Politiken leiden unter der Fehlerfortpflanzung aufgrund der nicht i.i.d. Natur der Trainingsdaten. Um diese Einschränkung zu überwinden, wird eine Datenaggregationstechnik verwendet, die an einen hierarchischen IL-Rahmen (IL-DAgger) angepasst ist, wie in Abschnitt III-C beschrieben. Eine DAgger-Iteration umfasst die Ausführung der gesamten Arbeitslast. Es werden zehn DAgger-Iterationen durchgeführt, und die beste Iteration mit einer Leistung innerhalb von 2 % des Oracle-Ziels wird ausgewählt. Wenn das Ziel nicht erreicht wird, werden weitere Iterationen durchgeführt.
ist eine grafische Darstellung, die die durchschnittliche Auftragsausführungszeit zwischen Oracle, CP-Lösungen und IL-Richtlinien vergleicht, um eine Arbeitslast zu planen, die eine Mischung aus sechs Streaming-Anwendungen umfasst. zeigt, dass der vorgeschlagene IL-DAgger-Scheduler fast identisch mit Oracle ist; der durchschnittliche prozentuale Unterschied zwischen ihnen beträgt 1 %. Noch bemerkenswerter ist, dass der Abstand zwischen der vorgeschlagenen IL-DAgger-Strategie und der optimalen CP_5-min -Lösung nur 9,22 % beträgt. CP_5-min wird nur als Referenzpunkt herangezogen, hat aber einen um sechs Größenordnungen größeren Ausführungszeit-Overhead und kann nicht zur Laufzeit verwendet werden. Darüber hinaus schneidet der vorgeschlagene Ansatz besser ab als CP_1-min, das nicht in der Lage ist, einen guten Zeitplan innerhalb des Zeitlimits von einer Minute pro Entscheidung zu finden. Schließlich kann sich die Baseline IL der Leistung der vorgeschlagenen Strategie annähern. Dies ist intuitiv, da beide Strategien in dieser Evaluierung mit bekannten Anwendungen getestet werden. Dies steht im Gegensatz zu den in Abschnitt IV-E vorgestellten „leave one out“-Varianten.
Puls-Doppler-Anwendung Fallstudie: Die Anwendbarkeit der vorgeschlagenen IL-Planungstechnik wird in komplexen Szenarien anhand einer Puls-Doppler-Anwendung demonstriert. Es handelt sich um eine reale Radaranwendung, die die Geschwindigkeit eines sich bewegenden Zielobjekts berechnet. Diese Anwendung ist wesentlich komplexer, mit 13-64 mehr Aufgaben als die anderen Anwendungen. Sie besteht aus 449 Aufgaben, darunter 192 FFT-Aufgaben, 128 inverse FFT-Aufgaben und 129 andere Berechnungen. Die FFT- und inversen FFT-Operationen können auf den Allzweck-Cores und den Hardware-Beschleunigern ausgeführt werden. Im Gegensatz dazu können die anderen Tasks nur auf den Allzweck-Cores ausgeführt werden.
Die vorgeschlagenen KI-Richtlinien erreichen eine durchschnittliche Ausführungszeit innerhalb von 2 % des Oracle. Der Fehler von 2 % ist akzeptabel, wenn man bedenkt, dass die Anwendung aufgrund ihrer hohen Komplexität die Rechenplattform schnell sättigt. Darüber hinaus führt der CPbasierte Ansatz aufgrund der großen Problemgröße weder mit 1-Minuten- noch mit 5-Minuten-Zeitlimits zu einer brauchbaren Lösung. Aus diesem Grund wird diese Anwendung nicht in den Workload-Mix und die übrigen Vergleiche einbezogen.
E. Veranschaulichung der Generalisierung mit IL für unbekannte Anwendungen, Laufzeitvariationen und Plattformen
In diesem Abschnitt wird die Verallgemeinerung des vorgeschlagenen IL-basierten Scheduling-Ansatzes auf unbekannte Anwendungen, Laufzeitvariationen und Multi-Core-Plattformkonfigurationen analysiert.
Verallgemeinerung des IL-Schedulers auf unbekannte Anwendungen unter Verwendung von Leave-one-out-Embodiments: IL ist eine Adaption des überwachten Lernens für die sequentielle Entscheidungsfindung, leidet aber unter der mangelnden Generalisierung auf ungesehene Anwendungen. Um die Auswirkungen von ungesehenen Anwendungen zu analysieren, werden IL-Richtlinien trainiert, wobei jeweils eine Anwendung aus dem Trainingsdatensatz ausgeschlossen wird.
Um die Leistungen der beiden Scheduler S₁ und S₂ zu vergleichen, wird die Metrik der Auftragsverlangsamung slowdown _s1,s2 = T_s1/T_s2, verwendet. slowdown _s1,s2 > 1 wenn T_s1 > T_s2. Die durchschnittliche Verlangsamung des Schedulers S₁ im Vergleich zum Scheduler S₂ wird als durchschnittliche Verlangsamung für alle Jobs bei allen Injektionsraten berechnet. Die Ergebnisse bieten eine interessante und intuitive Erklärung für die durchschnittliche Verlangsamung der Ausführungszeiten für jede der Ausführungsarten, bei denen eine Ausnahme gemacht wird.
ist eine grafische Darstellung, in der die durchschnittliche Verlangsamung von IL-LOO (Baseline IL Leave-One-Out) und der vorgeschlagenen Politik mit DAgger Leave-One-Out (IL-LOO-DAgger) Iterationen mit dem Oracle verglichen wird. Die vorgeschlagene Strategie übertrifft die IL-Baseline für alle Anwendungen, wobei die signifikantesten Gewinne bei den Anwendungen WiFi-RX und SC-RX erzielt werden. Diese beiden Anwendungen bestehen aus einer Viterbi-Decoder-Operation, die auf Allzweck-Cores sehr teuer und auf Hardware-Beschleunigern sehr effizient zu berechnen ist. Wenn diese Anwendungen ausgeschlossen werden, werden die IL-Richtlinien nicht mit den entsprechenden Zuständen im Trainingsdatensatz konfrontiert und treffen falsche Entscheidungen. Die fehlerhaften PE-Zuweisungen führen zu einer durchschnittlichen Verlangsamung von mehr als 2x für die Empfängeranwendungen. Die Verlangsamung, wenn die Senderanwendungen (WiFi-TX und SCTX) vom Training ausgeschlossen werden, beträgt etwa das 1,13-fache. Die Anwendungen zur Entfernungserkennung und zur zeitlichen Abschwächung erfahren eine Verlangsamung um das 1,25-fache bzw. 1,54-fache, wenn die Anwendungen nicht berücksichtigt werden. Das Ausmaß der Verlangsamung in jedem Szenario hängt von der vom Training ausgeschlossenen Anwendung und ihrem Ausführungszeitprofil in den verschiedenen Verarbeitungsclustern ab. Zusammenfassend lässt sich sagen, dass sich die durchschnittliche Verlangsamung aller „leave-one-out“ IL-Policies nach DAgger (IL-LOO-DAgger) auf ~1,01 × im Vergleich zu Oracle verbessert, wie in dargestellt.
ist eine grafische Darstellung der durchschnittlichen Auftragsausführungszeiten für die Oracle-, Baseline-IL- sowie IL-LOO- und IL-LOO-DAgger-Iterationen, wobei die WiFi-TX-Anwendung weggelassen wurde. ist eine grafische Darstellung der durchschnittlichen Auftragsausführungszeiten für Oracle, Baseline-IL, sowie IL-LOO und IL-LOO-DAgger Iterationen ohne die WiFi-RX Anwendung. ist eine grafische Darstellung der durchschnittlichen Auftragsausführungszeiten für die Oracle-, Baseline-IL- sowie IL-LOO- und IL-LOO-DAgger-Iterationen ohne die RangeDet-Anwendung. ist eine grafische Darstellung der durchschnittlichen Auftragsausführungszeiten für Oracle, Baseline-IL, sowie IL-LOO und IL-LOO-DAgger Iterationen ohne die SC-TX Anwendung. ist eine grafische Darstellung der durchschnittlichen Auftragsausführungszeiten für Oracle, Baseline-IL, sowie IL-LOO- und IL-LOO-DAgger-Iterationen ohne die SC-RX-Anwendung. ist eine grafische Darstellung der durchschnittlichen Auftragsausführungszeiten für Oracle, Baseline-IL sowie IL-LOO- und IL-LOO-DAgger-Iterationen ohne die TempMit-Anwendung.
Die höchste Anzahl von DAgger-Iterationen war 8 für die SC-RX-Anwendung und die niedrigste war 2 für die Anwendung zur Entfernungsmessung. Wenn das DAgger-Kriterium auf eine Verlangsamung um das 1,02-fache gelockert wird, erreichen alle Anwendungen dasselbe in weniger als 5 Iterationen. Die drastische Verbesserung der Genauigkeit der IL-Richtlinien mit wenigen Iterationen zeigt, dass die Richtlinien schnell und gut auf unbekannte Anwendungen verallgemeinert werden können, wodurch sie für die Anwendbarkeit zur Laufzeit geeignet sind.
IL-Scheduler Generalisierung mit Laufzeitvariationen: Aufgaben unterliegen Laufzeitschwankungen aufgrund von Schwankungen der Systemauslastung, des Speichers und der Überlastung. Daher ist es von entscheidender Bedeutung, die Leistung des vorgeschlagenen Ansatzes zu analysieren, wenn Aufgaben solchen Schwankungen ausgesetzt sind, anstatt nur ihre statischen Profile zu beobachten. Der Simulator berücksichtigt die Schwankungen, indem er eine Gauß-Verteilung verwendet, um Schwankungen in der Ausführungszeit zu erzeugen. Um eine Bewertung in einem realistischen Szenario zu ermöglichen, werden alle Aufgaben in jeder Anwendung auf großen und kleinen Kernen des Odroid-XU3 sowie auf Cortex-A53-Kernen und Hardware-Beschleunigern auf dem Zynq für Variationen in der Ausführungszeit profiliert.
Die durchschnittliche Standardabweichung wird in Tabelle VIII als Verhältnis zur Ausführungszeit für die Aufgaben dargestellt. Die maximale Standardabweichung beträgt weniger als 2 % der Ausführungszeit auf der Zynq-Plattform und weniger als 8 % auf dem Odroid-XU3. Um Schwankungen in der Laufzeit zu berücksichtigen, wird während der Simulation ein Rauschen von 1 %, 5 %, 10 % und 15 % in der Ausführungszeit der Aufgaben hinzugefügt. Die IL-Richtlinien erreichen in allen Fällen von Laufzeitschwankungen durchschnittliche Verlangsamungen von weniger als 1,01 ×. Obwohl die IL-Richtlinien mit statischen Ausführungszeitprofilen trainiert werden, zeigen die oben genannten Ergebnisse, dass sich die IL-Richtlinien gut an Ausführungszeitvariationen während der Laufzeit anpassen. In ähnlicher Weise lassen sich die Richtlinien auch auf Variationen der Kommunikationszeit und des Energieverbrauchs verallgemeinern. Tabelle VIII Standardabweichung (in Prozent der Ausführungszeit) Profiling von Anwendungen in Odroid-XU3 und Zynq ZCU-102

Application WiFi-TX WiFi-RX RangeDet SC-TX SC-RX Temp Mit

Zynq ZCU-102 0.34 0.56 0.66 1.15 1.80 0.63

Odroid-XU3 6.43 5.04 5.43 6.76 7.14 3.14
IL-Scheduler Verallgemeinerung mit Plattformkonfiguration: In diesem Abschnitt wird eine detaillierte Analyse der AWL-Richtlinien durch Variation der Konfiguration, d. h. der Anzahl der Cluster, der Mehrzweck-Cores und der Hardware-Beschleuniger, durchgeführt. Zu diesem Zweck werden fünf verschiedene SoC-Konfigurationen ausgewählt, wie in Tabelle IX dargestellt. Die Oracle-Richtlinie für die Konfiguration G1 wird wie folgt bezeichnet π*^G1. Eine IL-Richtlinie, die für die Konfiguration G1 ausgewertet wird, wird als π^G1. G1 ist die Basiskonfiguration, die für eine umfassende Bewertung verwendet wird. Zwischen den Konfigurationen G1-G4 wird die Anzahl der PEs innerhalb jedes Clusters variiert. Es wird auch ein degenerierter Fall betrachtet, der nur LITTLE und big clusters umfasst (Konfiguration G5). Die IL-Richtlinien werden nur mit der Konfiguration G1 trainiert. Die durchschnittlichen Ausführungszeiten von π^G1, π^G2, und π^G3 liegen innerhalb von 1%, π^G4 liegt innerhalb von 2%, und π^G5 liegt innerhalb von 3% ihres jeweiligen Orakels. Tabelle IX: Konfiguration von Multi-Core-Plattformen

Platform Config. LITTLE PEs big PEs MatMut Acc. PEs FFT Acc. PEs Decoder Acc. PEs

G1 (Baseline) 4 4 2 4 2

G2 2 2 2 2 2

G3 1 1 1 1 1

G4 4 4 1 1 1

G5 4 4 0 0 0
ist eine grafische Darstellung der Bewertung der IL-Politik mit verschiedenen Konfigurationen der Multi-Core-Plattform. Die Genauigkeit von π^G5 in Bezug auf das entsprechende Oracle (π*^G5) ist etwas niedriger (97 %), da die Plattform die Rechenressourcen sehr schnell sättigt, wie in dargestellt. Auf der Grundlage dieser Auswertungen lassen sich die IL-Richtlinien für die verschiedenen Konfigurationen der Many-Core-Plattform gut verallgemeinern. Die Änderung der Systemkonfiguration wird in den Merkmalen (in den Ausführungszeiten, PE-Verfügbarkeitszeiten usw.) genau erfasst, was eine gute Verallgemeinerung auf neue Plattformkonfigurationen ermöglicht. Wenn sich die Clusterkonfiguration in der Many-Core-Plattform ändert, sind die IL-Richtlinien gut verallgemeinerbar (innerhalb von 3 %), können aber auch durch die Verwendung von Dagger verbessert werden, um eine bessere Leistung zu erzielen (innerhalb von 1 % des Oracle).
F. Leistungsanalyse mit mehreren Workloads
Um die Verallgemeinerungsfähigkeit der IL-Richtlinien zu demonstrieren, die auf einer Arbeitslast (IL-DAgger) trainiert und aggregiert wurden, wird die Leistung derselben Richtlinien auf 50 verschiedenen Arbeitslasten bewertet, die aus verschiedenen Kombinationen von Anwendungsmischungen mit unterschiedlichen Injektionsraten bestehen, wobei jede dieser Arbeitslasten 500 Frames enthält. Für diese umfassende Bewertung werden Arbeitslasten betrachtet, die jeweils eine der folgenden Funktionen intensiv nutzen: WiFi-TX, WiFi-RX, Entfernungserkennung, SC-TX, SC-RX und zeitliche Mitigation. Schließlich werden auch Workloads betrachtet, bei denen alle Anwendungen ähnlich verteilt sind.
ist eine grafische Darstellung, in der die durchschnittliche Verlangsamung für jede der 50 verschiedenen Arbeitslasten (dargestellt als W-1, W-2 usw.) normalisiert auf IL-DAgger-Richtlinien mit Oracle verglichen wird. Während W-22 eine Verlangsamung um das 1,01-fache im Vergleich zu Oracle feststellt, liegt die durchschnittliche Verlangsamung bei allen anderen Arbeitslasten unter dem 1,01-fachen (innerhalb von 1 % von Oracle). Unabhängig von der Verteilung der Anwendungen in den Workloads nähern sich die IL-Richtlinien dem Oracle gut an. Im Durchschnitt liegt die Verlangsamung unter dem 1,01-fachen, was zeigt, dass die IL-Richtlinien für verschiedene Arbeitslasten und Streaming-Intensitäten geeignet sind.
G. Bewertung mit Energie- und Energieverzögerungszielen
Die durchschnittliche Ausführungszeit ist entscheidend für die Konfiguration von Computersystemen, um die Anforderungen an die Latenzzeit von Anwendungen und die Benutzerfreundlichkeit zu erfüllen. Eine weitere kritische Metrik in modernen Computersystemen, insbesondere bei batteriebetriebenen Plattformen, ist der Energieverbrauch. Daher wird in diesem Abschnitt der vorgeschlagene IL-basierte Ansatz mit den folgenden Zielen vorgestellt: Leistung, Energie, Energie-Verzögerungs-Produkt (EDP) und Energie-Verzögerungs-Produkt² (ED² P). ETF wird angepasst, um Orakel für jedes Ziel zu erzeugen. Dann werden die verschiedenen Orakel verwendet, um IL-Politiken für die entsprechenden Ziele zu trainieren. Die Scheduling-Entscheidungen sind für diese Orakel wesentlich komplexer. Daher wird eine RT der Tiefe 16 (die Ausführungszeit verwendet eine RT der Tiefe 12) verwendet, um die Entscheidungen genau zu lernen. Die durchschnittliche Latenzzeit pro Scheduling-Entscheidung bleibt bei RT der Tiefe 16 ähnlich (~1,1µ s) auf Cortex-A53.
ist eine grafische Darstellung der durchschnittlichen Ausführungszeit der Arbeitslast mit Orakeln und IL-Richtlinien für Leistungs-, EDP- und ED² P-Ziele. ist eine grafische Darstellung des durchschnittlichen Energieverbrauchs der Arbeitslast mit Orakeln und IL-Richtlinien für Leistungs-, EDP- und ED² P-Ziele. Die niedrigste Energie wird durch das Energie-Orakel erreicht, während sie erwartungsgemäß ansteigt, wenn mehr Gewicht auf die Leistung gelegt wird (EDP→ ED P²→ performance). Die durchschnittliche Ausführungszeit und der Energieverbrauch liegen in allen Fällen innerhalb von 1 % der entsprechenden Orakel. Dies zeigt, dass der vorgeschlagene IL-Planungsansatz leistungsfähig ist, da er von Orakeln lernt, die für jedes Ziel optimieren.
H. Vergleich mit Reinforcement Learning
Da die modernsten maschinellen Lerntechniken nicht auf das Streaming-DAG-Scheduling in heterogenen Multicore-Plattformen abzielen, wird eine auf Policy-Gradient basierende Reinforcement-Learning-Technik unter Verwendung eines tiefen neuronalen Netzes (mehrschichtiges Perzeptron mit 4 versteckten Schichten mit 32 Neuronen in jeder versteckten Schicht) implementiert, um einen Vergleich mit der vorgeschlagenen IL-basierten Task-Scheduling-Technik anzustellen. Bei der RL-Implementierung wird die Explorationsrate zwischen 0,01 und 0,99 und die Lernrate zwischen 0,001 und 0,01 variiert. Die Belohnungsfunktion wurde von H. Mao, M. Schwarzkopf, S. B. Venkatakrishnan, Z. Meng und M. Alizadeh, „Learning Scheduling Algorithms for Data Processing Clusters," in ACM Special Interest Group on Data Communication, 2019, S. 270-288 übernommen. RL beginnt mit zufälligen Gewichten und aktualisiert diese dann basierend auf dem Ausmaß der Exploration, der Ausnutzung, der Lernrate und der Belohnungsfunktion. Diese Faktoren beeinflussen die Konvergenz und die Qualität der gelernten RL-Modelle.
Weniger als 20 % der Bewertungen mit RL konvergieren zu einer stabilen Strategie, und weniger als 10 % von ihnen bieten eine wettbewerbsfähige Leistung im Vergleich zum vorgeschlagenen IL-Scheduler. Die RL-Lösung, die am besten abschneidet, wird für den Vergleich mit dem IL-Scheduler ausgewählt. Die Oracle-Generierung und das Training der vorgeschlagenen Technik dauern 5,6 Minuten bzw. 4,5 Minuten, wenn sie auf einem Intel Xeon E5-2680 Prozessor mit 2,40 GHz laufen. Im Gegensatz dazu konvergiert eine RL-basierte Scheduling-Politik, die die Policy-Gradient-Methode verwendet, in 300 Minuten auf demselben Rechner. Die vorgeschlagene Technik ist also 30 Mal schneller als RL.
ist eine grafische Darstellung, die die durchschnittliche Ausführungszeit zwischen Oracle-, IL- und RL-Richtlinien vergleicht, um eine Arbeitslast zu planen, die aus einer Mischung von sechs Streaming-Anwendungen aus der realen Welt besteht. Wie in zu sehen ist, liegt der RL-Scheduler innerhalb von 11 % des Oracle-Schedulers, während der IL-Scheduler eine durchschnittliche Ausführungszeit aufweist, die innerhalb von 1 % des Oracle-Schedulers liegt.
Im Allgemeinen leiden RL-basierte Scheduler unter folgenden Nachteilen: (1) Notwendigkeit einer übermäßigen Feinabstimmung der Parameter (Lernrate, Explorationsrate und NN-Struktur), (2) Entwurf einer Belohnungsfunktion und (3) langsame Konvergenz bei komplexen Problemen. Im Gegensatz dazu werden IL-Politiken von einer starken Überwachung geleitet, wodurch das Problem der langsamen Konvergenz und die Notwendigkeit einer Belohnungsfunktion entfällt.
I. Komplexitätsanalyse des vorgeschlagenen Ansatzes
In diesem Abschnitt wird die Komplexität des vorgeschlagenen IL-basierten Aufgabenplanungsansatzes mit ETF verglichen, das zur Erstellung der Oracle-Richtlinien verwendet wird. Die Komplexität von ETF ist O(n² m), wobei n die Anzahl der Aufgaben und m die Anzahl der PEs im System ist. Während ETF für die Verwendung bei der Oracle-Generierung (offline) geeignet ist, ist es für die Online-Verwendung aufgrund der quadratischen Komplexität in Abhängigkeit von der Anzahl der Aufgaben nicht effizient. Die vorgeschlagene IL-Strategie, die einen Regressionsbaum verwendet, hat jedoch eine Komplexität von O(n). Da die Komplexität der vorgeschlagenen IL-basierten Politik linear ist, ist sie praktisch in heterogenen Systemen mit vielen Kernen zu implementieren.
V. Computer-System
ist ein Blockdiagramm eines Computersystems 1300, das für die Implementierung von Laufzeit-Task-Scheduling mit IL gemäß den hier offengelegten Ausführungsformen geeignet ist. Die hierin beschriebenen Ausführungsformen können das Computersystem 1300 umfassen oder als solches implementiert werden, das jedes Computer- oder elektronische Gerät umfasst, das in der Lage ist, Firmware, Hardware und/oder ausführende Softwarebefehle zu enthalten, die zur Durchführung der oben beschriebenen Verfahren oder Funktionen verwendet werden können. In dieser Hinsicht kann das Computersystem 1300 ein Schaltkreis oder Schaltkreise sein, die in einer elektronischen Leiterplatte enthalten sind, wie z.B. eine gedruckte Leiterplatte (PCB), ein Server, ein Personalcomputer, ein Desktop-Computer, ein Laptop-Computer, eine Reihe von Computern, ein persönlicher digitaler Assistent (PDA), ein Computer-Pad, ein mobiles Gerät oder jedes andere Gerät, und kann z.B. einen Server oder den Computer eines Benutzers darstellen.
Das beispielhafte Computersystem 1300 in dieser Ausführungsform umfasst eine Verarbeitungsvorrichtung 1302 oder einen Prozessor, einen Systemspeicher 1304 und einen Systembus 1306. Der Systemspeicher 1304 kann einen nichtflüchtigen Speicher 1308 und einen flüchtigen Speicher 1310 enthalten. Der nichtflüchtige Speicher 1308 kann einen Festwertspeicher (ROM), einen löschbaren programmierbaren Festwertspeicher (EPROM), einen elektrisch löschbaren programmierbaren Festwertspeicher (EEPROM) und Ähnliches umfassen. Der flüchtige Speicher 1310 umfasst im Allgemeinen einen Speicher mit wahlfreiem Zugriff (RAM) (z. B. einen dynamischen Speicher mit wahlfreiem Zugriff (DRAM), wie einen synchronen DRAM (SDRAM)). Ein grundlegendes Eingabe-/Ausgabesystem (BIOS) 1312 kann im nichtflüchtigen Speicher 1308 gespeichert werden und kann die grundlegenden Routinen enthalten, die bei der Übertragung von Informationen zwischen Elementen innerhalb des Computersystems 1300 helfen.
Der Systembus 1306 bietet eine Schnittstelle für Systemkomponenten, einschließlich, aber nicht beschränkt auf den Systemspeicher 1304 und das Verarbeitungsgerät 1302. Bei dem Systembus 1306 kann es sich um eine beliebige von mehreren Arten von Busstrukturen handeln, die weiter mit einem Speicherbus (mit oder ohne Speicher-Controller), einem Peripheriebus und/oder einem lokalen Bus verbunden werden können, wobei eine beliebige von mehreren kommerziell verfügbaren Busarchitekturen verwendet wird.
Die Verarbeitungsvorrichtung 1302 stellt eine oder mehrere handelsübliche oder proprietäre Mehrzweckverarbeitungsvorrichtungen dar, wie z. B. einen Mikroprozessor, eine Zentraleinheit (CPU) oder Ähnliches. Insbesondere kann die Verarbeitungsvorrichtung 1302 ein CISC-Mikroprozessor (Complex Instruction Set Computing), ein RISC-Mikroprozessor (Reduced Instruction Set Computing), ein VLIW-Mikroprozessor (Very Long Instruction Word), ein Prozessor, der andere Befehlssätze implementiert, oder andere Prozessoren sein, die eine Kombination von Befehlssätzen implementieren. Die Verarbeitungsvorrichtung 1302 ist so konfiguriert, dass sie Verarbeitungslogikbefehle zur Durchführung der hier besprochenen Operationen und Schritte ausführt.
In dieser Hinsicht können die verschiedenen logischen Blöcke, Module und Schaltungen, die in Verbindung mit den hier offengelegten Ausführungsformen beschrieben werden, mit der Verarbeitungsvorrichtung 1302 implementiert oder ausgeführt werden, bei der es sich um einen Mikroprozessor, ein feldprogrammierbares Gate-Array (FPGA), einen digitalen Signalprozessor (DSP), eine anwendungsspezifische integrierte Schaltung (ASIC) oder eine andere programmierbare Logikvorrichtung, eine diskrete Gate- oder Transistorlogik, diskrete Hardwarekomponenten oder eine beliebige Kombination davon handeln kann, die zur Ausführung der hier beschriebenen Funktionen entwickelt wurde. Darüber hinaus kann die Verarbeitungsvorrichtung 1302 ein Mikroprozessor oder ein herkömmlicher Prozessor, Controller, Mikrocontroller oder eine Zustandsmaschine sein. Die Verarbeitungsvorrichtung 1302 kann auch als eine Kombination von Rechenvorrichtungen implementiert sein (z. B. eine Kombination aus einem DSP und einem Mikroprozessor, eine Vielzahl von Mikroprozessoren, ein oder mehrere Mikroprozessoren in Verbindung mit einem DSP-Kern oder eine andere derartige Konfiguration).
Das Computersystem 1300 kann ferner ein nicht flüchtiges, computerlesbares Speichermedium enthalten oder mit diesem gekoppelt sein, z. B. ein Speichergerät 1314, das ein internes oder externes Festplattenlaufwerk (HDD), einen Flash-Speicher oder Ähnliches darstellen kann. Das Speichergerät 1314 und andere Laufwerke, die mit computerlesbaren Medien und computerverwendbaren Medien verbunden sind, können eine nichtflüchtige Speicherung von Daten, Datenstrukturen, computerausführbaren Befehlen und Ähnlichem ermöglichen. Obwohl sich die obige Beschreibung der computerlesbaren Medien auf eine Festplatte bezieht, sollte man sich darüber im Klaren sein, dass auch andere Arten von Medien, die von einem Computer gelesen werden können, wie z. B. optische Platten, Magnetkassetten, Flash-Speicherkarten, Kassetten und dergleichen, in der Betriebsumgebung verwendet werden können, und dass darüber hinaus alle diese Medien computerausführbare Anweisungen zur Durchführung neuartiger Verfahren der offengelegten Ausführungsformen enthalten können.
Ein Betriebssystem 1316 und eine beliebige Anzahl von Programmmodulen 1318 oder anderen Anwendungen können im flüchtigen Speicher 1310 gespeichert werden, wobei die Programmmodule 1318 eine breite Palette von computerausführbaren Anweisungen darstellen, die Programmen, Anwendungen, Funktionen und dergleichen entsprechen, die die hier beschriebene Funktionalität ganz oder teilweise implementieren können, beispielsweise durch Anweisungen 1320 auf der Verarbeitungsvorrichtung 1302. Die Programmmodule 1318 können sich auch auf dem Speichermechanismus befinden, der von der Speichervorrichtung 1314 bereitgestellt wird. So kann die gesamte oder ein Teil der hier beschriebenen Funktionalität als Computerprogrammprodukt implementiert werden, das auf einem transitorischen oder nichttransitorischen computerverwendbaren oder computerlesbaren Speichermedium gespeichert ist, wie z. B. der Speichervorrichtung 1314, dem flüchtigen Speicher 1310, dem nichtflüchtigen Speicher 1308, den Anweisungen 1320 und dergleichen. Das Computerprogrammprodukt enthält komplexe Programmieranweisungen, wie z. B. komplexen computerlesbaren Programmcode, um die Verarbeitungsvorrichtung 1302 zu veranlassen, die Schritte auszuführen, die zur Umsetzung der hier beschriebenen Funktionen erforderlich sind.
Ein Bediener, wie z. B. der Benutzer, kann auch in der Lage sein, einen oder mehrere Konfigurationsbefehle an das Computersystem 1300 über eine Tastatur, ein Zeigegerät, wie z. B. eine Maus, oder eine berührungsempfindliche Oberfläche, wie z. B. das Anzeigegerät, über eine Eingabegeräteschnittstelle 1322 oder aus der Ferne über eine Webschnittstelle, ein Terminalprogramm oder Ähnliches über eine Kommunikationsschnittstelle 1324 einzugeben. Die Kommunikationsschnittstelle 1324 kann drahtgebunden oder drahtlos sein und die Kommunikation mit einer beliebigen Anzahl von Geräten über ein Kommunikationsnetz auf direkte oder indirekte Weise erleichtern. Ein Ausgabegerät, z. B. ein Anzeigegerät, kann mit dem Systembus 1306 verbunden und über einen Videoanschluss 1326 angesteuert werden. Zusätzliche Eingänge und Ausgänge für das Computersystem 1300 können über den Systembus 1306 bereitgestellt werden, um die hier beschriebenen Ausführungsformen zu implementieren.
Die in den beispielhaften Ausführungsformen beschriebenen Arbeitsschritte werden hier als Beispiele und Diskussionsgrundlage beschrieben. Die beschriebenen Vorgänge können in zahlreichen anderen als den dargestellten Abläufen durchgeführt werden. Darüber hinaus können Vorgänge, die in einem einzigen Arbeitsschritt beschrieben werden, tatsächlich in einer Reihe von verschiedenen Schritten durchgeführt werden. Außerdem können ein oder mehrere der in den Beispielen beschriebenen Arbeitsschritte kombiniert werden.
Fachleute werden Verbesserungen und Änderungen an den bevorzugten Ausführungsformen der vorliegenden Offenbarung erkennen. Alle diese Verbesserungen und Modifikationen werden im Rahmen der hier offengelegten Konzepte und der folgenden Ansprüche berücksichtigt.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

WO 63/104260 [0002]

Zitierte Nicht-Patentliteratur

Joshua Mack, Nirmal Kumbhare, N. K. Anish, Umit Y. Ogras und Ali Akoglu, „User-Space Emulation Framework For Domain-Specific SoC Design“, in 2020 IEEE International Parallel and Distributed Processing Symposium Workshops (IPDPSW), pp. 44-53, IEEE, 2020 [0047]
S.E. Arda et al., „DS3: A System-Level Domain-Specific System-an-Chip Simulation Framework,“ in IEEE Transactions on Computers, vol. 69, no. 8, pp. 1248-1262, 2020 [0048]
H. Mao, M. Schwarzkopf, S. B. Venkatakrishnan, Z. Meng und M. Alizadeh, „Learning Scheduling Algorithms for Data Processing Clusters,“ in ACM Special Interest Group on Data Communication, 2019, S. 270-288 [0080]

Claims

Ein Rahmenwerk für die Anwendungsplanung, das Folgendes umfasst: einen heterogenen System-on-Chip (SoC)-Simulator, der so konfiguriert ist, dass er eine Vielzahl von Planungsalgorithmen für eine Vielzahl von Anwendungsaufgaben simuliert; und ein Orakel, das so konfiguriert ist, dass es Aktionen für die Aufgabenplanung während der Laufzeit vorhersagt; und einen Richtliniengenerator für Imitationslernen (IL), der so konfiguriert ist, dass er IL-Richtlinien für die Aufgabenplanung während der Laufzeit auf einem heterogenen SoC erzeugt, wobei die IL-Richtlinien unter Verwendung des Orakels und des SoC-Simulators trainiert werden.
Der Anwendungsplanungsrahmen nach Anspruch 1, wobei der IL-Richtliniengenerator so konfiguriert ist, dass er die IL-Richtlinien auf der Grundlage von überwachtem maschinellem Lernen mit dem Orakel erzeugt, so dass die IL-Richtlinien das Orakel für die Planung von Aufgaben zur Laufzeit des heterogenen SoC imitieren.
Der Anwendungsplanungsrahmen nach Anspruch 2 umfasst ferner einen Datenaggregator (DAgger), der so konfiguriert ist, dass er die IL-Richtlinien auf der Grundlage von Orakelaktionen und Ergebnissen der IL-Richtlinien während der Simulation verbessert.
Der Anwendungsplanungsrahmen nach Anspruch 3, wobei der DAgger so konfiguriert ist, dass er einen aktuellen Systemzustand zusammenfasst und eine aktuelle Orakelaktion für eine Aufgabe kennzeichnet, wenn sich die IL-Politikaktionen von den Orakelaktionen unterscheiden.
Der Anwendungsplanungsrahmen nach Anspruch 3, wobei der DAgger ferner so konfiguriert ist, dass er die IL-Richtlinien auf der Grundlage der Ergebnisse der IL-Richtlinien während der Laufzeit auf dem heterogenen SoC verbessert.
Der Rahmen für die Anwendungsplanung nach Anspruch 1, wobei der SoC-Simulator auf einem heterogenen SoC mit heterogenen Verarbeitungselementen basiert, die in verschiedene Arten von Verarbeitungsclustern gruppiert sind.
Der Anwendungsplanungsrahmen nach Anspruch 6, wobei die IL-Richtlinien hierarchisch sind und eine IL-Richtlinie der ersten Ebene einen der Verarbeitungscluster vorhersagt, der für jede der Vielzahl von Anwendungsaufgaben geplant werden soll.
Der Anwendungsplanungsrahmen nach Anspruch 7, wobei eine IL-Richtlinie zweiter Ebene ein Verarbeitungselement innerhalb des einen vorhergesagten Verarbeitungsclusters vorhersagt, das für jede der Vielzahl von Anwendungsaufgaben geplant werden soll.
Der Anwendungsplanungsrahmen nach Anspruch 8, wobei der heterogene SoC einen oder mehrere allgemeine Prozessorcluster und einen oder mehrere Hardwarebeschleunigercluster umfasst.
Das Anwendungsplanungs-Framework nach Anspruch 9, wobei der eine oder die mehreren Hardware-Beschleuniger-Cluster mindestens eines der folgenden Elemente umfasst: einen Cluster von Matrix-Multiplizierern, einen Cluster von Viterbi-Dekodierern, einen Cluster von FFT-Beschleunigern (Fast Fourier Transform), einen Cluster von Grafikverarbeitungseinheiten (GPUs), einen Cluster von digitalen Signalprozessoren (DSPs) oder einen Cluster von Tensor-Verarbeitungseinheiten (TPUs).