Évaluation Warp

Objectif

Collecter des preuves reproductibles sur le comportement d'une couture étroite dans une base de code existante dans NVIDIA Warp. Rapporter des faits ; l'utilisateur décide.

Nommer Warp comme l'option en cours d'évaluation dans la première ligne, affirmer qu'aucune recommandation d'adoption ne suivra, et ne pas traiter la demande de performance déclenchante comme une autorisation d'expérimenter.

Les évaluations mesurées produisent warp-evaluation-report/ : le rapport, un diff indépendamment applicable par solution, les drivers et les résultats bruts. Ne jamais modifier le code en production. Les sorties avant le travail mesuré ne créent aucun répertoire.

Règles strictes

Elles remplacent tout raisonnement local.

1. Les objectifs par défaut sont la latence, le débit et la mémoire crête ou conservée. Compter la maintenabilité, l'ergonomie, le packaging, l'extensibilité, la différenciation automatique ou les nouvelles fonctionnalités seulement quand l'utilisateur les nomme ; sinon les rapporter comme des contraintes ou des coûts, non comme des bénéfices.
2. La correction est un filtre. Si l'incumbent est bogué ou son contrat peu clair, abandonner cette comparaison jusqu'à l'existence d'un oracle indépendant ou d'un contrat clarifié. Signaler le défaut sans prescrire une réponse.
3. Ne jamais prédire des économies à partir de la forme source ou d'une autre charge. La mémoire matérialisée provient de preuves du profiler ou de l'allocateur, non d'une source qu'un compilateur peut fusionner.
4. « Cela peut être écrit en Warp » est une hypothèse, jamais une opportunité prouvée.
5. Les filtres sont exacts, jamais adjacents ou analogues. Déclencher un filtre seulement quand chaque condition dans sa définition est établie. Le filtre D exige une implémentation maintenue confirmée s'exécuter avec CUDA sur un GPU NVIDIA ; une rapide bibliothèque native CPU est une base de référence, non le filtre D.
6. Étiqueter chaque affirmation comme fait observé, mesure, hypothèse ou inconnue.
7. Chronomètrer l'étape visible par l'utilisateur, non le kernel. Inclure l'import/init/JIT à froid de Warp dans le régime de processus réel, les transferts, les lancements, les boucles de lancement Python, la construction/remontage des structures, l'allocation, la conversion, la validation, la compaction et la synchronisation. Rapporter chaque coût et la différence de bout en bout.
8. Aucun travail mesuré sans autorisation explicite. Après l'étape 1, arrêter et demander avant le profilage, les changements d'environnement, le prototypage, les benchmarks ou l'utilisation du GPU.
9. Le travail mesuré autorisé inclut Warp. Si le profilage n'expose aucun filtre, continuer vers la plus forte base de référence du projet, le prototype Warp minimal et la comparaison de bout en bout. Si Warp est hors de portée, arrêter avant le profilage.
10. Ne jamais déduire l'intention de l'environnement. Le déploiement NVIDIA et la propriété d'une dépendance compilée optionnelle sont des décisions produit. Abandonner seulement sur une contrainte énoncée ; sinon demander une fois et arrêter (AWAITING INTENT).
11. Les mesures Warp sont CUDA uniquement et synchronisées. Résoudre un périphérique NVIDIA CUDA explicite ; rejeter la résolution CPU et le timing dispatché uniquement.
12. Ne jamais recommander ou classer les options d'adoption. Rapporter les faits, les mesures, les hypothèses et les inconnues par couture et régime.
13. Arrêter au rapport. Aucun déploiement ou édition de production.

Exigences

Le dépistage statique nécessite le repository cible et ses contraintes de produit énoncées. Le travail mesuré exige en outre une autorisation explicite, un GPU NVIDIA CUDA, les dépendances du projet cible et une charge de travail représentative.

Limitations

• Les kernels CPU Warp sont sériels et hors du champ d'évaluation de cette compétence. « L'exécuter sur le CPU à la place » n'est pas un repli de performance.
• Les requêtes de mailles et géométries calculent en float32/int32 même derrière une API publique float64. L'erreur absolue augmente avec la magnitude des coordonnées.
• Warp ne suit pas semver. Les versions de fonctionnalités peuvent casser les APIs, seule la plus nouvelle ligne de fonctionnalités est maintenue, les dépréciations s'exécutent environ quatre versions mensuelles.
• Les docs latest suivent le développement, non la version livrée. Épingler à la version Warp du projet cible lui-même ; s'il n'en a pas, utiliser la version stable actuelle et le dire.
• Les builtins du kernel uniquement ne sont pas résolubles à partir de Python — hasattr(wp, "mesh_query_point") est False sur une version qui l'a. Sonder le fichier stub ou les docs de cette version avant de conclure qu'un builtin est absent.
• enable_backward=False (kernel, module ou global) supprime la génération adjointe. Si rien ne se différencie à travers la couture, le configurer avant de mesurer le coût de compilation.

