Annonce du Steering Council concernant le projet JIT

• Le compilateur JIT expérimental de CPython est développé depuis plusieurs années sur la branche main et a récemment montré de réels gains de performance, mais une revue PEP officielle est nécessaire pour qu’il reste une fonctionnalité prise en charge
• La PEP 744 couvrait la conception initiale et les critères de passage à une fonctionnalité permanente, mais aucun consensus n’a encore été trouvé sur les mainteneurs à long terme, la revue de sécurité, la prise en charge du débogage et des outils de processus externes, les garanties d’exécution, ni les obligations des redistributeurs et des packageurs downstream
• Le Python Steering Council a officiellement demandé la rédaction d’une Standards Track PEP pour faire du JIT une fonctionnalité CPython prise en charge et non expérimentale, et demande de suspendre l’intégration dans main de nouvelles fonctionnalités, optimisations et travaux de performance jusqu’à l’acceptation de la PEP
• La nouvelle PEP devra traiter de la maintenance à long terme, de la compatibilité avec les fonctionnalités et outils CPython existants, d’indicateurs de réussite mesurables et d’un calendrier, de la relation avec des JIT tiers comme CinderX·Numba·PyTorch, ainsi que de la stabilité de l’architecture actuelle
• Si la PEP n’est pas soumise, résolue ou acceptée dans un délai de 6 mois, le code JIT devra être retiré de la branche main et son développement devra se poursuivre en dehors du dépôt Python principal

---

Contexte et demande officielle

• Le compilateur Just-In-Time expérimental de CPython est un travail mené sur la branche main depuis plusieurs années par plusieurs core developers et contributeurs, et les récentes améliorations de performances constituent des résultats concrets et encourageants
• Cette mesure n’est pas une critique du travail sur le JIT ni de ses participants ; le projet étant engagé depuis longtemps et ayant connu plusieurs refontes, il est jugé opportun de réévaluer le statut officieux du JIT au sein du projet CPython
• Le JIT a été intégré à main comme une expérimentation, et la PEP associée, la PEP 744, est une Informational PEP
• La PEP 744 traitait de la conception initiale et esquissait les critères permettant au JIT de devenir une fonctionnalité permanente, mais elle laissait ouvertes des questions comme les mainteneurs à long terme, la revue de sécurité, la prise en charge du débogage et des outils de processus externes, les garanties d’exécution, ainsi que les obligations des redistributeurs et des packageurs downstream
• Le Python Steering Council estime qu’un changement d’une telle complexité et d’une telle portée aurait nécessité une procédure plus stricte, et que ces questions non résolues constituent des engagements que la communauté doit examiner et valider via le processus PEP
• Pour faire du JIT une fonctionnalité CPython prise en charge et non expérimentale, une Standards Track PEP est nécessaire afin de traiter aussi bien des garanties que des engagements de maintenance et de l’impact sur les redistributeurs, suivie d’une procédure officielle d’acceptation ou de rejet par le Steering Council après discussion de la communauté
• Tant que cette PEP n’est pas acceptée, aucun nouveau développement JIT ne doit être intégré dans la branche main ; les nouvelles fonctionnalités, optimisations et travaux de performance sont concernés par cette suspension
• Les corrections de bugs et de sécurité peuvent continuer, et la portée de cette demande de suspension se limite à l’ajout de nouvelles fonctionnalités JIT avant l’acceptation de la PEP

Questions que la PEP doit traiter et échéance de 6 mois

• L’intention n’est pas d’exiger des propositions concurrentes, mais c’est aussi un bon moment pour discuter d’alternatives, ce qui rejoint la position existante selon laquelle les expérimentations ne devraient pas être menées sur la branche main de CPython sans PEP
• Plutôt que de proposer une seule implémentation JIT, une PEP décrivant une infrastructure JIT capable de prendre en charge plusieurs stratégies d’implémentation pourrait être plus appropriée
• Comme plusieurs approches prometteuses de JIT tracing continuent d’être proposées, l’infrastructure devrait éviter d’être trop fortement couplée à une stratégie unique et permettre d’expérimenter et d’évaluer facilement de telles approches au sein de CPython
• La PEP devra établir un plan clair sur la manière de faire vivre et de maintenir à long terme un sous-système de cette ampleur et de cette complexité, ainsi que sur son impact pour les mainteneurs et contributeurs qui ne contribuent pas directement au JIT
• La PEP devra traiter de la compatibilité avec les fonctionnalités et outils CPython existants, et couvrir de manière large et détaillée les interactions et garanties entre le JIT et des fonctionnalités comme le free-threading, les profilers et les débogueurs
• La PEP devra inclure des indicateurs de réussite clairs et mesurables ainsi qu’un calendrier, en couvrant des objectifs et des échéances tels que les performances, le périmètre de prise en charge des plateformes et la surcharge mémoire
• La PEP devra traiter de la relation avec les autres compilateurs JIT, et préciser s’il s’agit d’une conception fournissant une infrastructure générale sur laquelle d’autres efforts peuvent s’appuyer, et si elle prévoit une compatibilité ou une incompatibilité avec des JIT tiers comme CinderX, Numba ou PyTorch
• La PEP devra indiquer si l’architecture JIT actuelle est considérée comme stable ou si elle est encore susceptible d’évoluer fortement
• Cette liste n’est pas exhaustive, et d’autres questions pourront s’y ajouter au fil de la discussion de la communauté
• Une période de 6 mois est fixée pour la soumission et la résolution de la PEP ; si la PEP n’est pas acceptée dans ce délai, le code JIT sera retiré de la branche main et son développement devra se poursuivre en dehors du dépôt Python principal
• Cette exigence ne signifie pas la fin du projet, mais constitue une procédure destinée à apporter la clarté et l’engagement explicite de la communauté nécessaires à un changement majeur du runtime CPython

