DE102010053701A1

DE102010053701A1 - Beziehungsmodellierung für Leistungsanalyse von Mehrkernprozessoren

Info

Publication number: DE102010053701A1
Application number: DE102010053701A
Authority: DE
Inventors: Christopher J. Oreg. Cormack; Nathaniel Calif. Duca; Jason Oreg. Plumb
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2009-12-23
Filing date: 2010-12-08
Publication date: 2011-08-25
Also published as: TW201145015A; US20110154294A1; US8826234B2; GB201020675D0; GB2476544A; TWI506420B; CN102141954A; CN102141954B

Abstract

Ein Beziehungsmodell kann verwendet werden, um Primitiven für jeden einer Vielzahl von Threads in einem Mehrkernprozessor zu codieren. Die Primitiven können Tasks und Parameter, wie beispielsweise Puffer, beinhalten. Die Beziehungen können mit verschiedenen Tasks verbunden sein. Die Tasks mit der die Beziehungen anzeigenden Codierung können sodann bei Benutzerauswahl verwendet werden, um eine Visualisierung der funktionalen Beziehungen zwischen Tasks anzuzeigen.

Description

Hintergrund
Dies bezieht sich im Allgemeinen auf Mehrkernprozessoren und insbesondere auf Leistungsanalyse von Mehrkernmaschinen.
Moderne Universal- und Grafikprozessoren können einen oder mehr Kerne beinhalten. Diese Prozessoren können eine große Anzahl an Threads laufen lassen. Unter Anbetracht der Anzahl an Tasks und der Anzahl an unterschiedlichen Threads, die laufen können, kann das Analysieren der Leistung eines Prozessors daher ein komplexes Unternehmen miteinbeziehen.
Herkömmlicherweise ist ein Trace eine grafische Abbildung eines zeitlichen Ablaufs zwischen Tasks, die auf einem Prozessor laufen. Softwarebasierte Trace-Analyse ermöglicht es einem Softwaredesigner den Ablauf von Operationen zwischen Tasks zu verstehen.
Im Fall von Mehrkernprozessoren kann jedoch eine ausgereifterte Analyse von Nöten sein.
Kurze Beschreibung der Zeichnungen
1 ist eine schematische Abbildung einer erfindungsgemäßen Ausführungsform;
2 ist ein Ablaufdiagramm, das einen Ablauf abbildet, der von der in 1 gezeigten Ausführungsform verwendet wird;
3 ist eine Visualisierung eines taskbasierten Beziehungsmodells in Übereinstimmung mit einer erfindungsgemäßen Ausführungsform;
4 ist eine Visualisierung einer Parent/Child-Beziehung, hergestellt in Übereinstimmung mit einer erfindungsgemäßen Ausführungsform; und
5 ist eine Visualisierung von Abhängigkeitsbeziehungen in Übereinstimmung mit einer weiteren erfindungsgemäßen Ausführungsform.
Ausführliche Beschreibung
In Übereinstimmung mit einigen erfindungsgemäßen Ausführungsformen können Beziehungen neben zeitlicher Ablaufsteuerung zwischen Code-Einheiten, genannt Tasks, visualisiert werden. Ein Task ist jede herkömmliche Arbeitseinheit zum Schedulen und Ausführen. Dies kann jeder Teil von Code sein, mit einem Anfang und einem Ende. Die Zeitdauer kann definiert werden als eine Anzahl an Zyklen, um den Task auszuführen.
Traces sind Verbindungen zwischen Tasks. Ein Beziehungsmodell gibt die Beziehung zwischen Tasks hinsichtlich Parent zu Child, Geschwister, Abhängigkeit sowie Erzeuger und Verbraucher wieder. Andere Beziehungen können ebenfalls verwendet werden.
Die Parent/Child-Beziehung besteht zwischen einem ersten Task und einem zweiten Task, der von dem ersten Task hervorgebracht wurde. Eine Abhängigkeit besteht zwischen einem ersten und einem zweiten Task, wenn der erste Task von dem zweiten Task zur Ausführung abhängt. Eine Erzeuger/Verbraucher-Beziehung bedeutet, dass ein erster Task Daten erzeugt und diese in einen Puffer gibt, und dass ein zweiter Task diese Daten von dem Puffer verbraucht.
Eine Primitive ist jede Einheit, die Teil einer Beziehung ist. Ein Task ist eine Art von Primitive. Eine weitere Primitive wird Parameter genannt. Ein Parameter kann ein Puffer, ein Name-Wert-Paar, eine Zeichenkette oder jede andere Art von normalem Datentyp oder -struktur sein, die eine Beziehung zu einem Task aufweist. Andere Primitiven können ebenfalls verwendet werden.
Unter Bezugnahme auf 1 kann das Leistungsanalysewerkzeug 10 eine Steuerung 12 beinhalten, was ein Prozessor sein kann. Der Prozessor kann ein Mehrkernprozessor sein. Bei einer Ausführungsform kann dies ein Grafikprozessor und bei einer Ausführungsform kann dies ein SIMD-(single instruction multiple data)-Mehrkernprozessor sein. Die Steuerung 12 ist mit einem Speicher 14 gekoppelt, der eine grafische Benutzeroberfläche (graphical user interface, GUI) 16 oder Frontend des Werkzeugs, eine Anzahl an Anwendungsprogrammschnittstellen (application program interfaces, APIs) 18 speichern kann, die die Primitiven und die Beziehungen zwischen Primitiven und einer Library 20 codieren, die den Werkzeugkasten an zu verwendbaren Merkmalen bereitstellt. Die Steuerung kann mit einem Eingang/Ausgang 22 gekoppelt sein, um es dem Benutzer zu ermöglichen, Informationen einzugeben und eine Ausgabe zu empfangen. Ein Display 24 kann verwendet werden, um die Beziehungen zwischen Primitiven, einschließlich Tasks, zu visualisieren.
Das Leistungsanalysewerkzeug 10 wird von Softwareentwicklern verwendet, um, durch Nachvollziehen der Beziehungen zwischen Primitiven, wie beispielsweise Tasks innerhalb dieser Software, die Leistung ihrer Software zu verbessern. Durch Nachvollziehen dieser Beziehungen kann der Softwareentwickler verstehen, wie die Softwareleistung verbessert werden kann.
Im Allgemeinen entwickelt der Softwareentwickler zwei Versionen des Codes. Eine Version des Codes ist der Code, der lediglich die gewünschte Funktion ausführt, wie beispielsweise ein Spiel. Die andere Version des Codes beinhaltet die APIs 18 in sich, die bei einigen Ausführungsformen die Visualisierungen der Primitive-Beziehungen erzeugen (während bei anderen Ausführungsformen binäre Ausgaben ohne Visualisierungen zur weiteren Analyse verwendet werden können). Die Version des Codes mit den APIs wird instrumentierter Code genannt. Durch Strömen des instrumentierten Codes zu der grafischen Frontend-Benutzeroberfläche 16 wird es dem Designer ermöglicht, zu sehen, was in dem Code abläuft. Gezeigt werden die in dem Code laufenden Threads, die Tasks innerhalb der Threads und, am wichtigsten, die funktionalen Beziehungen zwischen diesen Tasks.
Unter Bezugnahme auf 2 beginnt der Ablauf, der von den Anwendungsprogrammschnittstellen 18 implementiert wird, durch Empfangen der Auswahl eines Threads, wie in Block 22 angezeigt. Als nächstes wird ein Primitive-Identifikator ausgewählt, wie in Block 24 angezeigt. Der Identifikator wird in Block 26 registriert. Als nächstes wird in Block 28 der Identifikator einer Primitive zugeteilt.
An dieser Stelle tritt der Designer nun in die Beziehungen zwischen einer ausgewählten Primitive und anderen Primitiven ein. Die ausgewählte Primitive wird „diese” Primitive genannt und die Primitiven, mit denen die diese Primitive Beziehungen unterhält, werden „jene” Primitiven genannt.
Bei einigen Ausführungsformen impliziert der Ablauf 18 automatisch eine Anzahl an Beziehungen über diejenigen hinaus, in die von dem Designer eingetreten wurden. Wenn beispielsweise ein erster Task der Parent von einem zweiten Task ist, dann wird impliziert, dass der zweite Task das Child von dem Parent ist. Gleichermaßen, wenn ein erster Task zu einem zweiten Task in Beziehung steht, und der zweite Task zu einem dritten Task in Beziehung steht, dann wird impliziert, dass der erste und zweite Task ebenfalls in Beziehung stehen, und die Natur der Beziehung kann impliziert werden. Dies kann als transitive Beziehungen oder Beziehungen, die von anderen Beziehungen impliziert werden, bezeichnet werden. Die Verwendung von transitiven Beziehungen verringert bei einigen Ausführungsformen die Last der Dateneingabe auf Seiten des Benutzers. Zusätzlich kann es eine zu N oder Fan-Out-Beziehungen geben. Beispielsweise kann ein einzelner Parent jede Anzahl an Children hervorbringen, und alle diese Children brauchen bei einigen Ausführungsformen nicht einzeln codiert werden.
Zusätzlich stellt der Ablauf 18 Zeitstempel für jeden der Primitive-Identifikatoren bereit. Er stellt ebenfalls die Zeit bereit, wann irgendein Task beginnt und als eine Ausgabe endet. Daher kann er bei einer Ausführungsform eine Reihe von Threads als Reihen in einem Diagramm anzeigen. Jede Reihe kann den Ablauf von Tasks in dem Thread beinhalten. Zusätzlich können verschachtelte Tasks durch Visualisierung ebenfalls angezeigt werden, wie beispielsweise Zeigen des verschachtelten Tasks als sich über den Task, in dem dieser ausgeführt wird, hinausstreckend. Ein Benutzer kann auf einen bestimmten Task klicken, und als Antwort auf die Auswahl des Tasks kann seine Beziehung grafisch angezeigt werden.
Im Gegensatz zu zeitbasierten Tracing-Systemen kann das System 10 beziehungsbasiert sein. Die zeitliche Beziehung zwischen Tasks und verschiedenen Puffern ist weniger wichtig als die Beziehung zwischen ihnen. Bei einigen Ausführungsformen werden Beziehungen innerhalb Tasks gezeigt, sogar dort, wo bei einigen Ausführungsformen ihr relatives Timing nicht gezeigt wird. Daher kann innerhalb des Threads der Zeitablauf von Tasks veranschaulicht werden, aber der zeitliche Ablauf von Tasks in unterschiedlichen Threads kann bei einigen Ausführungsformen nicht angezeigt sein. Bei einigen Ausführungsformen können funktionale, im Gegensatz zu zeitlichen, Beziehungen visualisiert sein. Eine funktionale Beziehung ist neben dem zeitlichen Ablauf jede Beziehung zwischen Tasks.
Bei einer Ausführungsform kann jeder Task durch ein Rechteck dargestellt werden, dessen Länge in der x Richtung eine Funktion hinsichtlich der Dauer der Ausführung ist. Bei einigen Ausführungsformen kann eine Mausklick- und Dragtechnik verwendet werden, um eine Anzahl an Tasks auszuwählen, um die Beziehungen zwischen jenen ausgewählten Tasks und jeden anderen Tasks anzuzeigen.
Daher, als ein einfaches Beispiel, unter Bezugnahme auf 3, gibt es vier Primitiven, einschließlich drei Tasks 36, 38 und 42, und ein Parameter in der Form eines Puffers 40. Die Pfeile 44, 52, 50 und 48 zeigen die Beziehungen zwischen den Tasks. Beispielsweise kann der Vertex-Task 44 seine Ergebnisse in den Puffer 40 geben, und diese Ergebnisse können von dem Pixel-Task 42 verwendet werden. Daher ist der Task 44 der Erzeuger und der Task 42 ist der Verbraucher. Da der Vertex-Task 38 durch den Draw-Task 36 erzeugt wurde, zeigt der Pfeil 52 an, dass der Vertex-Task das Child von dem Draw-Task 36 ist. Gleichermaßen hängt der Pixel-Task 42 zur Ausführung von dem Vertex-Task 38 ab, und daher wird die Abhängigkeit von dem Pfeil 46 angezeigt. Daher kann es in einigen Fällen mehrere Beziehungen zwischen Tasks geben. Zusätzlich kann es mehrere Objekttypen geben.
Zurückkehrend zu 2, nach Zuteilen des Identifikators zu der Primitive in Block 28, wird sodann in die Beziehungen für diese Primitive eingetreten, wie in Block 30 angezeigt. Während eine manuelle Technik hierin beschrieben ist, werden automatische Techniken ebenfalls in Erwägung gezogen, wobei Code-Analyse in automatischem Eintritt von Beziehungen ohne Eingriff des Benutzers resultiert.
Bei Raute 32 bestimmt sodann eine Überprüfung, ob noch weitere Primitiven codiert werden müssen. Wenn ja, wiederholt sich der Fluss. Ansonsten bestimmt eine Überprüfung bei Raute 34, ob noch weitere Threads codiert werden müssen. Wenn ja, wiederholt sich der Fluss. Ansonsten endet der Fluss.
4 zeigt ein Beispiel einer Visualisierung für eine Parent/Child-Beziehung. Bei einer Ausführungsform kann die Visualisierung eine grafische Benutzeroberfläche mit mausauswählbaren Task- oder Primitive-Abbildungen sein. In diesem Beispiel werden nur vier Threads gezeigt. Für jeden Thread werden die Tasks durch Rechtecke angezeigt.
In diesem Fall hat der Benutzer einen Parent-Task B in dem zweiten Thread ausgewählt. Als Antwort darauf wird die Visualisierung der Parent/Child-Beziehung automatisch generiert. Nämlich erstrecken sich Pfeile von Task B zu einer Reihe von Tasks C in dem dritten Thread, die Children von dem Task B sind. Des Weiteren erstrecken sich Pfeile von dem Task C in dem dritten Thread darauf zu Task C in dem vierten Thread, die Grandchildren von dem Parent-Task B sind.
5 ist eine Visualisierung einer Abhängigkeitsbeziehung. Sie stimmt mit 4 überein, mit der Ausnahme, dass nun der benutzerausgewählte Task B Abhängigkeiten gegenüber Tasks A, C, D und E aufweist. Nämlich der Task B ist abhängig von Eingaben von dem Task A, wie angezeigt von dem Pfeil mit der Markierung „eingehende Abhängigkeiten”. Die Tasks C, D und E sind abhängig von Task B für die Ausgaben, mit der Markierung „ausgehende Abhängigkeiten”. Daher zeigt die Visualisierung die funktionale Beziehung zwischen Tasks in unterschiedlichen Threads.
Die hierin beschriebenen Grafikverarbeitungs-Techniken können in verschiedenen Hardware-Architekturen implementiert werden. Beispielsweise kann Grafikfunktionalität innerhalb eines Chipsatzes integriert sein. Alternativ kann ein getrennter Grafikprozessor verwendet werden. Als noch eine weitere Ausführungsform können die Grafikfunktionen durch einen Universalprozessor, einschließlich eines Mehrkernprozessors, implementiert werden.
Verweise in dieser Beschreibung auf „eine Ausführungsform” bedeuten, dass ein bestimmtes Merkmal, eine Struktur oder Charakteristik, die in Verbindung mit der Ausführungsform beschrieben wird, mindestens in einer innerhalb der vorliegenden Erfindung eingeschlossenen Implementierung enthalten ist. Somit beziehen sich Verwendungen des Ausdrucks „bei einer Ausführungsform” nicht notwendigerweise auf die gleiche Ausführungsform. Außerdem können die bestimmten Merkmale, Strukturen oder Charakteristika in anderen geeigneten Formen eingeführt werden, die sich von der bestimmten veranschaulichten Ausführungsform unterscheiden, und alle solchen Formen können innerhalb der Ansprüche der vorliegenden Anmeldung eingeschlossen sein.
Obwohl die vorliegende Erfindung im Hinblick auf eine begrenzte Anzahl von Ausführungsformen beschrieben wurde, sind sich Fachleute bewusst, dass viele weitere Modifikationen und Varianten davon möglich sind. Die beigefügten Ansprüche sollen alle solchen Modifikationen und Varianten abdecken, die dem Sinn und Schutzbereich der vorliegenden Erfindung entsprechen.