Format de sortie

Utiliser cette forme exacte pour une sortie précoce : ABORT — Gate <lettre>: <fait cité> ; <pourquoi l'évaluation Warp ciblée ne peut pas procéder>. Ne pas nommer une alternative préférée. Règles de rapportage : references/evidence-and-reporting.md. Un répertoire livré suit l'ordre fixe du modèle : schéma et provenance, autorisation et état d'évaluation, recensement des étapes, une section de preuve B<n> par couture/régime, mises en garde, puis environnement/reproduction. solutions/, benchmarks/ et results/ contiennent chaque artefact lié.

Exemples

Sortie de filtre : ABORT — Gate A: deployment.md exige une implémentation avec parité AMD, Apple et NVIDIA ; un chemin spécifique à Warp ne peut pas satisfaire cette portée.

Candidat survivant : Nommer la couture et le motif, étiqueter les faits déduits comme des hypothèses, affirmer qu'aucun filtre n'a déclenché, prévisualiser la portée du profil/base de référence/prototype Warp/benchmark et son coût, puis poser les questions d'intention et d'autorisation séparées de references/authorization-checkpoint.md.

Entrées

Obligatoire : le repository cible et un problème de performance, mémoire ou échelle avec une couture candidate. Optionnel : contraintes explicites de déploiement/packaging, profils ou logs existants, datasets représentatifs et critères d'acceptation. Les contraintes de prompt prennent la priorité sur la politique/configuration du repository, puis les logs existants. Les corrections utilisateur remplacent l'inférence. Ne jamais substituer une hypothèse à un fait énoncé ou une mesure.

Scripts disponibles

Utiliser run_script("scripts/validate_report_schema.py", args=["warp-evaluation-report"]) quand supporté ; sinon invoquer le script avec Python et le répertoire de rapport.

Dépannage

• Aucune charge de travail représentative : marquer la portée INCOMPLETE et nommer l'artefact manquant ; ne pas inventer de données ni déclencher le filtre F.
• Warp se résout en CPU ou aucun périphérique CUDA : rejeter l'exécution et arrêter avant des affirmations de correction ou timing.
• La validation du rapport échoue : corriger le rapport ou l'artefact référencé ; ne jamais renoncer à l'erreur de schéma.

Instructions

Chaque étape avant la dernière peut terminer l'évaluation. Arrêter dès qu'un filtre déclenche ; ne pas rassembler de preuves qui ne peuvent pas changer les faits ciblés.

1. Lire le code, dériver le contrat, vérifier les filtres

• Identifier un candidat et sa métrique avec references/target-patterns.md.
• Dériver les périphériques/résidence, dtypes/formes, tailles, fréquence, durée de vie du processus, gradients et packaging du repository. Inférer avant de demander.
• Énoncer le contrat déduit en une ligne et inviter à correction. Le matériel inconnu, les comptes, tailles et tolérances sont des hypothèses, jamais des mesures. Chaque inférence reste ouverte à correction et ne peut pas satisfaire un filtre qui exige un fait énoncé ou une mesure.
• Vérifier les filtres A–E avant le profilage. Vérifier le filtre F maintenant seulement si une preuve représentative existe déjà ; sinon le porter à l'étape 2. Chaque filtre utilise seulement les limites exactes dans references/rejection-gates.md.

• Le filtre F ne peut déclencher à l'étape 1 que depuis une preuve représentative qui existe déjà — un profil fourni, une borne structurelle, ou l'arithmétique sur des chiffres que l'utilisateur a cités. Si cette preuve n'existe pas, le filtre F reste ouvert jusqu'au profilage de l'étape 2 ; les valeurs déduites ne le déclenchent jamais.
• Les filtres A et E ont besoin d'une contrainte énoncée. Une implémentation CPU, un autre accélérateur, pas de dépendance Warp, ou une petite liste de dépendances ne prouvent rien.
• Quand A/E ne sont pas résolus et un motif survit, demander si un chemin NVIDIA optionnel est acceptable : extra nommé, import souple, fallback existant, installation par défaut inchangée. Chaque réponse affirmative doit dire explicitement que Warp sera prototypé et benchmarké ; les conditions contraignent seulement cette portée Warp. Une réponse négative ou indécise signifie ABORT.
• Ne pas demander quand un autre filtre a déclenché, le repository répond, ou aucun motif ne correspond. Aucun motif signifie aucun profilage.
• Si un candidat survit, combiner toute question d'intention avec le point de contrôle d'autorisation — découvertes précoces, portée exacte, étapes, coût de ressource — puis arrêter. L'étape 2 exige à la fois une question d'intention établie et une autorisation explicite.

