Experiment für Free-Threaded CPython ist bereit

• Free-Threaded CPython ist eine große Veränderung, die es ermöglicht, mehrere Threads innerhalb desselben Interpreters parallel auszuführen
• Wird in CPython 3.13 als experimentelle Funktion bereitgestellt
• Dank PEP 703 kann es mit deaktiviertem GIL ausgeführt werden
• Wichtig für Leistungssteigerungen, insbesondere bei Multithreading-Performance
• Ermöglicht die effektive Nutzung mehrerer CPU-Kerne

Beeindruckend, aber was sind die Probleme?

• Die Implementierung von Free-Threading in CPython selbst ist ein großer Aufwand
• Zwei Hauptprobleme: Thread-Sicherheit und ABI-Kompatibilität
  • Thread-Sicherheit: Reiner Python-Code funktioniert ohne Änderungen, aber Code, der in anderen Sprachen geschrieben ist oder die CPython-C-API verwendet, tut das möglicherweise nicht
  • ABI-Kompatibilität: Der Free-Threaded-Interpreter hat eine andere ABI, daher muss jedes Paket mit Erweiterungsmodulen zusätzliche Wheels bauen
• Probleme mit der Thread-Sicherheit sind schwer zu verstehen, zu verbessern und zu testen
• Beispiele: intermittierende Fehler in numpy#26690, pywavelets#758 usw.

Nächste Schritte und Arbeit des Teams

• Es wird noch einige Jahre dauern, bis Free-Threaded CPython zum Standard wird
• Es besteht die Hoffnung, dass in Python 3.13 viele Projekte an der Kompatibilität arbeiten und cp313t-Wheels auf PyPI veröffentlichen
• Das Team hat vor einigen Monaten begonnen, von der Basis des PyData-Stacks aus zu arbeiten
• Für jedes Paket wird ein ähnlicher Ansatz verwendet:
  1. Ersten CI-Job hinzufügen
  2. Probleme mit Thread-Sicherheit sowie gemeinsamem/globalem Zustand beheben
  3. Free-Threaded-Unterstützung zu den CI-Jobs für den Wheel-Build hinzufügen
  4. Lokal Stresstests durchführen und CI-Jobs überwachen
  5. Erweiterungsmodule so markieren, dass sie ohne GIL ausgeführt werden können
  6. Zum nächsten Paket übergehen

Zusammenfassung von GN⁺

• Free-Threaded CPython ist eine wichtige Veränderung, die die Multithreading-Performance deutlich verbessern kann
• Die Lösung von Problemen bei Thread-Sicherheit und ABI-Kompatibilität ist die zentrale Herausforderung
• Es besteht die Hoffnung, dass viele Projekte mit Python 3.13 an der Kompatibilität arbeiten und experimentieren können
• Wichtige Pakete wie PyTorch und viele kleinere Pakete müssen diese Veränderung aufgreifen
• Zu den verwandten Projekten gehören PyO3 und PyTorch

[GN⁺]

Hacker-News-Kommentare

• Durch die Entfernung des GIL in Python entsteht für viele Organisationen und Projekte die Chance, die Leistung mit kaum zusätzlichem Aufwand deutlich zu steigern

  • Wenn ältere Bibliotheken diese Veränderung nicht rechtzeitig aufgreifen, könnten neue Projekte Marktanteile gewinnen
  • Man kann die Komplexität und Bugs von Multiprocessing vermeiden und stattdessen einfache Threads nutzen, um alle Kerne großer Maschinen auszuschöpfen

• Es werden Erfahrungen damit geteilt, eine Python-Version ohne GIL auf macOS zu installieren und zum Laufen zu bringen

  • Dazu wurde ein kurzes Skript geschrieben, das den Installationsprozess und die Unterschiede erklärt
  • Link

• Ein Nutzer, der die einfache Schreibweise und Logik von Python schätzt, hofft, dass der Ansatz ohne GIL der bisherigen Art, Python zu schreiben, ähnlich bleibt

  • Es wird erwähnt, dass man sich wegen der Schwierigkeit von Multithreading nicht tiefer damit beschäftigt hat

• Der Fortschritt von Python 3 wird zusammengefasst

  • [x] Async
  • [x] Optionales statisches Typing
  • [x] Threading
  • [ ] JIT
  • [ ] Effizientes Dependency-Management

• Es wird daran erinnert, dass parallele Verarbeitung etwa ab 2007 unverzichtbar wurde

  • Dabei wird erwähnt, dass Rust bei Geschwindigkeit und Parallelverarbeitung im Vorteil ist

• In PEP703 wird erklärt, wie nach der Entfernung des GIL die Operation append bei Listen threadsicher bleibt

  • Es wurden Sperren pro Liste hinzugefügt
  • Es wird erwähnt, dass einfache Operationen zum Erhöhen von Ganzzahlen derzeit durch den GIL threadsicher sind

• Es besteht Vorfreude darauf, wie die Entfernung des GIL den Charakter von ML-Training und Inferenz verändern wird

  • Die Komplexität von Speicherübergabe und Prozesskoordination könnte sinken
  • Es gibt die Erwartung, dass Bibliotheken wie PyTorch optimiert werden könnten

• Es besteht die Sorge, dass Programmierer, die noch nie echtes Multithreading behandelt haben, neue subtile Bugs einführen könnten

• Es wird die Frage aufgeworfen, ob der Rückgang der Single-Thread-Performance gravierend ist

  • Es konnten keine Benchmarks gefunden werden, stattdessen gab es nur allgemeine Beschwichtigungen

• Es wird Neugier darauf geäußert, wie das mit Async zusammenarbeitet

  • Es gibt eine natürliche Grenze zwischen I/O- und CPU-bound-Code
  • Man würde gern ein flexibleres Modell sehen
  • Es wird gefragt, ob JIT möglich wäre, wenn man in CPU-bound-Coroutinen ein "gather" ausführt
  • Ein flexibles Programmiermodell, das mit einer ähnlichen Schnittstelle schnelle Wechsel erlaubt, würde als großartig angesehen