Skip to content

Points sur les livrables - 2021/11/03

Liste des livrables

  • D-CYP-10 Une première version de Cython+ acceptée par la communauté Cython et offrant une exécution efficace sur une architecture multi-cœurs

    • JPS: Faire savoir que ça marche bien avec scikit-learn. Les financeurs seront contents.
    • JJ: “On doit pouvoir avoir des temps d’exécution bien meilleurs dans scikit-learn du fait de l’exécution asychrone”. Il a un blog post en cours de rédaction (en parallèle de l’implémentation).
    • JJ: il est peu probable qu’on bascule scikit-learn vers Cython+ a court-moyen terme. La meilleure issue serait que Cython+ soit mergé dans Cython.
    • JPS: Je dois aller voir Stefan Behnel à Munich avant qu’on commence à s’exprimer publiquement, par exemple dans la mailing list. Il faut lui montrer des use cases qui marchent (ex: scikit-learn)
  • D-CYP-20 Une implémentation du modèle PyObject compatible avec une exécution multi-coeur sans global interpreter lock (GIL)

    • JPS: pour moi c’est fait depuis 1 an.
  • D-CYP-30 Un outil d’analyse statique de code et d’aide à la suppression de deadlocks dans l’exécution concurrente

    • JPS: on n’en a plus besoin, on a un modèle où il n’y a plus de deadlocks.
    • JD: on a fait des benchmarks classiques, qui chargent énormément les thread, et ça passe.
  • D-CYP-40 Une version de NEO en Cython aux performances équivalentes à la version de NEO en golang et mutuellement interopérable

    • JPS: Pas du tout fait. Je peux demander à Kiril, ou à un stagiaire. Avec Kiril ça prendra 3 ans et ca marchera, avec un stagiaire ca prendra 3 mois et ca marchera pas.
  • D-CYP-50 Un framework Web applicatif capable d’exécuter des coroutines Cython sur plusieurs cœurs

    • Cf. discussion below.
  • D-CYP-60 Un modèle de contrôle d’allocation de ressources par les framework hétérogènes de programmation concurrente.

    • JPS: joblib…
    • JJ: github.com/joblib/threadpoolctl/
  • D-CYP-70 Un serveur de publication et de partage de grand jeux de données pour les data science et l’IA

  • D-CYP-80 Un notebook Jupyter capable de compiler nativement Cython+ et de l’appliquer à des grands jeux de données

    • JPS: fait et déployé à l’IMT.

Il y a aussi un livrable sur Olapy: prendre une fonction / une classe et accélérer…

Conclusion: les principaux trous dans la raquette sont l’acceptation par la communauté Cython, NEO et le framework applicatif.

Discussion: relation avec Cython

Relation avec S. Behnel: il travailler 1 jour/semaine sur Cython, il veut pas qu’on l’emmerde. Il a pas répondu au mail de XT (notes sur l’architecture du compilo Cython). Si un sujet ne l’intéresse pas, il répond pas. => Il faut aller le voir et le payer. Le meilleur argument c’est de montrer que ça sert pour scikit-learn. Ca peut prendre des années que ce soit intégré dans Cython+. On peut réver d’intégrer Cython+ comme un plugin de Cython, mais il y a peut de change que ça aboutisse.

Quelles sont les alternatives si on n’y arrive pas ? Fork, comme Cython est un fork de Pyrex. Nexedi est motivé pour l’utiliser et le maintenir (pour pas avoir à faire de C++ ou de Go).

Conclusion: le blog post de JJ est important pour avancer.

Discussion: framework (ou serveur) Web

SF: ca peut être un serveur web (HTTP/1.1 ou HTTP/3) ou un framework (à la Flask, Sanic, etc.)

JPS: on veut du HTTP/3 car sur tous les serveurs qu’on a utilisé il y a des bugs compliqués de concurrence, de timeout, dès qu’ils sont chargés. Il faut qu’on maitrise et qu’on puisse débugger nous-même.

  • Apache a des fuites de process (après plein de restart on a un timeout sur la requête suivante)
  • Même pb dans Nginx
  • Pb similaire mais différent dans Caddy.
  • => 0.1% à 0.5% d’erreurs sur un front-end avec 3000 domaines.
  • Solutions possibles: Cython+, HA-Proxy ou le front-end HTTP/3 de Clever Cloud

JD: c’est un projet complexe difficile à faire dans le temps imparti.

JPS: il faut regarder Caddy.
JPS: même problème pour WebRTC (Pion en Go qui marche a peu près, Janus en C++ mais 10 ans pour stabiliser)

JD: le temps pour coder en Cython+ est long car on est les premiers à l’utiliser (JJ et moi), il y a pas de doc, il manque les librairies (et des questions “stratégiques” se posent à chaque nouveau besoin: est-ce qu’on fait quelque chose de proche de Python ou proche de C++). On aimerait n’utiliser Cython+ qu’à la périphérie, mais pour un framework, c’est pas possible.

JPS: on a fait un truc qui prend du HTTP et qui ouvre des sockets (en utilisant Mongoose). [TODO: récupérer le code]. Ca donne un exemple de l’approche à utiliser.
JPS: on aussi un exemple de code en Rust qu’on a écrit en Cython+.
JPS: j’ai demandé à XT de faire le serveur HTTP le plus simple possible. Il utilise la librairie C. On finit en général par wrapper des librairies C ou C++.

XT: TBOX (https://tboox.io/) donne de bons résultats. Il faut des coroutines. Il manque le context-switch pour attendre qu’une co-routine finisse.
XT: AIOQUIC ca peut être intéressant car ca utilise sansio, donc on peut découpler.

JPS: le coeur du framework doit être fait en Cython+ (+ des librairies C/C++/etc). Le reste peut être fait en Python (CLI, configuration, tests, etc.). Le moindre appel Python conduit à tout arrêter donc tue les perfs.

JD: Quelles sont les plus grosses bases de code en Cython+ ? =>
- JJ: Quelques centaines de lignes (ex: les kd-trees de JJ).
- XT: 300 lignes.
- XT: on a intérêt à découpler le runtime du compilateur.
JD: A fait pas mal de code dans “cythonplus-sandbox”. Essaie d’appliquer le paradigme Cython+ à des benchmarks classiques. Pb par exemple avec les constantes vs. le système d’acteurs.
JD: Il faut définir un périmètre minimal pour le “framework web”, sinon on n’y arrivera pas dans le temps imparti.

JPS: il faut livrer une appli HTTP déployable (quelle qu’elle soit) en se donnant des contraintes de temps pour voir ensuite. Par exemple un proxy HTTP. Mais c’est pas obligé. Il faut une application HTTP haute performance qui sert à qq chose. Ex JMAP (IMAP sur HTTP en JSON) -> faire un proxy JMAP vers IMAP. Ou un serveur de notification web (mais pas évident que ce soit utile).

JD: il y a une implémentation d’HTTP/3 dans une librarie de CloudFlare, mais c’est gros et pas évident.

JPS: Cython+ ne sert qu’à traiter ce qu’on ne sait pas traiter avec du multiprocess. Ex: un CDN, un serveur de notifications…

Next steps

  • XT, JJ, JPS: Voyage à Munich (à préparer avec le blog post).
  • Abilian: décider ce qu’on va livrer comme cas d’application.
  • Nexedi: décider qui va bosser sur NEO (en partant de NEO-Python). [NB: NEO-Go ne marche pas en prod].
  • Sven: doit contacter la Région pour organiser la revue de projet.
Back to top