Python 3.14 ist erschienen. Wie viel schneller ist es geworden?

• Das jetzt veröffentlichte Python 3.14 zeigt die bisher schnellste Leistung aller CPython-Versionen
• Im Single-Thread-Betrieb zeigte 3.14 gegenüber 3.13 eine Verbesserung von rund 27 %, während der Leistungsgewinn durch JIT gering ausfällt und der Free-Threading-Interpreter im Single-Thread-Betrieb leicht langsamer ist
• Im Multithread-Betrieb zeigt der FT-Interpreter durch den Wegfall des GIL eine Beschleunigung um das 3,1-Fache bei Fibonacci und das 2-Fache bei Bubble Sort und ist damit für CPU-intensive Multithreading-Workloads wirksam
• Fazit: 3.14 ist das schnellste CPython überhaupt, 3.11 oder neuer wird empfohlen, PyPy ist weiterhin sehr schnell, und JIT braucht noch mehr Reife

---

Voraussetzungen und Grenzen des Benchmarks

• Kurz nach der offiziellen Veröffentlichung von Python 3.14 wurden die Ergebnisse von Performance-Benchmarks zwischen mehreren Python-Versionen und anderen Sprachen geteilt
• Der Test wurde mit einfachen rekursiven Funktionen (Fibonacci) und iterativen Funktionen (Bubble Sort) durchgeführt, die ausschließlich in reinem Python-Code geschrieben waren
• In realen Entwicklungsumgebungen wird häufig nativer Code wie C/C++/Rust beigemischt, daher sind diese Ergebnisse nicht 1:1 auf reale Szenarien übertragbar

Testmatrix

• Testumgebung
  • 6 Python-Versionen (3.9–3.14), PyPy, Node.js und Rust enthalten
  • Python-Interpreter: Standard, JIT, Free-Threading (jeweils ab 3.13)
  • Testskripte: Fibonacci (fibo.py), Bubble Sort (bubble.py)
  • Thread-Modi: Single-Thread, 4 Threads
  • Testmaschinen: Linux (Framework i5), macOS (M2)
• Auch die Versionen von Node.js und Rust wurden als Referenz mit verglichen

Testskripte

• Fibonacci (fibo.py): rekursive Struktur, Ausführung von fibo(40) in jeder Umgebung
• Bubble Sort (bubble.py): Sortierung von 10.000 Zufallszahlen
• Jeder Test wurde dreimal wiederholt und daraus ein Mittelwert berechnet
• Der Testcode ist im GitHub-Repository veröffentlicht

Benchmark #1: Fibonacci (Single-Thread)

• Python 3.14 erreichte gegenüber 3.13 eine um rund 27 % höhere Geschwindigkeit (6,59 Sekunden vs. 8,26 Sekunden)
• Seit Version 3.11 wechselte es von „sehr langsam“ zu „wenigstens etwas weniger langsam“
• PyPy ist etwa fünfmal schneller als 3.14 und liegt auf dem Niveau von Node.js, während Rust mit großem Abstand am schnellsten ist
• Free-Threading ist im Single-Thread-Betrieb weiterhin langsamer als die Standardversion, doch mit 3.14 hat sich der Abstand verringert (auf etwa 91 %)

JIT- und Free-Threading-Interpreter

• JIT bringt bei dieser rekursiven Funktionsstruktur keine spürbare Leistungssteigerung
• Free-Threading liefert im Single-Thread-Betrieb sogar ein leicht schlechteres Ergebnis
• Die Grenzen des JIT-Leistungsgewinns können je nach Funktionsstruktur unterschiedlich ausfallen

Benchmark #2: Bubble Sort (Single-Thread)

• Python 3.14 ist geringfügig schneller als 3.11, der Abstand ist aber kleiner als bei Fibonacci (3.14: 2,18 Sekunden, 3.11: 2,48 Sekunden)
• PyPy ist etwa 18-mal schneller als 3.14
• JIT ist unter Linux mitunter leicht schneller, unter macOS gibt es fast keinen Unterschied

Benchmark #3: Fibonacci (Multithread)

• Beim Standard-Interpreter führt der GIL (Global Interpreter Lock) dazu, dass mehr Threads nicht den erwarteten Geschwindigkeitsgewinn bringen
• Der Free-Threading-Interpreter (3.14) ist gegenüber dem Standard 3,1-mal schneller
• Ein Einfluss von JIT ist kaum feststellbar
• Gemessen wurden nur die Ergebnisse von PyPy; Node.js und Rust wurden in diesem Test nicht verglichen

Benchmark #4: Bubble Sort (Multithread)

• Free-Threading (3.14 FT) ist gegenüber dem Standard (3.14) 2-mal schneller (der Vorteil zeigt sich besonders bei CPU-intensiven Aufgaben)
• JIT zeigt keinen klaren Leistungsvorteil
• Die Free-Threading-Leistung auf dem Mac fällt besonders auf

