GraalPy - runtime Python 3 embarqué hautes performances

 (graalvm.org)
1 points par GN⁺ 2024-09-18 | 3 commentaires | Partager sur WhatsApp
  • Runtime Python 3 embarquable hautes performances pour Java
  • Permet de charger et d’utiliser directement des packages Python depuis Java
  • Compatible avec les packages Python récents pour l’IA et la data science
  • Permet d’exécuter Python à une vitesse proche du code natif grâce au compilateur JIT Graal
  • Offre un chemin de migration aux utilisateurs de Jython
  • Permet d’utiliser des scripts Python depuis Java pour interagir avec des classes et frameworks Java
  • Permet de packager des applications Python en un binaire unique avec GraalVM Native Image

Le récapitulatif de GN⁺

  • GraalPy fournit un runtime permettant d’exécuter Python avec de hautes performances dans Java
  • Offre aux utilisateurs de Jython un chemin de migration pour profiter des fonctionnalités modernes de Python
  • Grâce à l’interface polyglotte de GraalVM, permet d’intégrer facilement des bibliothèques Python de data science dans des applications Java
  • Renforce l’interopérabilité entre Python et Java, offrant davantage de flexibilité aux développeurs
  • Parmi les projets proposant des fonctionnalités similaires figurent Jython et Py4J

À lire aussi

3 commentaires

 
GN⁺ 2024-09-18
Avis Hacker News

  • Partage de résultats de benchmark comparant GraalPy et JDK8

    • JDK8 est environ 2,4 fois plus rapide que GraalPython EE 22.3 Hotspot
    • JDK8 est 41 fois plus rapide que CPython 3.11
    • GraalPython est environ 17 fois plus rapide que CPython et environ 2 fois plus rapide que PyPy
    • Graal Enterprise Edition (EE) est environ 1,31 fois plus rapide que Community Edition (CE)

  • Quelqu’un a essayé d’exécuter un gros projet avec GraalVM, mais a rencontré plusieurs problèmes

    • Maturin ne prend pas en charge l’interpréteur Graal, donc impossible d’utiliser des paquets Py03
    • uv ne s’exécute pas, et fork ainsi que execve sont absents du paquet os
    • Graal exige d’appliquer de nombreux correctifs à des bibliothèques populaires
    • Utiliser Graal pour de gros projets est difficile en raison du niveau de risque élevé

  • Avis selon lequel GraalVM pourrait être utile pour les programmes utilisant Spark s’il pouvait appeler directement des fonctions Java (ou Scala) sans pont

  • L’aspect intéressant de Python est son intégration avec la toolchain ML, CUDA, Metal/MLX, pytorch, tensorflow, les encodeurs/décodeurs de LLM, etc.

    • Doute sur la capacité de GraalVM à exécuter ce type de code de manière réellement pertinente

  • Il existe déjà un cas d’intégration Java/Python implémenté en Clojure

    • Rendu possible grâce à Chris Neurnberger et libpython-clj

  • DuckDB n’est pas pris en charge actuellement, mais Pandas et matplotlib le sont

    • Avis selon lequel la prise en charge de DuckDB et Polars serait utile pour de nombreux travaux de data

  • Constat que GraalPy cible Python 3.11

    • Aucune mention du GIL
    • Avertissement aux utilisateurs de Python de ne pas cliquer sur le lien de démarrage rapide

  • Interrogation sur les cas d’usage de GraalPy

    • Avis indiquant ne pas comprendre pourquoi il faudrait utiliser GraalPy

  • Question sur le fait de savoir si GraalPy doit s’exécuter uniquement sur GraalVM ou si cela est aussi possible sur d’autres implémentations de la JVM
 
ahwjdekf 2024-09-29

Le projet sur lequel je travaille en ce moment consiste à refaire en Java une implémentation réalisée en Python avec numpy et pandas, une demande complètement aberrante. Du coup, on est en train de tout reconstruire depuis zéro. C’est absurde. Si GraalPy prenait correctement en charge pandas et numpy, on pourrait peut-être éviter ce genre de travail inutile. Mais dans un environnement Windows, il y a une dépendance à Visual Studio, pour l’environnement de compilation C++. Et puis, même si l’idée est vraiment bonne et utile, je me demande comment ils vont réussir à faire aboutir sans encombre un écosystème aussi vaste. Ça m’inquiète un peu. Je me demande aussi si ça deviendra vraiment assez stable pour qu’on puisse l’utiliser en toute confiance. Si ça arrivait, ce serait vraiment bien.
 
ahwjdekf 2024-10-01

En regardant d’un peu plus près, j’avais mal compris certains points. Les dépendances à gcc ou à VS ne sont nécessaires que lorsqu’on utilise native image.