2. Profiler l'application réelle

Exige une autorisation explicite et une question d'intention établie.

• Profiler avec le profiler propre du projet et les points d'entrée représentatifs.
• Mesurer le temps d'étape synchronisé de bout en bout et la mémoire crête avant de choisir un backend. Rapporter quels points d'entrée ont été profilés et lesquels un filtre a screening.
• Prioriser la mesure supplémentaire par coût observé, non par apparence source.
• Nommer chaque mesure par la méthode publique et la variante réellement invoquées. Un fallback est un régime d'exécution de cette couture publique, non une opération différente, et une méthode sibling moins chère ne peut pas dépister la méthode nommée.
• Confirmer que la branche chronométrée s'est exécutée sur le périphérique voulu. Un coût inchangé et une allocation de périphérique près de zéro entre les entrées hôte et périphérique exposent un fallback hôte.
• Mesurer le plafond d'étape libre et le plancher stubé à travers la limite publique. Ne pas soustraire les timings par opération.
• Si le plafond mesuré prouve que le candidat ne peut pas déplacer sa propre métrique, ABORT la portée affectée sous le filtre F, préserver la preuve déjà collectée, et arrêter. L'autorisation existante couvrait déjà cette vérification de matérialité ; ne pas demander d'autorisation à nouveau.
• Si la couverture représentative n'est pas disponible — aucun dataset représentatif, point d'entrée exécutable ou distribution de production — enregistrer l'artefact unique manquant, marquer la portée affectée INCOMPLETE, et arrêter. C'est une preuve manquante, pas le filtre F ni ABORT. Une charge de travail inventée ne peut pas prouver la matérialité.

Protocole : references/benchmark-protocol.md.

3. Former des hypothèses falsifiables

Enregistrer par candidat : source, preuve du goulot, objectif, couture étroite, mécanisme que Warp pourrait changer, incumbent le plus fort, risques, seuil d'acceptation, expérience falsifiante la moins chère. Screener contre references/target-patterns.md ; si aucun ne survit, écrire le rapport et arrêter.

4. Écrire le contrat avant le prototype

Définir valeurs, dtypes, formes, périphériques, erreurs, mutation, ordonnancement, ties, capacité/débordement, topologie/dégénérescence, tolérances, gradients requis, streams, propriété, aliasing, invalidation, concurrence, capture, démontage et fallback.

• Fixer les tolérances avant de voir la sortie Warp. Ne jamais affaiblir un contrat après une non-correspondance.
• ABORT avant le prototypage si la couture proposée ne peut pas satisfaire un contrat exigé.
• Pré-enregistrer, avant le timing : provenance de la charge, la variable d'état et la plage de production contrôlant le coût, boutons de tuning, écart incumbent run-à-run, et l'oracle appliqué à chaque implémentation.

Aléas et vérifications adversariales : references/semantic-contract.md.

5. Améliorer d'abord la base de référence

Algorithme avant backend : (1) un algorithme meilleur ou sensible à la sortie ; (2) chunking, tiling, sortie creuse, layout, rématérialisation ; (3) compilateur du framework incumbent et primitives natives ; (4) ce que le projet dépend déjà — son propre backend accélérateur, un idiome parallèle qu'il expédie mais laisse désactivé, ou une capacité qu'une dépendance existante expose et que personne n'a câblée ; (5) seulement ensuite affiner Warp.

• Comparer seulement les options ciblées : l'incumbent amélioré, les capacités atteignables à travers les dépendances actuelles, et Warp. Ne pas ajouter des bibliothèques non liées.
• Chercher les dépendances déclarées pour les backends dormants, flags et bindings avant d'appeler une route absente.
• Garder l'incumbent amélioré comme l'oracle. Un résultat contre une base de référence non tuée, incorrecte ou asymptotiquement inférieure n'établit pas une comparaison de backend.

Fermer chaque route du projet avant le prototypage Warp :

