In einer JIT-kompilierten GPU-Kernelbibliothek Kernel hinzufügen und testen

## Eine bearbeitbare Installation einrichten, die geänderte Kernel automatisch neu kompiliert Verwenden Sie eine bearbeitbare Installation, die die vorhandenen Versionen des Rahmenwerks und Beschleunigers in der Umgebung beibehält. Deaktivieren Sie die isolierte Abhängigkeitsauflösung, wenn sie inkompatible Laufzeitpakete beziehen könnte. Initialisieren Sie vor dem Kompilieren oder Testen alle erforderlichen Quelluntermodule. Behandeln Sie Just-in-Time-Kompilierung als den normalen Entwicklungszyklus. Bearbeiten Sie Kernelquellen, führen Sie einen gezielten Test aus und lassen Sie die Quelltexthashes die Neukompilierung auslösen. Installieren Sie das Paket nicht nach jeder Kerneländerung neu, es sei denn, der Paketierungscode selbst wurde geändert. Leeren Sie den JIT-Zwischenspeicher nur, wenn veraltete Artefakte Teil der Diagnose sind. Verwenden Sie vorkompilierte Kernelpakete nur, wenn ein schnellerer Ersteinsatz oder die Verteilung sie erfordert. Halten Sie vorkompilierte Artefakte für die normale Entwicklung optional. Legen Sie Zielarchitekturen ausdrücklich fest, wenn Sie für andere Geräte als die erkannte lokale GPU kompilieren. Begrenzen Sie Compilerfäden und parallele Kompilierungsaufträge entsprechend dem verfügbaren Speicher. Schätzen Sie den gesamten Kompilierungsspeicher als Produkt aus Aufträgen, Compilerfäden und Bedarf je Faden. Verhindern Sie, dass Testparametergrößen den Gerätespeicher vermeidbar erschöpfen. Installieren Sie Unterstützung für Leistungsanalysen nur, wenn genaue Hardwarezeitmessungen erforderlich sind. Führen Sie vor der Überprüfung Formatierung und Repository-Hooks aus. ## Erzeugte Dateien nur in beschreibbare Arbeitsbereiche schreiben, nie in installierte Ordner Stellen Sie jede Kompilierungswerkzeugkette über eine gemeinsame Spezifikationsschnittstelle dar. Geben Sie jeder Spezifikation einen eindeutigen Namen, eine Quellliste, Compileroptionen, Linkeroptionen und unterstützte Architekturen. Verwenden Sie eine gemeinsame Vorlage zum Kompilieren und Laden, um Zwischenspeichersuche, Sperrung, Kompilierung und Laden zu koordinieren. Halten Sie den Lebenszyklus ausdrücklich fest: Versuchen Sie zuerst, aus dem Zwischenspeicher zu laden, kompilieren Sie bei Bedarf und laden Sie anschließend das kompilierte Modul. Verweigern Sie die JIT-Kompilierung, wenn ein Deaktivierungsschalter gesetzt ist und weder ein gültiges zwischengespeichertes noch ein vorkompiliertes Modul vorhanden ist. Schreiben Sie erzeugte Dateien niemals in Verzeichnisse installierter Pakete, da diese schreibgeschützt sein können. Halten Sie Quellvorlagen und Daten vorkompilierter Pakete schreibgeschützt. Schreiben Sie gerenderten Quelltext und kopierte Kompilierungseinheiten ausschließlich in einen Arbeitsbereich für erzeugten Quelltext. Schreiben Sie Objektdateien, gemeinsam genutzte Bibliotheken, Metadaten und Kompilierungsdateien ausschließlich in den JIT-Artefaktarbeitsbereich. Erzeugen Sie das Kompilierungsmanifest aus der genauen Quellliste und den Kompilierungsoptionen. Sorgen Sie dafür, dass Arbeitsbereichspfade für gemeinsam genutzte, temporäre oder eingeschränkte Umgebungen überschrieben werden können. Kombinieren Sie mithilfe des Architekturkontexts erkannte Geräte mit ausdrücklich angeforderten Zielen. Beschränken Sie ein Modul vor Beginn der Kompilierung auf unterstützte Architekturfamilien. Brechen Sie mit einer eindeutigen Fehlermeldung ab, wenn keine der angeforderten Architekturen unterstützt wird. Kompilieren Sie nicht stillschweigend für eine andere Gerätefamilie. ## Einen neuen Kernel vom Gerätecode bis zur öffentlichen API hinzufügen Implementieren Sie rahmenwerkunabhängigen Gerätecode für rohe Zeiger und portable Kerneltypen. Halten Sie Rahmenwerk-Header aus der wiederverwendbaren Kernel-Einbindungsschicht heraus. Fügen Sie in der Anbindungsschicht eine Startfunktion hinzu, die Tensoren prüft und Aufrufparameter vorbereitet. Exportieren Sie die Startfunktion über die typisierte sprachübergreifende FFI des Projekts. Berechnen Sie aus Spezialisierungsparametern eine deterministische Vorgangs-URI. Erstellen Sie für jeden Vorgang ein eigenes Generierungsverzeichnis im beschreibbaren Quellarbeitsbereich. Verwenden Sie eine Vorlage nur, wenn eine konkrete Typ- oder Parameterspezialisierung erforderlich ist. Schreiben Sie die gerenderte Konfiguration nur, wenn sich ihr Inhalt unterscheidet. Kopieren Sie erforderliche Kompilierungseinheiten in das Generierungsverzeichnis. Geben Sie eine Kompilierungsspezifikation zurück, die URI, Quellen, Optionen und Architekturgrenzen enthält. Stellen Sie eine zwischengespeicherte übergeordnete API bereit, die geladene Module wiederverwendet. Registrieren Sie den Vorgang für die Vorabgenerierung von Paketen, wenn die Verteilung dies erfordert. Exportieren Sie die öffentliche API am Paketeinstiegspunkt. Verknüpfen Sie eine Ablaufverfolgungsvorlage, die Achsen, Eingaben, Ausgaben und eine optionale Referenz definiert. Verknüpfen Sie bei Planungs- und Ausführungs-APIs die Ablaufverfolgung mit der Methode, welche die Ausführung übernimmt. Fügen Sie ein realistisches Ablaufverfolgungsbeispiel hinzu, erzeugen Sie die Artefakte der Leistungsmessungsdefinitionen neu und committen Sie die erwarteten Ausgaben. Führen Sie nach der Neuerzeugung Konsistenztests der Ablaufverfolgung und Ende-zu-Ende-Tests aus. ## Nicht unterstützte GPUs in Tests überspringen und Geschwindigkeitsangaben mit Korrektheitsprüfungen belegen Führen Sie für eine umfassende Prüfung die vollständige Testsammlung und während der Entwicklung gezielte Tests aus. Überspringen Sie nicht unterstützte Hardware bewusst über zentrale Hilfsfunktionen zur Fähigkeitserkennung. Prüfen Sie sowohl die Rechenfähigkeit des Geräts als auch die Unterstützung durch das Backend, wenn eine API diese Abfragen bereitstellt. Halten Sie die Architekturanforderungen jeder Funktion ausdrücklich fest. Machen Sie aus einer nicht unterstützten Architektur keinen Testfehler. Überspringen Sie eine unterstützte Architektur nicht, nur weil das lokale Gerät abweicht. Wählen Sie Testformen, die den Vertrag prüfen, ohne vermeidbare Überspringungen wegen Speichermangels zu verursachen. Decken Sie die von einer Änderung betroffenen Pfade für Aufmerksamkeit, Matrixmultiplikation, Expertenmischung, Kommunikation und Hilfsfunktionen ab. Verwenden Sie für kollektive oder verteilte Tests Startwerkzeuge für mehrere Geräte. Führen Sie Leistungsmessungen mit einem einheitlichen Testgerüst durch, das vergleichbare Backends und gebündelte Konfigurationen unterstützt. Bevorzugen Sie die Zeitmessung eines Profilers auf Hardwareebene und greifen Sie auf Beschleunigerereignisse zurück, wenn sie nicht verfügbar ist. Halten Sie fest, welcher Zeitmessungsmechanismus jedes Ergebnis der Leistungsmessung erzeugt hat. Geben Sie Median, Streuung, Wiederholungszahl, Arbeitslastform, Datentyp, Architektur und Backend an. Aktivieren Sie beim Vergleich von Kerneln die Referenzprüfung. Stellen Sie keine Geschwindigkeitsbehauptungen ohne Korrektheitsprüfungen und reproduzierbare Parameter auf. Verlangen Sie vor der Freigabe eines leistungsempfindlichen Kernels Nachweise aus Leistungsmessungen und Tests. ## Zwischengespeicherte Kernel neu bauen, wenn sich Quellen oder Ziel-GPU ändern Verwenden Sie für geladene Module einen prozessinternen Zwischenspeicher und für kompilierte Artefakte einen Festplattenzwischenspeicher. Machen Sie zwischengespeicherte Module ungültig, wenn sich Quellen, Optionen, Architektur, Parameter oder Bibliotheksversion ändern. Leiten Sie die Zwischenspeicheridentität aus Vorgangstyp, Parametern, Quelltexthashes, Optionen und Zielarchitektur ab. Halten Sie Zwischenspeicherschlüssel über Spezialisierungs- und Werkzeugkettenvarianten hinweg eindeutig. Speichern Sie Kompatibilitätsmetadaten neben den Artefakten und prüfen Sie sie vor dem Laden. Schützen Sie die Kompilierung durch Sperren, damit parallele Prozesse gemeinsame Artefakte nicht beschädigen. Speichern Sie bei DSL-Ausgaben für eine einzelne Architektur ein Modulverzeichnis mit Metadaten und ein Objekt je Spezialisierung. Leiten Sie die Architektur aus dem DSL-Kompilierungsziel oder dem aktiven Gerät ab. Machen Sie ein DSL-Modul ungültig, wenn sich die Version seines Compilerpakets oder der Hash der Kernelquelle ändert. Erlauben Sie zur Diagnose, den Zwischenspeicher zu deaktivieren, während die Wiederverwendung standardmäßig aktiviert bleibt. Verwenden Sie Dispatch-Makros oder erzeugten Code, um kombinatorische Räume aus Datentypen und Blockgrößen zu verwalten. Halten Sie Dispatch-Entscheidungen ausdrücklich fest und testen Sie nicht unterstützte Kombinationen. Fügen Sie keine Vorlagenbildung hinzu, wenn direkter Quelltext ausreicht. Lassen Sie veraltete vorkompilierte Pakete die Versionskompatibilitätsprüfungen nicht umgehen. Umgehen Sie Versionsprüfungen nur für ein bewusstes, diagnostiziertes Experiment mit gemischten Versionen. ## API-Eingaben vor dem Kernelstart protokollieren, damit Abstürze nachstellbar bleiben Protokollieren Sie API-Eingaben vor der Kernelausführung, damit absturzauslösende Parameter einen Gerätefehler überdauern. Halten Sie die Protokollierung bei Deaktivierung frei von Laufzeitaufwand. Bieten Sie abgestufte Ebenen für Aufrufnamen, Ein- und Ausgaben sowie aufwendige Statistiken an. Beschränken Sie Statistiken und Suchen nach ungültigen Werten auf ausdrücklich angeforderte Detaildiagnosen. Überspringen Sie während der Graphenerfassung eine inkompatible Statistikerhebung. Begrenzen Sie Diagnoseabbilder anhand der Ereigniszahl und Gesamtgröße. Unterstützen Sie Ein- und Ausschlussfilter, damit aufwendige Erfassungen nur einschlägige APIs betreffen. Wählen Sie ein portables Tensorformat, wenn Abbilder zwischen Umgebungen übertragen werden müssen. Verwenden Sie ein eigenes beschreibbares Abbildverzeichnis. Aktivieren Sie ausführliche Kompilierungsausgaben und Debugsymbole nur während der Fehlerdiagnose. Untersuchen Sie erzeugten Quelltext, Kompilierungsmanifeste, kompilierte Module und Zwischenspeichermetadaten gemeinsam. Erfassen Sie beim Nachstellen eines Absturzes Formen, Datentypen, Architektur, Optionen und das ausgewählte Backend. Verwenden Sie Zeileninformationen, wenn ein Profiler oder Debugger Quelltextzuordnungen benötigt. Halten Sie normale Optimierungseinstellungen von Debugkompilierungen getrennt. Behandeln Sie erzwungene Algorithmus- oder Backendauswahlen als Diagnosesteuerungen und nicht als Produktionsvorgaben. Dokumentieren Sie jede vom Standard abweichende Steuerung, die zur Reproduktion eines Ergebnisses verwendet wurde. ## Heruntergeladene Artefakte prüfen und Releases für eine feste GPU-Liste bauen Brechen Sie in Offline- oder abgeschotteten Umgebungen bei fehlenden lokalen Artefakten zwingend mit einem Fehler ab. Erlauben Sie, dass ein vertrauenswürdiger Spiegel das voreingestellte Artefakt-Repository ersetzt. Prüfen Sie standardmäßig die Prüfsummen heruntergeladener Artefakte. Deaktivieren Sie die Prüfsummenprüfung nur vorübergehend als Hilfe bei der Fehlersuche. Begrenzen Sie parallele Artefaktdownloads. Bevorzugen Sie vor einem Downloadversuch eine konfigurierte lokale Quelle. Halten Sie Kompilierungsoptionen und Überschreibungen der Startfunktion ausdrücklich und beobachtbar. Halten Sie die Protokollierungssteuerung des Artefaktladers von der Protokollierungssteuerung für API-Aufrufe getrennt. Verwenden Sie für die automatische Abstimmung eine stabile Zeitmessung, einschließlich eines globalen Hardwarezeitgebers, wenn die Ereigniszeitmessung unzuverlässig ist. Erlauben Sie, die Erkennung vertraulicher Datenverarbeitung für eine kontrollierte CI-Diagnose zu überschreiben. Speichern Sie Ergebnisse der automatischen Abstimmung nur mit einem ausdrücklich angegebenen Zwischenspeicherort und in einer kompatiblen Umgebung dauerhaft. Laden Sie eine Sperrliste für Taktiken, um Kernel zu meiden, die im aktuellen Softwarestapel bekanntermaßen hängen bleiben oder abstürzen. Belassen Sie experimentelle Weiterleitungs- und Kernelauswahlüberschreibungen auf ihren dokumentierten Vorgaben. Erstellen Sie vorab kompilierte Pakete für eine ausdrückliche Architekturliste. Erzeugen Sie Paketversionsmetadaten aus einer einzigen maßgeblichen Versionsquelle. Verwenden Sie für Kernel, Geräteunterstützung und Fehlerkorrekturen rückwärtskompatible Versionserhöhungen. Reservieren Sie inkompatible API-Änderungen für eine architektonische Versionsgrenze. ## Öffentliche API und Dokumentation mit dem Kernelcode abgleichen Verwenden Sie eine typisierte sprachübergreifende ABI, damit dieselben Kernel mehreren Host-Rahmenwerken dienen können. Belassen Sie die rahmenwerkspezifische Tensorverarbeitung in den Anbindungen statt in den Geräte-Headern. Registrieren Sie benutzerdefinierte Vorgänge im Host-Rahmenwerk nur dort, wo Kompilierung und Graphenerfassung dies erfordern. Halten Sie Python-API, JIT-Generator, Anbindungsexport, Vorabkompilierungsregister und Paketexporte synchron. Beginnen Sie mit dem einfachsten funktionierenden Kernelmuster, bevor Sie fortgeschrittene Arbeitsbereichs- oder Planungs- und Ausführungsentwürfe übernehmen. Aktualisieren Sie Funktionssignaturen, Vorlagen, Startfunktionen und Tests gemeinsam, wenn sich Parameter ändern. Übernehmen Sie etablierten Stil, Komplexität, defensive Auslegung und Effizienz aus nahegelegenen funktionierenden Beispielen. Dokumentieren Sie bewusste Abweichungen und leistungskritische Algorithmenentscheidungen zusammen mit den erwogenen Alternativen. Ziehen Sie für architekturspezifisches Verhalten maßgebliche Dokumentation zu Befehlssatz und Werkzeugkette heran. Bevorzugen Sie mitgelieferte Abhängigkeitsquellen, wenn externe Dokumentation veraltet ist. Halten Sie Ablaufverfolgungsvorlagen und erzeugte Leistungsmessungsdefinitionen mit öffentlichen APIs synchron. Aktualisieren Sie Infrastrukturbeispiele und Anleitungen, wenn sich Protokollierungs-, Anforderungs-, FFI- oder Codegenerierungsmuster ändern. Kennzeichnen Sie überholte Ansätze deutlich oder entfernen Sie sie aus der aktuellen Anleitung. Legen Sie wesentliche KI-Unterstützung gemäß den Beitragsrichtlinien offen. Genehmigen Sie nur, wenn Quellen, erzeugte Artefakte, Zwischenspeicher, Tests, Leistungsmessungen, Exporte und Dokumentation übereinstimmen.