Claims

Verfahren, umfassend: Empfangen einer Identifikation einer Vielzahl von Code-Primitiven in einem Mehrkernprozessor; und Anzeigen einer funktionalen Beziehung zwischen Primitiven.
Verfahren nach Anspruch 1, einschließlich Bereitstellen einer Visualisierung einer funktionalen Beziehung zwischen zumindest zwei Tasks.
Verfahren nach Anspruch 1, einschließlich Anzeigen einer funktionalen Beziehung zwischen einem Task und einem Parameter.
Verfahren nach Anspruch 3, wobei das Anzeigen einer funktionalen Beziehung zwischen einem Task und einem Parameter das Anzeigen einer funktionalen Beziehung zwischen einem Task und einem Puffer beinhaltet.
Verfahren nach Anspruch 1, einschließlich Bereitstellen einer Visualisierung einer funktionalen Beziehung, einschließlich zumindest entweder Parent zu Child, Geschwister, Abhängigkeit oder Erzeuger und Verbraucher.
Verfahren nach Anspruch 1, einschließlich das automatische Implizieren einer Beziehung zwischen Primitiven.
Verfahren nach Anspruch 6, einschließlich Implizieren einer transitiven Beziehung.
Verfahren nach Anspruch 1, einschließlich das automatische Implizieren einer zu mehr Beziehungen und den gegenteiligen Beziehungen.
Verfahren nach Anspruch 1, einschließlich das Ermöglichen eines Benutzers, einen Task auszuwählen, und als Antwort auf die Taskauswahl, das Anzeigen seiner funktionalen Beziehung zu anderen Primitiven.
Verfahren nach Anspruch 1, einschließlich Bereitstellen eines Identifikators für jeden Task auf einem bestimmten Thread.
Computerlesbares Medium, das Befehle, die von einem Computer ausgeführt werden, speichert, um: eine Vielzahl von Code-Primitiven in einem Mehrkernprozessor zu identifizieren; eine funktionale Beziehung zwischen Primitiven zu identifizieren.
Medium nach Anspruch 11, das weiter Befehle speichert, um eine funktionale Beziehung zwischen zumindest zwei Tasks zu visualisieren.
Medium nach Anspruch 11, das weiter Befehle speichert, um eine funktionale Beziehung zwischen einem Task und einem Parameter anzuzeigen.
Medium nach Anspruch 13, das weiter Befehle speichert, um eine funktionale Beziehung zwischen einem Task und einem Puffer anzuzeigen.
Verfahren nach Anspruch 11, das weiter Befehle speichert, um eine Visualisierung einer funktionalen Beziehung, einschließlich zumindest entweder Parent zu Child, Geschwister, Abhängigkeit oder Erzeuger und Verbraucher, bereitzustellen.
Medium nach Anspruch 11, das weiter Befehle speichert, um automatisch eine Beziehung zwischen Primitiven zu implizieren.
Medium nach Anspruch 16, das weiter Befehle speichert, um eine transitive Beziehung zu implizieren.
Medium nach Anspruch 11, das weiter Befehle speichert, um automatisch eine zu mehr Beziehungen und die gegenteiligen Beziehungen zu implizieren.
Verfahren nach Anspruch 11, das weiter Befehle speichert, um es einem Benutzer zu ermöglichen, einen Task auszuwählen, und als Antwort auf die Taskauswahl, seine funktionale Beziehung mit anderen Primitiven zu zeigen.
Medium nach Anspruch 11, das weiter Befehle speichert, um einen Identifikator für jeden Task auf einem bestimmten Thread bereitzustellen.
Vorrichtung, umfassend: einen Mehrkernprozessor; und einen Speicher, der mit dem Prozessor gekoppelt ist, wobei der Speicher Befehle speichert, um eine funktionale Beziehung zwischen Code-Tasks anzuzeigen.
Vorrichtung nach Anspruch 21, wobei der Speicher Befehle speichert, um Beziehungen zwischen Primitiven, einschließlich Tasks und Parameter, zu identifizieren.
Vorrichtung nach Anspruch 21, wobei die Vorrichtung eine Visualisierung der funktionalen Beziehung zwischen zumindest zwei Primitiven bereitstellen soll.
Vorrichtung nach Anspruch 21, wobei die Vorrichtung ein Grafikprozessor ist.
Vorrichtung nach Anspruch 24, wobei die Vorrichtung ein SIMD-(single instruction multiple data)-Mehrkernprozessor ist.
Vorrichtung nach Anspruch 21, wobei die Vorrichtung eine Visualisierung einer funktionalen Beziehung, einschließlich zumindest entweder Parent zu Child, Geschwister, Abhängigkeit oder Erzeuger und Verbraucher, bereitstellen soll.