Une capacité présente mais non liée est atteignable, non absente. Si l'exposer coûte pas plus que la couture Warp prévue, la mesurer en premier. Détails de l'échelle : references/baselines.md. Les routes renoncées ne bloquent pas l'étape 6 ; chaque route non explicitement renoncée doit être mesurée ou prouvée absente avant le prototype Warp commence.

6. Prototyper l'unité minimale

• Travailler dans une copie séparée, production inchangée, couture d'intégration désactivée par défaut. Prototyper juste assez pour tester l'hypothèse.
• Sélectionner un périphérique CUDA explicite pour chaque prototype Warp et vérifier que Warp le résout comme CUDA avant le travail de correction ou performance. Ne jamais exercer ou rapporter le backend CPU de Warp.
• Dimensionner l'unité par données partagées et durée de vie de structure, non par limites de fonction : les coûts de construction/remontage/requête qui s'amortissent ensemble sont une unité.
• Nommer les variantes avant le timing. Préserver chaque solution comme un patch indépendant contre la base de référence épinglée, et prouver qu'elle s'applique proprement et reproduit le résultat mesuré.
• Exposer les cas non supportés et débordement avant le timing.
• Exécuter les vérifications de contrat adversariales, auditer la correction à l'échelle de production, et délibérément casser une branche pour prouver que les tests échouent. Toute vérification exigée échouée retourne ABORT pour la portée affectée.
• Avant de traiter un résultat décevant lié au calcul ou à la réutilisation dense comme représentatif, considérer les formulations plus fortes dans references/target-patterns.md. Un kernel naïf ne borne pas le potentiel de Warp.

7. Benchmarker la limite entière

• Copier scripts/driver-template.py une fois par goulot et mesurer par scripts/measure.py. Ne pas rouler manuellement le timing ou la mémoire.
• Les lancements Warp sont asynchrones. Le helper de mesure doit synchroniser le périphérique sélectionné immédiatement avant de démarrer et après avoir mis en queue chaque région chronométrée, avant d'arrêter son chrono mural.
• Inclure chaque coût de règle-7, l'appel public, l'étape immédiatement en aval, des tailles réalistes, et les régimes de processus froid/chaud.
• Transcrire chaque cellule de rapport depuis le JSON émis ; les enregistrements absents lisent not measured.
• Rapporter null_test, et les coûts ponctuels à la fois séparément et amortis. Sérialiser les mesures GPU sous un verrou de périphérique exclusif. Sous 1,5× il n'y a pas de différence mesurée.
• ABORT pour une couture et régime dont le requirement de performance ou mémoire de bout en bout pré-déclaré échoue, après préservation des mesures.

Protocole complet : references/benchmark-protocol.md.

8. Résumer la preuve

• Par couture et régime d'exécution, rapporter les résultats sémantiques, les mesures du strongest-baseline, provenance de charge, temps, mémoire, cycle de vie, faits de portabilité et propriété.
• Utiliser pass, fail, not measured, not available, no representative data, unknown ou n/a seulement où un critère énoncé rend ce statut objectif. La preuve manquante reste manquante.
• Marquer le rapport complete seulement quand chaque couture et régime évalués inclut une mesure Warp de bout en bout. Utiliser aborted — <gate and scope> quand un filtre a déclenché, ou incomplete — <missing evidence and scope> quand une preuve représentative n'était pas disponible. Préserver tout collecté. Ne jamais livrer un rapport incumbent uniquement comme un warp-eval complété.
• Donner à chaque étape valant ≥10 % du total mesuré une ligne de recensement avec un statut et une raison d'une ligne, incluant les étapes screening.
• Vérifier chaque filtre contre la métrique que ce motif candidat épuise, non l'objectif titre de l'étude.

9. Remettre

• Utiliser assets/warp-evaluation-report-template.md inchangé dans le schéma. Enregistrer autorisation et portée.
• Une table par goulot : base de référence, solutions de dépendance actuelle, puis Warp ; temps absolu et mémoire crête, ratios, statut de contrat, lacunes de preuve.
• Inclure la prose seulement où elle explique les mesures ou leurs limites. Les artefacts de travail appartiennent à results/.

uv run python scripts/validate_report_schema.py <report-directory>

• Exécuter le validateur une fois que la première mesure établit un recensement/table, et à nouveau avant livraison. Corriger chaque erreur.
• Vérifier les constructions et imports depuis artefacts, non le statut de sortie. Expédier les drivers exacts exécutés. Puis arrêter.