[GN⁺]

Avis sur Lobste.rs

• Ça n’a pas l’air particulièrement hostile, mais c’est un peu maladroit. Si JIT est encore une fonctionnalité expérimentale, le fait que l’intégration continue ne semble pas poser de problème
  Si des personnes comme Shannon disent « nous allons proposer une PEP, mais laissez-nous éviter les conflits maladroits », j’ai tendance à penser qu’on peut leur faire suffisamment confiance pour ne pas avoir à imposer un verrouillage strict empêchant toute avancée. Il est possible que cette annonce publique soit arrivée après des discussions privées, mais j’espère que cela se passera bien, sans blessures inutiles

• La proposition d’une interface permettant différentes implémentations de JIT donne l’impression de mal comprendre, de façon assez profonde, ce qu’exige un JIT haute performance. Les personnes travaillant sur le JIT ont sans doute rencontré plusieurs problèmes, mais l’un des principaux semble être qu’elles n’ont pas pu — ou pas voulu — modifier en profondeur les structures de données fondamentales du runtime
  Bien sûr, Python a aussi le problème d’exposer pratiquement toute son implémentation comme s’il s’agissait d’une API. Malgré tout, si quelqu’un fait n’importe quoi, on peut toujours l’obliger à réécrire le typage, mais pour cela il faut une communauté qui accorde vraiment beaucoup d’importance aux performances. Historiquement, Python a tenu le coup en faisant en sorte que les bibliothèques nécessitant des performances ne soient pas écrites en Python, et cela a influencé les priorités. Je me souviens qu’autrefois, dans des comparaisons de performances entre langages, on comparait des implémentations d’algorithmes de base avec des implémentations Python qui, en réalité, n’étaient que des enveloppes autour d’implémentations C très optimisées et peaufinées

  • La proposition d’interface JIT semble inspirée de Ruby, et j’ai l’impression que cela a plutôt bien fonctionné chez Ruby. Donc il se peut que Ruby n’ait pas de JIT ultra-haute performance, mais c’est peut-être acceptable. Je pense que beaucoup de gens seraient satisfaits si le JIT de Python fonctionnait au moins aussi bien que celui de Ruby

  • Je ne vois pas très bien pourquoi on dit que « la proposition d’une interface permettant différentes implémentations de JIT comprend très mal ce qu’il faut pour un JIT haute performance »
    Comme vous l’avez dit, Python expose aujourd’hui son implémentation comme une API, mais pour la même raison le JIT appelle aussi ces API. En pratique, certaines fonctions ont même été exposées comme symboles publics au linker parce que le JIT en avait besoin. Personnellement, je travaille sur un JIT de méthodes plutôt que sur un JIT de traçage, et j’ai publiquement soutenu l’idée d’un JIT enfichable

• Je me demande pourquoi cela a été publié comme une annonce publique au lieu d’être envoyé comme demande privée aux principaux développeurs du JIT

  • Parce que Python est un projet open source piloté par la communauté. Même dans des projets propriétaires, des annonces similaires ont déjà fuité

• On dirait qu’il faudrait qu’un anthropologue, quelque part, écrive un livre sur la bureaucratie dans les projets logiciels open source, et que Python et Debian en soient des objets d’étude centraux
  Ce n’est pas un reproche. Ce type de bureaucratie correspond, au fond, à une prise de décision distribuée et à un processus de construction du consensus, et il est difficile de faire fonctionner cela correctement à cette échelle

  • Gabriella Coleman est une anthropologue qui a mené une enquête de terrain sur Debian. Le livre qui en est sorti, « Coding Freedom », est vivement recommandé

• Honnêtement, cela donne l’impression d’être le même syndrome qui a mené à Python 3, mais avec l’effet inverse. CPython existe surtout pour le plaisir de ses implémenteurs, et ce changement risque d’être assez pénible pour les gens habitués à bricoler de la manière actuelle
  La bonne direction serait sans doute de soutenir une version JIT comme implémentation séparée, de lui permettre d’évoluer librement, tout en visant la compatibilité avec le CPython d’origine comme objectif de meilleure volonté

  • Je ne vois pas exactement ce que veut dire « le même syndrome qui a mené à Python 3, mais avec l’effet inverse »
    Quant à l’idée que « CPython existe surtout pour le plaisir de ses implémenteurs », l’impression que j’ai eue de mes interactions limitées avec le SC et les core developers était plutôt l’inverse. Ils semblaient généralement assez profondément engagés à trouver un équilibre raisonnable entre continuer à soutenir la communauté existante et avancer vers l’avenir