GraalPy - Hochleistungsfähige eingebettete Python-3-Laufzeit

 (graalvm.org)
1 Punkte von GN⁺ 2024-09-18 | 3 Kommentare | Auf WhatsApp teilen
  • Hochleistungsfähige einbettbare Python-3-Laufzeit für Java
  • Python-Pakete können direkt aus Java geladen und verwendet werden
  • Kompatibel mit aktuellen Python-Paketen für KI und Data Science
  • Python kann über den Graal-JIT-Compiler mit nativer Codegeschwindigkeit ausgeführt werden
  • Bietet einen Upgrade-Pfad für Jython-Nutzer
  • Python-Skripte können in Java verwendet werden, um mit Java-Klassen und Frameworks zu interagieren
  • Python-Anwendungen können mit GraalVM Native Image als einzelne Binärdatei paketiert werden

Zusammenfassung von GN⁺

  • GraalPy bietet eine Laufzeit, mit der Python in Java mit hoher Performance ausgeführt werden kann
  • Für Jython-Nutzer bietet es einen Upgrade-Pfad, um moderne Python-Funktionen zu verwenden
  • Über die Polyglot-Schnittstelle von GraalVM lassen sich Python-Data-Science-Bibliotheken leicht in Java-Anwendungen integrieren
  • Es erhöht die Interoperabilität zwischen Python und Java und bietet Entwicklern mehr Flexibilität
  • Projekte mit ähnlichen Funktionen sind unter anderem Jython und Py4J

Verwandte Beiträge

3 Kommentare

 
GN⁺ 2024-09-18
Hacker-News-Kommentare

  • Es werden Benchmark-Ergebnisse geteilt, die GraalPy mit JDK8 vergleichen

    • JDK8 ist etwa 2,4-mal schneller als GraalPython EE 22.3 Hotspot
    • JDK8 ist 41-mal schneller als CPython 3.11
    • GraalPython ist etwa 17-mal schneller als CPython und etwa 2-mal schneller als PyPy
    • Graal Enterprise Edition (EE) ist etwa 1,31-mal schneller als die Community Edition (CE)

  • Es wurde versucht, ein großes Projekt mit GraalVM auszuführen, dabei traten jedoch einige Probleme auf

    • Maturin unterstützt den Graal-Interpreter nicht, daher können Py03-Pakete nicht verwendet werden
    • uv läuft nicht, und im os-Paket fehlen fork und execve
    • Graal erfordert viele Patches für verbreitete Bibliotheken
    • Der Einsatz von Graal für große Projekte ist wegen des hohen Risikos schwierig

  • Es wird die Meinung geäußert, dass GraalVM für Programme mit Spark nützlich wäre, wenn es Java- (oder Scala-)Funktionen direkt ohne Bridge aufrufen könnte

  • Das Interessante an Python ist die Integration mit ML-Toolchains, CUDA, Metal/MLX, pytorch, tensorflow, LLM-Encodern/Decodern usw.

    • Es wird bezweifelt, ob GraalVM solchen Code sinnvoll ausführen kann

  • In Clojure gibt es bereits ein Beispiel für eine Java/Python-Integration

    • Möglich dank Chris Neurnberger und libpython-clj

  • DuckDB wird derzeit nicht unterstützt, aber Pandas und matplotlib werden unterstützt

    • Es wird die Meinung geäußert, dass die Unterstützung von DuckDB und Polars bei vielen Datenarbeiten hilfreich wäre

  • Es wurde festgestellt, dass GraalPy auf Python 3.11 abzielt

    • Es gab keine Erwähnung des GIL
    • Warnung an Python-Nutzer, nicht auf den Schnellstart-Link zu klicken

  • Es werden Fragen zu den Anwendungsfällen von GraalPy aufgeworfen

    • Es wird die Meinung geäußert, man verstehe nicht, warum man GraalPy verwenden sollte

  • Frage, ob GraalPy nur auf GraalVM laufen muss oder auch auf anderen JVM-Implementierungen möglich ist
 
ahwjdekf 2024-09-29

Das Projekt, an dem ich gerade arbeite, ist ein völlig absurdes Projekt: Etwas, das mit Python numpy und pandas implementiert wurde, soll in Java umgesetzt werden. Also bauen wir gerade alles von Grund auf neu. Völlig unsinnig. Wenn pandas und numpy in GraalPy ordentlich unterstützt würden, müsste man diese sinnlose Arbeit vielleicht nicht machen. Allerdings gibt es in der Windows-Umgebung eine Abhängigkeit von Visual Studio. Wegen der C++-Kompilierumgebung. Und die Idee ist zwar wirklich gut und nützlich, aber ich frage mich auch ein wenig, wie man dieses riesige Ökosystem ohne Fehlschläge vollständig umsetzen will. Ich mache mir etwas Sorgen. Und ich habe auch Zweifel, ob es am Ende stabil genug sein wird, um es vertrauensvoll produktiv einzusetzen. Wenn das alles klappt, wäre das natürlich großartig.
 
ahwjdekf 2024-10-01

Bei näherer Betrachtung habe ich wohl einen Teil falsch verstanden. Die Abhängigkeiten von gcc oder VS sind offenbar nur erforderlich, wenn man native image verwendet.