Fazit

• CPython 3.14 zeigt die schnellste Leistung unter den derzeit verfügbaren CPython-Versionen
• Wenn ein Upgrade schwierig ist, wird die Nutzung von 3.11 oder neuer empfohlen
• Der JIT-Interpreter brachte in der Praxis nur geringe spürbare Geschwindigkeitszuwächse
• Der Free-Threading-Interpreter hat deutliche Vorteile in CPU-intensiven Multithreading-Szenarien
• PyPy ist überragend schnell und weitere Untersuchung wert

Sonstiges

• Die Ergebnisse können je nach verschiedenen Umgebungsvariablen unterschiedlich ausfallen; eigene Benchmarks und Verifizierung werden empfohlen
• Weitere Details und der Code sind im GitHub-Repository zu finden

[GN⁺]

Hacker-News-Kommentare

• Ich möchte von jemandem erzählen, der mein Leben verändert hat. Über das Flask Mega Tutorial habe ich meine erste Website gebaut, und kurz vor dem Launch blieb ich an einem wichtigen Teil hängen, bei dem Flask mit kaputten Dateien umgehen musste. Ich stellte eine Frage, bekam eine Stack-Overflow-Antwort und konnte die Lösung sofort auf der Website einbauen. Danach ging die Seite richtig durch die Decke. Zur Referenz hier der Link zur Antwort: stackoverflow link

  • Hat zwar nichts mit Flask zu tun, aber das neue Flask-Logo gefällt mir überhaupt nicht. Das alte Logo hatte so einen Vintage-, handgemachten Charakter, während das neue aussieht, als hätte ein Highschool-Schüler zum Spaß mit WordArt herumgespielt. Altes Logo, Neues Logo

  • Ich würde gern fragen, ob die von dir gebaute Seite yout.com ist. Mich würde interessieren, ob dort immer noch Flask verwendet wird

  • Es wäre wirklich schön, wenn microphonetest.com irgendwann mit etwas Vibe Coding wiederbelebt würde

• Ich würde davon abraten, Benchmarks so zu schreiben, dass innerhalb der Schleife die Zeit gemessen und dann aufsummiert wird. Besser ist es, die Laufzeit der gesamten Schleife zu messen und anschließend durch die Anzahl der Durchläufe zu teilen. Der Jitter, der allein durch die Zeitmessung entsteht, kann die Ergebnisse verfälschen

  • Ich empfehle timeit aus der Standardbibliothek: timeit docs

• Ich mache mir Sorgen, dass Python bei Version 3.14 so festgeschrieben wird wie TeX Reddit-Link

  • Beim Lesen der Meinung, dass man hoffe, es werde nicht „anhalten“, fand ich den Gedanken erfrischend, dass Donald Knuth einem System, das dauerhaft dieselben Ergebnisse liefert, mehr Bedeutung beimisst als ständigen Veränderungen. In einer Welt, in der nach ein paar Jahren alles als veraltet gilt, wirkt der Zwang, sofort auf etwas Neues umzusteigen, nur weil wieder irgendetwas Neues erschienen ist, fast wie eine Krankheit. Es gibt keinen wirklichen Grund, warum wir keinen Code schreiben sollten, der 100 Jahre nutzbar ist. Code ist letztlich Mathematik. So wie niemand als altmodisch gilt, nur weil er Polynome verwendet, die vor Tausenden von Jahren erfunden wurden, finde ich, dass man ruhig auch bei Bewährtem bleiben kann. Man muss nicht jedem neuen Release und jedem neuen Tool hinterherlaufen. Ich denke, die Menschen, die Code schreiben, den man nicht ohne Grund ändern muss, leisten den eigentlichen Beitrag

  • Ein Kommentar, dass die Situation erstaunlich gut zu dem Witz über πthon passt

• Jedes Mal, wenn es Python-News gibt, finde ich es schade, dass PyPy im Jahr 2025 immer noch ein separater Zweig ist. Ich frage mich, ob GIL-loses Python someday sogar GIL-loses C FFI ermöglichen wird. Das würde Python wirklich enorm helfen

  • Über C FFI konnte man den GIL schon früher manuell freigeben, deshalb frage ich mich, was genau damit gemeint ist

  • Ich halte es für ein gesundes Ökosystem, wenn ausgehend von C durch verschiedene Compiler-Implementierungen unterschiedliche Dialekte entstehen. Das fördert Experimente und Weiterentwicklung. Ich finde auch, dass der Unterschied zwischen PyPy und CPython nicht groß ist und die Kompatibilität hoch bleibt: pypy compatibility guide

  • Genau dafür ist Free-Threading gedacht. Soweit ich weiß, kann man Free-Threading noch nicht als Standard verwenden, weil viele C-FFI-Bibliotheken noch nicht so angepasst wurden, dass sie ohne GIL funktionieren

  • Python hat mit einem experimentellen JIT einen Schritt in Richtung PyPy gemacht. Ich weiß nicht, ob man künftig einen neuen JIT direkt selbst bauen oder PyPy integrieren wird, aber ich glaube, dass man viel von PyPy gelernt hat

  • Ich würde gern fragen, ob du glaubst, dass sich so ein Problem — also getrennte Implementierungswelten zusammenzuführen — ändern kann. Ein Szenario, in dem Python versehentlich noch eine weitere Breaking Change einführt, die die Performance verschlechtert, wäre für eine breite Nutzerschaft schädlich. Ich frage mich, ob die Python-Organisation das wirklich wollen würde

• Ich finde es interessant, dass PyPy auch bei Multithread-Code schneller ist als Free-Threaded CPython

• Auffällig ist, wie reibungslos der Wechsel zu non-GIL verlaufen ist. Im Vergleich zum Übergang von 2 auf 3 ist dieser Wechsel wirklich beeindruckend. Dass man so schnell die Standardgeschwindigkeit erreicht hat, macht Hoffnung, und ich hoffe, dass auch die Inkompatibilitäten bald verschwinden

• Wenn man schnell selbst einen Benchmark ausprobieren will, empfehle ich das Repo fast_langton_ant. Man kann es etwa mit python3 server.py -s 10000000 -n ausführen

• Ich frage mich, ob die Funktion für eingeklappte Kommentare je nach Karma oder anderen Optionen angewendet wird. Es war bemerkenswert, dass die Geschichte darüber, wie Miguel geholfen hat, der beliebteste Beitrag war, aber dabei ist mir zum ersten Mal aufgefallen, dass es keine Einklappfunktion gibt, wenn man nur Kommentare sehen will, die mit dem eigentlichen Thema zu tun haben

• Ich finde, dass sich mit Benchmarks, die nur einfache Schleifen und Integer-Arithmetik verwenden, die reale Nutzung von Python kaum bewerten lässt. Hashmaps oder String-Verarbeitung kommen echtem Code näher. Viele Python-Nutzer überlassen numerische Berechnungen ohnehin externen Bibliotheken

  • Benchmarks sind immer dafür gemacht, etwas nach bestimmten Kriterien zu messen. Da der Autor im Beitrag erklärt hat, was das Ziel war, würde ich empfehlen, das bei Interesse nachzulesen

  • Ich hätte mir zwar einen gründlicheren Analyseartikel gewünscht, aber für meine tatsächliche Nutzung passen solche Benchmarks trotzdem besser. Bei mir sind es meistens Monte-Carlo-Simulationen oder einfache wissenschaftliche Berechnungen, die ich für verschiedene Probleme immer wieder neu baue. Für einmalige Simulationen setze ich nicht extra auf schnellere Algorithmen oder Bibliotheken, mit denen ich nicht vertraut bin. Es ist für mich auch in Ordnung, wenn etwas mal 10 Minuten dauert (ja, scipy und numpy nutze ich meistens schon). Da ich Annahmen ständig wieder ändere, gehe ich möglichst einfach vor. Lesbarkeit und spontaner Code sind wichtig, und es ist nicht schlimm, wenn nicht alles optimal optimiert ist (z. B. Fibonacci, Bubble Sort oder verschachtelte for-Schleifen). Wenn ich wirklich Performance brauche, implementiere ich die betreffenden Teile direkt mit cpp/zmp/pybind/numba

  • Es wäre näher an der realen Python-Nutzung, populäre Beispiele wie FastAPI-Endpunktaufrufe oder numpy-Berechnungen in Benchmarks aufzunehmen. Diese Teile sind zwar möglicherweise kein reiner Python-Code, aber so verwenden viele Menschen Python tatsächlich

• Ich frage mich, wie realistisch Benchmarks sind, die nur auf Tight Loops und Integer-Operationen basieren

• Ich frage mich, ob der neue experimentelle Tail-Call-Interpreter (Option --with-tail-call-interp) in den Benchmarks enthalten war offizielle tail-call-interp-Dokumentation. Da er in den Testergebnissen nicht erwähnt wird, vermute ich, dass er nicht enthalten war. Ich würde gern sehen, wie stark sich der Tail-Call-Interpreter von anderen bisherigen Implementierungen unterscheidet

  • Der verwendete Python-Build hatte Tail Call bereits aktiviert (Option --with-tail-call-interp). Ich bin mir nicht sicher, ob die Optimierung auch auf rekursive Tail Calls angewendet wird, aber wenn ja, hätte man beim Fibonacci-Test eine Leistungssteigerung sehen müssen