Transcript: Python 3.13

Ja, hallo liebe Hörerinnen und Hörer, willkommen beim Python-Podcast. Heute Jubiläumsepisode 60.

Hi Jochen.

Jubiläum. Herzlichen Glückwunsch und auch herzlich willkommen Dominik.

Ja, und auch, genau, ja beziehungsweise.

Lieber Johannes, dich kennt man zwar.

Ja, genau.

Hallo zusammen und herzlichen Glückwunsch zur 60. Episode.

Danke. Und lieber TF, auch dir.

Ja, vielen Dank, hallo.

Du warst ja auch schon mal da, habe ich noch in Erinnerung.

Genau, Januar 23 haben wir gerade rekonstruiert.

Ja, wir sprechen heute über Python 3.13. Und ich würde sagen, dann legen wir auch direkt los.

Ja, wollen wir noch News machen oder nicht?

Ich wollte gerade sagen, mit den News.

Genau, das ist natürlich irgendwie schon ein bisschen her. Wir sind ein bisschen spät dran. Aber es ist vielleicht auch noch interessant. Es gibt ein paar schöne Sachen, die man darüber erzählen kann, oder?

Ja, also wollen wir direkt

Python 3.13, können wir auch direkt

Es war gar nicht so viel los, oder?

Nee, sonst war auch nicht so viel los, stimmt

Also ja, erzähl uns was

Ich hab's jetzt auch schon überall

irgendwie installiert, wo ich irgendwie

Projekte angefasst habe und es funktioniert super

und

genau, ja, jetzt

haben wir da so einige Dinge

Vielleicht fangen wir einfach tatsächlich mit der

neuen REPL an

irgendwie, die halt aus

einem PyPy-Projekt

übernommen wurde.

Mit der neuen REPL.

Was ist eine REPL?

Ja, so eine Read-Eval-Print-Loop.

Irgendwie das, was man bekommt, wenn man

einfach nur Python eingibt und unterdrückt.

Also nutzt ihr schon 3.13? Alle?

Außer Jochen?

Ich nutze es nicht, ich nutze aber die neue REPL.

Ah.

Das ist natürlich ein Spass.

Ja gut, ich benutze IPython überall.

Warum nicht Bipython?

Das hatten wir vorhin im Vorgespräch schon mal kurz besprochen.

Also ich fand die Begründung interessant,

warum sie eigentlich überhaupt die REPL verbessern,

wenn sie sowieso ja wissen, dass die meisten Leute

halt sich sowieso als erstes erstmal IPython installieren,

weil das halt einfach viel, viel netter ist.

Aber der Grund scheint zu sein, dass die CPython Core Devs

halt während sie quasi dann die nächste Version entwickeln,

erstmal geht PyPI nicht und PIP nicht

und IPython geht vielleicht auch nicht auf der neuen Version

und damit sie es quasi beim Entwickeln etwas netter haben,

haben sie sich quasi den schöneren Multiline Edit,

schönere History, Farben, Rappel implementiert,

der jetzt in 3.13 released.

Also ich finde es auch toll, weil ich bin ja zu v4ipycen

und ich mache das eigentlich sonst immer klassisch und toll.

Endlich.

Die Welt.

Bunt.

Die Welt verbessert durch Eigennutzer, also Sauerei.

Ja, also das mit den Farben finde ich relativ abgefahren tatsächlich.

Also ich habe jetzt seit, weiß nicht, Oktober

jetzt auch den farbigen Rappel.

und wenn ich dann aber eine alte Version benutze

und es ist dann plötzlich nur noch schwarz-weiß

und es ist ja gar nicht so viel Farbe,

es sind ja wirklich nur die größer als Zeichen,

aber das kommt einem dann fast schon altbacken vor.

Ja, Back to the Future,

das ist schon ein bisschen wie damals.

Aber schade, dass es nicht früher noch grün war oder so,

aber ein echter Hacker.

Ja, die Farbauswahl,

die die C-Python-Entwickler getroffen haben,

das war ein riesen Diskussionsthema.

Das ist halt so Bike-Shedding-mäßig.

Also da kann man halt gut drüber diskutieren.

Und das Problem ist,

dass man halt aus der Shell raus nicht rausfinden kann,

ob die Shell auf schwarz auf weiß oder weiß auf schwarz eingestellt ist.

Das heißt, man muss Farben wählen, die bei beiden Hintergrundfarben

quasi noch einen einigermaßen brauchbaren Kontrast dann ergeben.

Und deswegen ist dieses, was ist das?

Dieses Pink und Rot sind so ein bisschen so ein Kompromiss,

weil das halt sowohl auf dem schwarzen Hintergrund

als auch auf dem weißen Hintergrund noch einigermaßen gut lesbar bleibt.

Ach okay, interessant.

Ja, aber

genau,

wie kommt das denn, dass du

die Rapple schon verwendet hast,

obwohl gar nicht...

Ja, also die Rapple ist,

das ist quasi die PyPy-Rapple,

nicht ganz, also die haben total viele neue Features

eingebaut und Bugs gefixt und so, aber so

dieses Kernfeature, dass es eben

Multiline-Edit

gibt, also

vielleicht können wir auch kurz sagen, was das ist, also

wenn man quasi auf der Python-Channel

eine Funktion angibt, die halt über mehrere Zeilen geht

und man macht dann irgendwie so einen Tippfehler in Zeile

2 von 8,

dann musste man bisher halt quasi dann mit der

History Zeile für Zeile in der richtigen Reihenfolge

dann die Funktion

wieder so neu zusammensetzen, die entsprechende

kaputte Zeile dann reparieren und dann die anderen

wieder über die History holen und das

ist halt total nervig. Und deswegen gibt es

jetzt eben

Multiline Edit und PyPi hatte das, wie ich gerade schon gesagt habe,

schon quasi schon immer, also in Anführungszeichen

also seit PyPi

2.4 oder 2.5 oder so hatten wir das,

dass man halt quasi, wenn man nach einer

Funktion Pfeil nach oben drückt, dann kriegt man

halt die ganze Funktion über mehrere Zeilen. Man kann dann auch

wie in einem Editor mit Pfeil nach oben dann in die fr Zeilen der Funktion kann das einfach editieren geht dann wieder ans Ende und mit Enter definiert man die Funktion neu Und das hat ja halt sagen wir mal zwei der fr

Piper-Entwickler einfach so als

in Anführungszeichen normalen Python-Code geschrieben.

Das war einfach, also das hat eigentlich

keine Piper-spezifischen Features

irgendwie gebraucht.

Michael Hudson, Doyle und Armin Rigo waren das.

Und

so ungefähr von einem Jahr haben halt

zwei der C-Python-Entwickler,

Luca Schlanger und

Galindo Salgado gesagt, dass sie das auch gern für

CPython hätten, beziehungsweise die haben halt versucht

sich zu überlegen, wie sie den

REPL verbessern können. Der REPL war bisher in

CPython NC geschrieben und das macht halt

alle Verbesserungen daran relativ nervig und aufwendig.

Und dann haben sie halt geguckt, woher man

vielleicht Python-Code nehmen könnte,

der irgendwie einen Teil des Problems schon löst,

ohne dann alles nochmal neu machen zu müssen und dann

habe ich halt gesagt, dass

sie vielleicht sich mal anschauen könnten, was Piper da hat und

dann haben sie das eben übernommen, angepasst,

den Code auch total verbessert, weil

in PyPy ist der auch immer noch

Python 2 kompatibel, weil wir auch immer noch

Python 2 Versionen releasen

und also das

haben die quasi so ein bisschen Grund überholt

und neue Tests geschrieben und so.

Und eben auch einiges an neuen Featuren hinzugefügt, also

ich hab ein paar Notizen

dazu gemacht. Also einmal die Farben, die haben wir nicht

gehabt, dann

diesen Paste Mode, den es jetzt gibt,

also wenn man quasi aus der Zwischenablage

irgendwie mehrere Zeilen Code einfügt, dann geht ja oft

die Einhöhung kaputt und das

ist jetzt eben auch repariert.

Auch Support für Windows

hatten wir bisher auch nicht und halt die Farben.

Was ich tatsächlich

auch nicht kannte, war, dass man einfach so ein Skript

reinfügen kann. Ich habe gehört, dass das schon ein bisschen

älter ist. Ich weiß aber nicht, bei welcher Version das reingekommen ist.

Man kann eine Environment-Variable setzen

und dann wird ein Skript rausgefügt.

Das heißt, du hast deine Imports, die du immer machst,

direkt mit dabei, wenn du zum Beispiel

diese setzt.

Deine Lieblingsmodule.

Nur sieben?

Finde ich ziemlich cool. Man kann dann lustige Sachen machen.

Python-Starter heißt das.

Ja.

Sehr schön. Muss ich unbedingt

für mein System auch bauen.

Ja, aber genau.

Ein großer Vorteil ist glaube ich

auch jetzt, dass es vorher

direkt in C, glaube ich,

geschrieben ist. Und jetzt ist es halt auch

Pure Python sozusagen. Und ich glaube,

da kann man jetzt auch einfach eine ganze Menge mehr

an die Innereien rankommen und dann auch das Verhalten

so ändern, dass man da eine ganze Menge

lustige Dinge mit tun kann.

Lukas Schlager hatte da auf der

EuroPython auch einen Vortrag gehalten,

wie man Live-Coding...

Wie man eine Performance performt.

Live-Musik-Coding-Geschichten

und da ist es natürlich praktisch, wenn man halt...

Lustig war, dass der Tontechniker,

der hat einen Eurorack dabei gehabt und hat irgendwie so einen hohen Ton

auf seinem Synthesizer gespielt,

dass der Tontechniker kurz Angst bekommt, dass seine Anlage

Schrott geht, hat alles runtergedreht auf so

20% Lautstärke oder sowas

und auf einmal war es sehr leise.

Und dann hat er

fünf Minuten so gespielt und irgendwann hat jemand geklopft

vom Tuchenechniker und hat dann überredet und gesagt, ja,

Lukas, wird diese hohen Frequenzen jetzt nicht

mehr spielen? Und dann durfte er wieder lauter drehen.

Ja, ich glaube,

das sieht man auch jetzt schon so ein bisschen. Es gibt halt einfach viel mehr

Bug Reports und Patches, was den neuen Rappel angeht.

Es ist immer noch so, dass es schon so ein bisschen

nervig ist, daran zu arbeiten, weil

wenn der Rappel kaputt ist, dann sieht man halt auch gleich nichts mehr.

Also der Debugger geht nicht.

Und also es ist schon,

die haben da schon so ein bisschen

eigene debugging-Sachen eingebaut.

Aber es ist schon noch so,

es bleibt so ein bisschen frickelig. Aber ich glaube, man kann

auch die alte wieder aktivieren irgendwie.

Insofern hat man

da vielleicht dann die Möglichkeit, auch mit der Umgebungsvariable

wieder auf die alten Dings zu kommen. Aber ja,

klar, ist natürlich, wenn man es kaputt macht, dann

ein Problem.

Ah ja, wichtiges anderes Neufeature

ist natürlich, dass man jetzt bei Exit keine Klammern

mehr braucht. Oh ja. Ja, und ich glaube,

Quid geht auch. Ja, vielleicht ist das so.

Ich meine, ja.

Ja, und Help gibt auch

irgendwie jetzt anders,

aber ehrlich gesagt, keine Ahnung.

Es gibt jetzt diesen Help-Mode, der eingebaut ist mit

F1 und dann kann man quasi aus dem

aus der Shell in so eine spezielle

Help-Shell wechseln und von da dann,

wenn man quasi die Namen von

irgendwelchen Sachen, die man dokumentiert haben möchte,

eingibt, dann kriegt man die direkt angezeigt.

Aber bei Print braucht man schon noch Klammern,

oder?

Nee.

Ich möchte jetzt einfach

Python 2 wieder haben.

Vielleicht das mal als

Feature-Request vorschlagen. Also das kannst du jetzt auf jeden Fall

für deine Rappel-Katze

das einbauen, dass sie sich dann wieder gegen Python 2

Das kann ich das machen.

Das mit dem Exit ist tatsächlich was, was

halt Newbies sich relativ oft wünschen.

Also weil man dann

Q reicht, glaube ich, auch.

Was ist das so?

Q reicht? Nee.

Warum steht denn das da?

Weiß ich nicht. Ach, für den Head-Mode.

Also Crit geht, aber

Q nicht. Schade.

Adias QQ, dann muss man direkt wieder in das

Skript reinschreiben

Ja, aber so ist es auf jeden Fall

toll, also ich finde es auch super, dass man da jetzt

irgendwie echt eine ganz brauchbare Geschichte eingebaut hat und gut klar also Alphaiten ist nat auch nicht schlecht oder wie Python oder so aber genau Ja und dann daran angelegt wir haben

jetzt Farben ja schon angesprochen, vielleicht können wir noch über die

Tracebacks sprechen. Oh ja.

In 3.11 gab es ja jetzt schon

die Verbesserung, dass wir quasi in Tracebacks

diese

genaueren Positionen innerhalb von der Zeile kriegen.

Wie sagt man, Dächle, Johannes? Genau.

Dächle, ja, da wo ich

herkomme, sagt man Dächle. Sind halt auch

keine Dächer, sondern nur kleine Dächle.

So goes the Negra mit.

Genau, also es wird jetzt quasi

nicht mehr nur gesagt, das ist halt in Zeile 5 der Fehler,

sondern auch noch dieser Teil des

Ausdrucks ist

der Teil, der die Exception hervorgerufen hat.

Und das wird jetzt halt

auch noch jetzt dann farbig

irgendwie anders dargestellt als der Rest der Zeile.

Ja, auch sehr nützlich.

Tatsächlich so ein bisschen readable und

man muss sich erstmal

gucken, wo ist denn jetzt der richtige Teil vom Traceback, sondern

so irgendwie aufstehen.

Mit den Positionen, da habe ich

das Feature habe ich quasi

durch einen geschickten Tweet

provoziert. Da habe ich nämlich

einen Screenshot gefälscht, wo wir

also den hat es nie, das Feature

hat es bei uns nicht gegeben, aber ich habe

quasi einen fiktiven Traceback auf Twitter

fingiert und das hat

dann dazu geführt, dass

C-Python das wirklich entwickelt hat. Das fand ich

großartig.

Feature-Request durch Bosartigkeit,

Also wir können das und ihr?

Und dann gelogen.

Also ich hatte schon so einen Plan,

wir haben das ja dann auch irgendwann

gekriegt, aber so,

und Zephyton hat uns dann halt einfach ganz schnell überholt

und viel mehr Leute benutzen Zephyton.

Ja.

Genau, hier kann man es auch nochmal sehen.

Ja.

Jetzt natürlich nicht, wenn ihr zuhört, aber.

Ich kann es jetzt sehen.

Das einzige, was zählt.

Ja, ja.

Genau. Ja, auch schön. Man kriegt jetzt irgendwie gesagt, wenn man halt ein Modul genauso genannt hat wie eines aus der Standardbibliothek oder von sonstigen Dingen, die man installiert hat, glaube ich. Also es gibt so ein bisschen bessere. Oder wenn man halt irgendwie bei Keyword-Argumenten das irgendwie falsch übergeben hat, dann kriegt man jetzt auch. Da gab es vorher einfach nur so sehr, sehr kryptische Fehlermeldungen, die halt Anfänger auch sehr verunsichert haben. Das ist jetzt, glaube ich, auch besser.

Er macht das Vorschlag, er versucht sich

dran zu erinnern, was denn der Fehler schon sein könnte

und versucht so einen kleinen Hinweis dazu zu geben.

Ich meine, das für,

das wird halt in jeder Version jetzt gerade so

ein bisschen verbessert. Das ist schon so ein,

jetzt über einige Versionen so ein,

eigentlich so ein festes Bestandteil von

jedem C-Python-Release, dass sie halt

sich echt Mühe geben, noch so ein paar der schlechten

Fehlermeldungen zu verbessern.

Also ich unterrichte halt

Python-Anfänger jedes Semester.

Das macht schon echt einen Unterschied, ob da dann irgendwie

halt Abkürzungen vorkommen,

die noch nie gehört haben oder einfach nur Syntax-Error

ohne irgendwas

anderes steht und

raten müssen, was das Problem gewesen sein

könnte.

Und das mit den Vorschlägen, also wenn man sich halt

vertippt, wenn man irgendwie einen Namen vertippt,

das ist jetzt schon seit ein, zwei Versionen, dass sie dann

da dann Vorschläge machen könnten, was

halt der existierende Name mit der

kleinsten Edit-Distance ist.

Und jetzt haben sie es eben noch zusätzlich

hinzugefügt, dass es auch bei Keyword-Argumenten geht.

Ah, okay.

Ja.

Ja.

Also das ist auf jeden Fall

vielleicht die größte

User-Facing-Änderung, die man

halt bekommt, wenn man jetzt

Python 3.13 verwendet.

Ja.

Ja, ich würde auch sagen, wenn die ganzen Bibliotheken umgezogen sind, die man sonst

so nutzt, dann direkt

kann nicht mehr so lange dauern.

Wann zieht ihr denn immer um? Bei der 3.1?

Oder bei der Punkt 1?

Ich stelle eigentlich immer sobald,

ich probiere es vorher schon aus, also

einfach deswegen, um zu sehen, ob ich halt irgendwie

bei den Paketen, die ich

habe

oder die ich maintaine, ob da nicht dann

Dinge kaputt gehen, weil um mir dann halt,

damit ich den R gar nicht

nach der Release kriege, gucke ich das halt

Du bist dann einer von denen, die dann die Bug-Reports

machen, wenn was nicht geht.

Ja, aber meistens

ist das halt so abstrakt, dass

ich da gar nicht in Bugs reinlaufe.

Also bisher, wo ich

es probiert habe, hat es eigentlich immer funktioniert.

Und dann

updaten,

Das mache ich dann normalerweise, wenn es tatsächlich dann

erscheint. Ja, aber der Rest der Software,

den hast du ja noch nicht alles umgezogen.

Ich habe noch nicht alles umgezogen.

Ich habe auch bei einem Ding hat es nicht geklappt.

Das war irgendwie bei meinem

Fast Deploy Ding, habe ich nicht

updaten können auf 3.13, weil

irgendwas mit

PyTest und Async und

irgendwelchen Geschichten nicht mehr ging.

Dann, ich weiß es gar nicht

mehr so genau, dachte ich, okay, da warte ich jetzt mal noch

zwei Monate ab oder so, dann probiere ich es nochmal, mal gucken,

vielleicht ist es dann gefixt.

Aber genau.

Aber die Dinge, die ich angefasst habe,

seitdem Python 3 raus ist habe ich es umgestellt und es war bis jetzt auf das eine Ding kein Problem Ja die Data Science war immer so ein bisschen langsam Dann haben die immer diese Boundaries in ihren Versionen drin und das nervt immer so ein bisschen Ja ja gut okay

Ich habe jetzt auch gerade nicht so viel Data Science in der Hand.

Da ist mir das nicht so aufgefallen.

Weil ich auch da das Gefühl habe, dass

eigentlich viele Bibliotheken sich da jetzt inzwischen echt

Mühe geben und halt schon bei den

Betas und Release Candidates halt gucken, ob es geht

und dann schon. Ja. Also es ist

jetzt nicht mehr so, dass es ein halbes Jahr dauert oder so.

Mhm. Ja.

Ja, ich bin gespannt, wie lange es diesmal dauert.

Tatsächlich, ja.

Ja.

Wollen wir hier mit den großen Blöcken

weitermachen oder willst du so ein paar der kleinen Sachen sammeln?

Ich weiß nicht.

Es gibt noch große Blöcke.

Es gibt noch zwei große.

Das war auch schon ein großer Block.

Ich habe eben noch

die Dokumentation

durchgeschaut und den History-Modus,

den fand ich auch ziemlich gut.

Mit F2 kann man seine History ansehen.

Ist das auch persistent?

Ja, also ich habe eben in mein History reingeguckt in meiner Session, die ich gerade gemacht habe. Das geht sehr weit zurück. Ich war sehr überrascht, wie viel History da drin ist.

Oh, da muss man jetzt auch passen, was man da drin ist.

Das ist doch ein Fremdschatz ohne Klammern.

Ja, das will ich jetzt nicht, ohne Anwalt möchte ich diese Frage nicht beantworten.

Ne,

sehr viele schöne Sachen, aber

ich find's ja interessant, dass

3.13 so ein Release ist

mit einer riesigen Änderung

im Frontend, also jetzt diese

Rapid-Sachen, aber ja auch

sehr große Änderungen im Backend,

zu denen wir jetzt kommen.

Du meinst ja Snowgill.

Ja, da kann ich

zwei dicke Blöcke.

Dann machen wir Ditt.

Dann mach ich mir Notizen.

Ja, super, okay.

Alles klar.

Also beides sind ja eigentlich Sachen, die

eher so im...

Vielleicht nochmal für alle Leute, die einsteigen, die noch gar keine Ahnung

von Python haben, just in time.

Was ist denn das und

warum ist das interessant und warum ist das wichtig?

Vielleicht nochmal so einen kurzen Aufzug

lang und dann...

Ja.

Also C-Python ist

ein Interpreter,

also der Python-Code,

der ausgeführt wird, der wird erst nach

Bytecode übersetzt und der Bytecode wird aber dann

von einem in C geschriebenen

Interpreter ausgeführt und das

gilt als nicht so schnell.

Das ist einer der Gründe, warum Python

den Ruf hat, nicht so super schnell zu sein.

Und seit ein paar

Versionen gibt es da einiges an

Arbeiten vom Faster

Python Team,

was zum guten Teil von Microsoft bezahlt wird,

das zu verbessern. Und was die machen

ist,

immer noch auf dem Interpreter,

aber sie verändern quasi die Bytecodes

zur Laufzeit in Abhängigkeit

von den Typen, die in den Funktionen

verwendet werden, was dazu führt, dass

wenn ich halt an irgendeiner Stelle vor allem Integers

benutze, dass dann

für Integers angepasster Bytecode

verwendet wird, was die

Ausführung schneller macht. Und das, also

dieser Prozess, der hat

in 3.11 angefangen und

in jeder Version gibt es da eben so ein paar Verbesserungen.

Und wenn man dann aber darüber

noch hinaus will, dann muss man eben

oder was man dann eben machen kann,

ist nochmal zu einer anderen Technik greifen, das ist der sogenannte

das ist ein Time-Compiler und das ist eine Technik,

die von

allen schnellen JavaScript-Implementierungen

oder auch von Java verwendet wird

und da ist die Idee, dass man zur Laufzeit eben

Maschinencode erzeugt für die

Funktionen, die man gerade ausführen möchte

und das hat den Vorteil, dass man

also der Grund, warum man das zur Laufzeit

macht, ist, weil man erst zur Laufzeit die Typen

weiß, die in der Python-Funktion gerade verwendet werden

und dann kann man eben Code erzeugen,

der dann speziell angepasst

ist auf die Arten und Weisen, wie die

Funktionen, die man gerade ausführt, eben verwendet

werden.

Aber das kann ja auch sehr dynamisch

sein, aber man muss dann wahrscheinlich ein paar Mal die so

ausführen und dann gucken, was passiert und dann...

Genau. Also das ist der grundsätzliche Ansatz.

Man fängt eben an, das erstmal

so mit dem Interpreter auszuführen und dabei

macht man so ein bisschen Beobachtung, was für Typen eben

konkret verwendet werden, führt so ein paar Statistiken

mit und nur wenn

die Funktion besonders oft ausgeführt wird und man dann eben

mit der Zeit eben so ein paar Informationen zusammen

hat, wie die Typen so sind, dann fängt

sich an, quasi das so ein bisschen zu stabilisieren

und

das ist auch dann der Zeitpunkt, wo eben dann die Bytecodes

umgeschrieben werden, quasi jetzt seit

Version 3.11 und

jetzt, was jetzt neu ist

in 3.13 ist, dass dann eben

dieser zweite Schritt hinzukommt, wo man

dann eben nicht nur Bytecodes

umschreibt und so dann

für die Situation effizientere Bytecodes, sondern

eben auch noch, und das

ist komplett optional, also bisher in den Standard-Builds

ist das Feature nicht drin, das ist eher so ein

so ein Feature-Outlook

für zukünftige Versionen,

dass man eben

CPython auch neu bauen kann mit so einem

speziellen, experimentellen

Build-Time-Flag, was eben sagt, ich möchte jetzt gerne

einen JIT-Compiler einbauen

und dann wird eben zur Laufzeit

dieser spezialisierte

Bytecode genommen und daraus Maschinencode erzeugt.

Und die Hoffnung ist, dass es dann eben noch

schneller wird. In 3.13 ist es aber

leider noch nicht der Fall.

Sie erzeugen

Vielen Dank.

quasi Machine Code,

aber der, ja,

also, der macht's halt nicht,

das macht's trotzdem nicht schneller. Das ist so ein bisschen

die schlechte Nachricht, aber

das ist trotzdem okay, also weil

das Ziel ist quasi so, die ganzen,

das Fundament zu legen für Verbesserungen,

die dann in den nächsten Versionen hoffentlich

auch wirklich dazu führen, dass halt dann

C-Python das Sachen schneller ausführen kann.

Ja.

Und

das ist, glaube ich, eine spezielle Art von

Just-in-Time-Compiler oder so,

die es auch noch gar nicht so lange gibt.

Das geht irgendwie zurück auf so ein Paper

für Lua irgendwie, für so Copy

und Patch, ich weiß nicht.

Also so ganz kann man das nicht sagen.

Also es gibt die,

die Idee gibt es schon sehr lang.

Also das ist ein sogenannter Templated

und da ist die Idee, dass man,

also man hat ja dann diese spezialisierten Bytecodes,

also sowas wie

Add to Integers oder sowas

und die Idee ist, dass man

quasi für alle diese Bytecodes

so ein bisschen Maschinencode

vorbereitet, also zu dem Zeitpunkt,

wo man CPython baut.

Und das dann,

den vorbereiteten Maschinencode, also

diese Templates, die werden dann so zusammen

kopiert. Und die Idee von einem Template-Jit,

die ist relativ alt.

Aber was jetzt neu ist, und das

ist eben dieser Copy-and-Patch-Ansatz,

ist die Art und Weise, wie diese Templates

hergestellt werden. Und das ist eben

die Einsicht von einem Copy-and-Patch-Ansatz,

das ein Doktorand in

Kalifornien, glaube ich,

Haurang Su.

Und die Idee davon ist, dass man eben

den C-Compiler benutzen kann, um

diese Templates vorzubereiten. Das hat

viele Vorteile. Also man

benutzt den C-Compiler, man hat so kleine

Funktionen in C geschrieben, benutzt den

C-Compiler, um die dann nach Maschinencode zu

übersetzen. Und

das bedeutet insbesondere,

dass normalerweise, wenn man JIT schreibt,

dann muss man halt anfangen für verschiedene Maschinenarchitekturen

so ein Backend

quasi von

von Null auf

erstmal zu bauen. Und das ist halt super aufwendig,

gerade wenn man viele Architekturen unterstützen will,

wie das ja bei C-Python der Fall ist.

Und die Idee von dem Copy-and-Patch-Ansatz ist,

man benutzt den C-Compiler, um sich den Maschinencode

erzeugen zu lassen

und kopiert den dann so mit

Memcpy quasi an die richtige Stelle

und patcht dann eben noch so ein paar Stellen,

wo man dann irgendwelche Konstanten

noch so in den erzeugten Maschinencode

reinpatchen kann.

Und dazu benutzt man linker

Informationen, das ist wirklich

so ein relativ

kreativer

Ansatz, um halt mit

vergleichsweise wenig Aufwand,

also ohne so ein komplettes Backend schreiben zu müssen,

trotzdem relativ schnell, relativ

guten Maschinencode erzeugen kann.

Ja, ich glaube, das ist irgendwie

LLVM oder so wird da benutzt.

Genau, das ist auch so ein bisschen das Problem, also man braucht dann

genau die richtige LLVM-Version.

Wenn man die nicht installiert hat,

dann bringt einem auch die Flag nicht, man kann es

dann trotzdem nicht bauen. Ich habe es tatsächlich noch nicht geschafft,

das zu bauen, weil ich irgendwie das richtige LVM

noch nicht hatte oder was. Aber ich glaube,

die arbeiten da jetzt, also ich glaube,

auf dem CPython

Main Branch ist das jetzt auch irgendwie gelöst.

Da werden halt dann Sachen schon eingecheckt oder

also man muss dann

nicht mehr genau die richtige Point-Version von

LVM installieren. Aber

habe ich jetzt noch nicht ausprobiert.

Hat LVM nicht auch

so eine IR, eine Intermediate

Representation, die

auch irgendwie so abstrahiert ist?

Ich hätte sowas mal gelesen.

im Prinzip haben das die meisten

optimierenden Compiler, die haben halt irgendwie so eine Zwischendarstellung,

wo sie halt quasi

diese benutzen, um Code zu

optimieren. Und bei LVM ist die deswegen

relativ sichtbar, weil sie halt

gute Tools haben, um die dann in so eine

ASCII-Syntax zu printen und auch wieder zu parsen

und weiter zu verarbeiten.

Aber, ja.

Auch viele

technische Bauteile immer noch, ja klar.

Ja, es ist schon, also es ist

jetzt schon so ein bisschen, der JIT in

3.13, das ist schon wirklich eher so,

das sind so

vorbereitende Arbeiten. Also die Hoffnung ist eben,

dass das dann so in den

nächsten Versionen,

also ich meine, bisher ist das relativ unbefriedigend.

Wir haben einen JIT, der erzeugt ganz tollen

Maschinencode, aber es wird halt nicht schneller.

Und

es ist, ja,

cool, aber halt irgendwie auch nutzlos.

Also warum sollte man es machen, wenn

sich die Performance halt dadurch gar nicht ändert.

Aber die Hoffnung ist eben,

dass sie dann, wenn sie jetzt weitere Optimierungen einbauen

und

bei diesem Patching, da kann man noch so

ein paar extra

Instruktionen dann wegoptimieren, das haben

sie glaube ich jetzt auch im

Main Repository auch schon gemacht und

die Hoffnung ist, dass dann eben, wenn 3.14

dann da ist, dass erstens eben dann,

dass sie so ein paar Bugs gefixt haben, weil

hoffentlich eben ein paar Leute trotzdem die

den experimentellen

JIT halt mal ausprobieren und dann vielleicht

Bug Reports schicken

und dass sie dann halt in der nächsten

Version dann auch die Performance

noch ein bisschen verbessern können.

Und insgesamt finde ich den Ansatz halt cool weil er in Anbetracht der Tatsache dass das C halt jetzt nicht so gro ist was bezahlte Entwickler angeht ich finde es halt einen relativ pragmatischen Ansatz wo sie ohne jetzt irgendwie

also was ich Google vor acht

hatte, irgendwie, weiß nicht, 80

Leute oder so.

Das fand ich auch überraschend, ja.

Also das hier hat

quasi mit der kleinen Anzahl an Festangestellten

halt trotzdem

mit diesem Ansatz

vielleicht irgendwie recht pragmatisch irgendwo hinkommen

können.

Ich finde es auch cool. Ich finde es auch generell

cool, ohne dass es jetzt direkt eine Geschwindigkeitsverbesserung

bringt.

Einfach, weil, wie du gesagt hast, das ist

eine wichtige Grundlage, um dann irgendwann

die Verbesserungen rausholen zu können.

Deshalb.

Richtige Richtung, meiner Meinung nach.

Ja, ich meine, wenn man jetzt nicht so viele Ressourcen hat, muss man sich halt überlegen,

wie man die ökonomisch einsetzt. Und wenn man jetzt

sieht, was vielleicht

V8 irgendwie macht oder so, und das

dann halt einfach später, wenn sich herausgestellt hat,

was da gut funktioniert, halt dann

die wesentlichen Teile nimmt oder so.

Wobei, ich weiß nicht genau,

gibt es irgendwo quasi den gleichen

Ansatz, der dann schon gut funktioniert?

Weil V8 ist ja dann wahrscheinlich

doch eher noch deutlich komplizierter oder so.

Sehr viel komplizierter. Also V8 hat halt nicht

nur einen JIT, sondern irgendwie drei oder so.

Oder vier.

Also halt dann erstmal einen, der

quasi schlechten Code sehr schnell erzeugt und

dann etwas besser optimiert, sehr gut

optimiert. Dann haben sie noch einen komplett getrennten JIT

für WebAssembly.

Also das ist schon

und dann natürlich auch wirklich dann

quasi richtige Backends für ganz viele verschiedene

Hardware-Architekturen.

Also das ist schon ein Aufwand,

den meiner Ansicht nach mit dem

jetzigen Funding das C-Python-Thema

erstmal so nicht hinkriegen kann.

Also

genau.

Transpilen nach, einfach Python transpilen

nach JavaScript.

Ja, oder

nach WebAssembly.

Das stimmt, das ist ja tatsächlich eine unterstützte

Plattform, ja. Genau, es ist

eine Tier-2-Plattform. Ja, genau, das stimmt.

Also das ist

so ein kleines Ding. Es gibt drei neue Plattformen

in 3.30. Ja, super spannend.

Soll ich mal, ich lese mal hier vor.

Die erste,

die Tier-2-Plattform heißt

WASM32-WASI, also eine

WebAssembly-Plattform.

CF, weißt du, was

Tier-2, weißt du, was die Tiere bedeuten?

Ich glaube irgendwie, die machen Aussagen

darüber, wie viele Buildbots sie haben

und was sie so versprechen

an Support

über die Version.

Da gibt es irgendwie ein Papp dazu.

Das kann man nachlesen.

Ist jetzt eine höhere Zahl besser oder eine kleinere?

Ich glaube, eins ist am besten.

Die niedrigeren Zahlen sind besser, oder?

Je näher du am Ziel bist,

an der Spitze, umso besser ist es.

Also WebAssembly ist jetzt

Tier 2 Supported Plattform mit vielen

Bildbots und viel Stabilität über die Version.

Und es gibt zwei neue

Plattformen, die

da war ich sehr überrascht, dass es die gibt,

nämlich Android und iOS.

Das sind Tier 3, Officially Supported

Plattform.

War ja

früher ein Riesenthema,

wenn man Android, wenn man Python auf

Android ausführen wollte oder noch schlimmer, Python auf iOS.

Das

ging auch schon sehr lange.

Das ging auch schon sehr lange.

Es ist ja auch kein Problem, du kannst ja einfach

den Interpreter auch

kopilieren und so. Und da ging auch

NumPy und so, das ging alles.

Und es gab da so eine schöne App

namens Pythonista.

Aber

die hat natürlich eigentlich schon gegen die

App-Store-Regeln verstoßen.

Genau, richtig.

Also ich meine,

mein Beowulf-Cluster aus

iOS, aus iPhones.

Was ist genau die Regel?

Also die

App-Store-Regel ist,

du darfst da nur

Dinge installieren. Also

kompilierter Code, ja, aber auch irgendwie

C++, C, irgendwie

Objective-C

und

was war es noch?

Ich weiß nicht, vielleicht

eine Handvoll Sprachen.

Die Regel, dass du keinen dynamisch erzeugten

Code nachladen kannst. Ja, das genau.

Weil dann kann

Apple ja nicht mehr prüfen, ob du nicht irgendwelche

schlimmen Programme nachlädst.

Ihre Sandbox-Tests oder was auch immer.

Ja, also

eigentlich geht, und du konntest halt

mit Python, da kannst du halt auch einfach

quasi Python-Code auf deinem Telefon ausführen und

das geht natürlich eigentlich

nicht.

Aber es ging dann doch.

Ja, aber bei Android wäre das ja prinzipiell

gegangen, nur war halt das

Tooling bisher immer sehr umständlich.

Also ich weiß, dass es Beware gibt und es gab

auch Kiwi und

viele andere Ansätze schon, aber

die waren schon immer sehr umständlich.

Ja, und wenn es jetzt...

Ja, genau, das ist schon noch wichtig,

dass es jetzt halt quasi von den

CPython-Entwicklern halt mit

versorgt wird. Ich habe jetzt nochmal nachgeschaut,

was genau die Tiers bedeuten Also Tier 1 ist halt das richtig gute Zeug also so Mac OS Windows Linux Tire 2 braucht man halt irgendwie Buildbots und mindestens zwei

CPython Core Developer, die

eben die Plattform unterstützen

und wenn es da

Buildbot Failures gibt, dann

werden CPython Releases dadurch

blockiert. Und Tire 3

heißt eben

Buildbot einen Core Entwickler,

wenn es da Bugs gibt, dann

kann C-Python trotzdem

released werden.

Also es ist quasi so, wir geben uns Mühe,

aber wenn jetzt irgendwie

es nur noch irgendwie einen

bekannten Bug auf Android gibt, dann

releasen wir halt möglicherweise trotzdem.

Und der Core-Developer, der für

Android und iOS zuständig ist,

ist übrigens Russell Keith-Mede.

Der, der auch Beware

schon gemacht hat, der das schon lange macht.

Der hat es jetzt offenbar

eben reingekriegt.

Der diesen tollen Vortrag gehalten hat,

irgendwie Black Swan Events

für, ich weiß gar nicht, wie der

Titel von dem Vortrag hat, da ging es halt genau darum,

was ist eigentlich, sind die bedrohlichsten

Geschichten, die jetzt Python noch

zustoßen können und ein

Szenario war halt so, ja, was

ist, wenn irgendwie künftige

Generationen gar nicht mehr vor so riesigen Desktop-Dingern

sitzen

oder so, ich kann das gar nicht verstehen, ich finde das total toll,

aber eher vielleicht auf Tablets oder

Telefone gucken und dann einfach

in Vergessenheit gerät, dass es Python überhaupt noch gibt, weil

Python gibt es halt nicht auf iOS

oder so. Und

dagegen sollte man vielleicht was tun. Und dann, ja,

jetzt ist halt was passiert und das sieht ja schon ganz gut aus.

Ja, ich habe das bei beiden Studenten.

Man muss nach Studenten echt. Also ich habe halt,

also ich mache eine Python-Einführung

für alle, also da dürfen Informatiker

nicht hin. Und das heißt, ich habe auch

Studierende aus allen Fächern

und jetzt

nicht viele, aber da gibt es halt dann immer wieder

Teilnehmende, die dann halt einfach auch

nur ein Tablet haben. Und

Tier 1? Ja, also

wir haben kein Tier 1 Gerät, genau.

Jupiter Notebook. Wir haben dann halt entweder

die Möglichkeit, das irgendwie über Google Callup zu machen,

also ich mache alles mit Jupiter Notebooks, aber das ist halt

dann immer so ein bisschen nervig mit

die Input-Dateien hochladen und so Zeug

und dann können die sich ins Rechenzentrum

setzen, da hast du es auch installiert, aber das ist natürlich auch

total nervig, du musst immer deine Übungsaufgaben da machen

und so eine richtig

also richtig guten Jupiter Support

auf so einem

iPad gibt es halt einfach auch noch nicht.

Es ist schon einfach

im Vergleich zu installiert

Anaconda, dann ist alles in Ordnung, ist es halt schon einfach

sehr frickelig.

Ich muss

noch dazu sagen, nicht, dass wir jetzt hier Personen

übergehen. Es gibt noch zweite

Maintainer für diese Plattform, neben Russell

Keith-McGee. Für Android

gibt es noch den Peter Victorin

oder Peter Victorin

oder wie auch immer man das aussprechen mag.

Einer von den drei.

Und dann gibt es noch für iOS

gibt es noch den NetDaily.

Also wieder so eine tolle Name-Conning gemacht.

Da muss ich ja nochmal kurz zum Sammelkartenspiel

zurückkommen, was er sich kurz angegeben hat.

Weil ich ja auf dem

Talk von

Lukas Langa, der ja in diesem

tollen Rappel irgendwie dann ein kurzes

Befehlchen eingeben konnte, um

das Bild von, ich dachte es wäre

John Romero gewesen, was eigentlich

Pablo Calderon da gerade war.

Und dann hatten wir kurz dieses Thema.

Und ich finde das eigentlich eine coole Idee, dass man demnächst auf den

Pycons, so Sammelkartenspiele.

Wir bringen die erste Edition mit,

dann machen wir den Python-Podcast, das ist dann

Team One.

Ich finde, die

sollten das selbst verteilen und nur

die Leute, die bei den Vorträgen waren, kriegen auch so

eine Karte. Also ich glaube, man kann die

verkaufen. Ich vermute, dass das

wirklich die Art und Weise ist, wie man endlich

mal gutes Funding für 10 Seiten findet.

Ja, dann liebe Zuhörer,

schreibt uns, ob das die Wahrheit ist und dann

müssen wir das wohl machen. Damals als NFTs

Neuwagen gab es ja auch so Sachen, die dann diese Bilder

dann gemacht haben und das dann als NFT.

Ja, aber das mit den NFTs

ist immer noch die Zukunft.

Ich weiß nicht.

Der einzige Vorteil von AI ist, dass die die NFTs verdrängt haben.

Für einen ganz kurzen

Moment waren Grafikkarten wieder billig und

dann hat die AI zugeschlagen.

Tja.

Okay, also es gibt zwei neue Plattformen,

Android und iOS und

es ist eine großartige Sache, finde ich.

Und WebAssembly.

Und WebAssembly, ja genau.

WebAssembly ist quasi aufgestiegen.

Da müssen wir auch unbedingt mal was machen.

Im Skripten zu WASI.

Wir müssen noch über den

anderen JIT reden.

Es gibt nämlich zwei

JITs in 3.13 und der eine ist der

coole, der quasi das irgendwann mal schneller machen soll,

der aber quasi standardmäßig gar nicht eingebaut

ist und dann gibt es aber den anderen,

der quasi standardmäßig eingebaut ist, aber

von ganz anderem Zweck und

ich glaube in einer der Core.py

Folgen ist Pablo Galeno

sehr stolz drauf,

dass er quasi den ersten T-Python-Jit

gemerged hat und geschrieben hat.

Und das ist n der Jit der benutzt wird um besseres Profiling machen zu k Und das funktioniert mit dem Linux Perf Profiler Und das Problem wenn man jetzt so ein

also der Perf Profiler ist eigentlich so ein Profiler für C.

Also man kann halt sehen, was macht der Kernel,

was macht der Linux Kernel,

oder was machen eben auch die C-Programme,

die im User Space laufen.

Und man kann eben sehen,

die und die C-Funktionen werden jetzt gerade so und so oft ausgeführt.

Das ist so ein Sampling Profiler,

also der Profiling-Aufhalt ist sehr gering.

Das Problem ist jetzt aber, dass wenn man quasi Python-Programme profilt,

dann sieht man natürlich jetzt gar nicht, welche Python-Funktionen wie viel Zeit verbrauchen,

sondern man sieht dann die ganze Zeit nur, dass halt irgendwelche Interpreter-Funktionen ausgeführt werden.

Und da gibt es jetzt eben dieses neue Feature, den PerfJit.

Und da ist die Idee, dass man so eine ganz, ganz kleine, ein paar wenige Maschinencode-Instruktionen lange Funktionen generiert zur Laufzeit.

Und für jede Python-Funktion eben genau eine so eine Funktion.

und das hat dann den Vorteil, dass Perf eben die ganzen

Python-Funktionen voneinander unterscheiden kann.

Wenn man eben nicht nur eine

interpretierige Python-Code-

Funktion dann sieht in Perf,

sondern man sieht dann eben diese

neu generierten Mini-Funktionen

und dann gibt es irgendwie so einen Rückübersetzungsschritt,

wo man dann eben sagen kann, okay,

diese neue, neu generierte

Assembly-Funktion an Adresse sowieso,

die entspricht eben der Python-Funktion

f,

wie auch immer und so kann man dann

eben mit Perf sehen, in welcher

Python-Funktion man lange Zeit verbraucht

hat.

Das hört sich nach einem sehr umständlichen Weg

an. Es ist erstaunlich

umständlich, aber Profiling ist auch echt

einfach ultra kompliziert.

Ja, gut, klar.

Also es gibt ja

irgendwie so

eine große Sammlung an Profilern für Python

und für andere Sprachen, aber

C-Profile hat halt einfach einen riesen Overhead.

Dann gibt es verschiedene Sampling-Profiler für Python.

Wie heißt dieser? PySpy

oder so, der funktioniert, glaube ich, ziemlich gut.

Habt ihr den mal benutzt?

Nee, ich weiß gar nicht.

Ich hab wieder vergessen, was ich... Ich hab mal irgendwas benutzt.

Gibt es einen, der Hotspot heißt?

Aber Hotspot ist, glaube ich, eine UI

nur, oder? Wo da die Samples herkommen, weiß ich nicht so genau.

Ja, und dann

gibt es unseren quasi, WMProf,

der ist aber nicht mehr so richtig maintained. Also auf

Piper schon, aber auf Zip hat er nicht so richtig.

Ist auch Sampling. Also Sampling heißt halt,

dass man quasi nicht jeden Funktionsaufruf

mitschreibt, was halt sehr, sehr hohen Overhead hat,

sondern einfach nur so tausendmal pro

Sekunde halt guckt, welche Funktionen gerade auf dem Stack sind

und dann sagt, so statistisch gesehen

sind das die Funktionen halt, die dann viel

Zeit brauchen.

Und Perf ist halt auch so einer und der

Vorteil von diesem Sampling-Ansatz ist, dass man den

Profiling-Overhead eben beliebig klein

machen kann. Man kann halt die Anzahl der Samples immer

kleiner machen und wenn es dann nur noch 10 Samples

sind, dann ist es halt quasi

genauso schnell, wie es vorher auch war.

Man hat aber auch schlechtere Informationen

dann sozusagen. Also man kann dann quasi

die Abwägung zwischen Genauigkeit

der Informationen, die man hat und Overhead

beliebig ausbalancieren.

Und Perf funktioniert halt sehr gut,

wenn man da gute Informationen darüber kriegt,

was auf dem C-Level

funktioniert. Aber die

Informationen, welche Python-Funktion da jetzt gerade involviert ist,

die geht halt verloren. Und die kann man dann eben wieder

zurückkriegen mit diesem neuen

Perf-Integration-Feature,

das jetzt in 3.13 released wurde.

Aber ist auf jeden Fall frickelig.

Also ich glaube, auf Mac ist es ja auch

total schwierig, weil man

braucht halt so ausführbare Blöcke von

Maschinencode und

Apple hat da halt auch einiges an Security-Featuren.

Man muss dann quasi

sicherstellen, dass man so einen Code-Block eben

so hin und her

wechselt zwischen, ich kann den Code-Block

schreiben und ich kann den ausführen. Also man kann ihn nie gleichzeitig

schreibbar und ausführbar

haben, um eben so

Security-Exploits unwahrscheinlicher zu machen.

Und bis man das ganz genau

richtig hingekriegt hat,

das ist tricky. Wobei Perf ist eigentlich nur ein Linux-Projekt.

Insofern habe ich, glaube ich, gerade Quatsch gesagt.

Achso, das ist genug.

Ja, ich will,

mit MacOS, ich glaube, der letzte Copy-By-

Episode war auch irgendwie

drin, dass der Memory-Profiler

Memory, den Pablo

gerade aufgeschrieben hat, der

hat auf MacOS nicht funktioniert, weil

irgendwie

sie die

Maloc-Funktion irgendwie, also nicht die

Unbekannt haben.

Von einer Mac-Version

zur nächsten.

Kann man auch schon mal machen.

Warum nicht?

Ja, ich finde es cool, dass es Leute gibt, die sich dann wirklich

mit den Linkern auf allen Plattformen rumschlagen,

um dieses Problem zu lösen.

Ja.

Ja, ja, Profiling, tja.

Das ist...

Wenn das so low-level ist, sinkt dann eigentlich der Tierassistent hier null?

Sorry.

Couldn't resist.

Es ist interessant.

Aber was ist denn das nächste Thema

auf unserer Liste?

Ja, na gut.

Dann, was jetzt auch drin ist,

das wurde auch viel diskutiert,

ist halt, ja es nennt sich jetzt Free Threading

früher, No-Gill,

dass man halt optional

den Gill ausschalten

kann, ist auch eine, muss man

Compiler-Flex setzen und dann neu

kompilieren oder halt

sich entsprechendes Binary halt via

was auch immer, wie man halt so Python

installiert, halt das damit

installieren und dann kann man das benutzen.

Tja.

Was macht das denn überhaupt, der G?

Oh.

Ja, es sorgt eigentlich im Grunde dafür,

dass halt

der,

dass immer nur,

dass Python immer nur

auf einer CPU läuft,

wenn ich das jetzt mal ganz

Aber das ist ja noch eine Auswirkung,

das ist ja nicht das, was der macht.

Nee, ich glaube, das ist tatsächlich das, was

Also. Und es stimmt auch nicht.

Es kann auf vielen CPUs laufen,

nur halt immer nur auf einer gleichzeitig.

Ja, immer nur auf einer gleichzeitig, genau, das meinte ich.

Ja, ja, genau.

Aber das ist ja nur eine Auswirkung, das ist ja nicht der Grund, warum man das macht.

Nee, der Grund, warum man das macht, ist, dass halt

viele Operationen, ja, gerade was

Memory Management angeht, halt

man dadurch halt

nicht, da muss man halt nicht locken,

was man ansonsten halt müsste, weil wenn man

den Reference-Counter von irgendeiner

Datenstruktur erhöht.

Also ganz allgemein, die ganzen Datenstrukturen

sind halt erstmal nicht Thread-safe.

Und das bedeutet, dass wenn man die

von mehreren Threads aus benutzt,

dass die dann kaputt gehen können.

Insbesondere das Reference-Counter. Um das zu verhindern,

müsste man halt locken und wenn man lockt, dann wird alles

so langsam, dass

man keinen Vorteil mehr davon hat, dass man mehr

CPUs hat. Also ich glaube,

die ersten Versuche,

das Projekt hieß

irgendwie Gilectomy oder so.

Es gibt noch ein älteres.

Also so alle paar Jahre kommt mal jemand

und schaut Versuch aus.

Doch, bei 1.1 wieder nicht genau aufgepasst.

Ja, genau. Also es war

wirklich so 1.6 oder irgendwie so was ganz frühes, wo das

dann...

Kann gut sein. Aber da war das auch schon...

An den Versuch erinnere ich mich noch und da war es

halt so, dass wenn man das einfach nur versucht hat

zu locken und auch nicht irgendwie

was Kompliziertes gemacht hat, sondern einfach mal

probiert hat, es nicht ganz so langsam hinzukriegen,

dann war irgendwie

der Performance

war so Faktor 40

weniger

und ja,

dann hat man es auch

Single Threat Performance,

genau.

Und dann hat man es runtergekriegt

mit Tricks auf 20,

Faktor 20

irgendwie schlechter,

aber das ist halt immer weit,

noch sehr, sehr weit entfernt

von irgendwie,

man will das verwenden,

weil wenn das so eine Auswirkung hat,

dann lohnt sich das eher nicht.

Aber was macht man denn dann

mit den ganzen Objekten,

die da irgendwo rumliegen?

Wie rückt man die denn dann weg?

Wie meinst du?

Wenn man nicht mehr braucht.

Du meinst Garbage Collector?

Ja. Gut, das ist nochmal ein anderes...

Der weiß ich gar nicht, ob der irgendwie...

Aber der Reference Count ist ja dafür da, oder?

Dass man das wieder wegräumen kann, wenn es auf 0 fällt.

Also an dem Garbage Collector hatten die quasi bei diesen

Gilectomy und so Versuchen auch nichts geändert.

Was sie gemacht haben, ist jedem Objekt einen Log zu geben

und immer wenn ein Threat mit dem

Objekt eben interagieren will, insbesondere

wenn eben der Reference Count

verändert wird, musst du halt dir erstmal

das Log holen für das Objekt.

Und weil halt

ständig, um irgendeine Operation

mit dem Objekt machen zu können, du halt ständig an dem

Reference-Count rumoperierst,

ja, musst du halt ständig

auf das Log warten und das hat

halt die bisherigen Versuche,

den Guild zu entfernen, einfach sehr, sehr teuer gemacht.

Also die

Single-Thread-Performance

eben komplett ruiniert.

Und jetzt kann es doch

dann eigentlich sein, dass so ein Objekt dann einfach

weggeräumt wird, obwohl es noch gebraucht wird?

Jetzt wird es super kompliziert.

Also wir haben

jetzt, genau, es gibt den Guild, der Guild verhindert, dass

mehr als ein Thread-Python-Core ausführen kann.

Also gleichzeitig auf einem Core.

Jetzt kommt eben der nächste Versuch

und das ist von Sam Gross bei Mitha

über viele Jahre lang eben probiert worden

und der hat einige sehr clevere neue Ideen da reingebracht,

um zu versuchen eben die Verlangsamung

für Single-Thread-Performance, soweit es geht, zu minimieren.

Und da gibt es eben so eine ganze Bandbreite an Optimierungen,

womit er dann eben versucht,

genau diese Probleme in den Griff zu kriegen.

Und eine davon ist eben die Beobachtung,

dass die allermeisten Objekte,

die werden halt trotzdem nur von einem Thread benutzt.

Also wenn ich halt eine Funktion habe,

die irgendwie eine Liste erstellt

und da was rein appendet und so weiter.

Selbst wenn auf ganz vielen anderen Threads

halt noch Sachen laufen,

kommt halt kein anderer Thread

erstmal standardmäßig an diese Liste ran.

Das heißt, die erste Optimierung ist zu sagen, für die ganzen lokalen Objekte, die ich also nur von einem Thread überhaupt jemals anfasse, muss ich für das Updaten der Reference Counts eben nicht locken. Also das ist quasi so die wichtigste Optimierung.

genau, das heißt

Biased Reference Counting, weil quasi

dafür gesorgt wird, dass man eben

nicht geshared Objekte

die nur von einem Thread

eben erreichbar sind

dass man da eben das Locking quasi

sein lassen kann

jetzt gibt es aber nat eine ganze andere Klasse an Objekten die werden halt von ganz vielen Objekten von ganz vielen verschiedenen Threads angefasst also halt alles was die ganzen Build also

None,

die ganzen Typen und dafür gibt es dann

also wieder einen ganz anderen Ansatz und da ist nämlich die Idee,

dass man da halt sagt,

diese Objekte, die können eh nicht sterben,

also sowas wie None.

Warum nicht wegräumen?

Dann gibt es halt einfach immer

und das gilt halt

für ganz, ganz viele andere Arten von Objekten auch,

die meisten Typen gibt es halt immer,

Und die werden dann so unsterblich gemacht.

Ist das dann ein Singleton?

Also, nein, das ist auch ein Singleton, ja.

Aber das ist nicht das einzige Kriterium.

Man kann sich schon noch vorstellen, dass es Singletons gibt,

die halt vielleicht auch sterben könnten.

Also, die man vielleicht wegräumen will.

Aber es gibt, also die ganzen eingebauten Sachen,

die werden einfach nie, also die werden halt nie gar nicht collected.

Und deswegen kann man da eben auch sagen,

da kriegt jetzt der Reference-Count irgendwie so einen speziellen Flag.

und dann erhöht und senkt man den Reference-Count eben auch nicht.

Und dann muss man die auch wieder nicht locken.

Und dann gibt es noch den dritten Ansatz

und das ist das sogenannte Deferred Reference-Counting

und da verstehe ich die ganzen Details auch nicht komplett.

Aber da ist eben die Idee,

dass man eben das Erhöhen und Senken des Reference-Counts

nicht mehr die ganze Zeit up-to-date macht,

um eben zu ver...

Also da geht es um Objekte, die so dazwischen sind,

also die von mehr als einem Thread erreicht werden können.

Also man erhöht, aber man reduziert das nicht oder beides nicht?

Ich glaube beides nicht.

Also und dann, das sorgt aber dafür,

dass wenn der Reference-Count null wird,

dann kann man die auch nicht sofort einsammeln,

sondern da muss man eben warten

und dann warten, bis alle Threads

zu irgendeinem wohl definierten Punkt kommen

und dann kann man schauen,

ob es nicht noch irgendwelche References

in den Stackframes gibt oder so,

die dann noch dazugezählt werden müssen,

deswegen eben Deferred.

und nur wenn man da dann eben überall nachgeschaut hat

und feststellt, oh okay, das Objekt,

das ist jetzt wirklich auch von keinem Frame-Objekt

mehr erreichbar, dann kann ich das wirklich wegräumen.

Und das hat auch komplizierte

Interaktionen mit dem

Memory Allocator,

da wechselt nämlich

die Free-Threading-Version auch zu

Mimalog, das ist so ein von Microsoft

geschriebener C-Memory

Allocator, der eben auch besonders gut mit

Multi-Threading

interagiert und da wird

auf eine für mich noch nicht ganz

verständliche Art und Weise eben mit

besonderen Meme-Log-Features dann

erreicht, dass genau das Richtige

passiert.

Dass genau das Richtige passiert, das ist immer toll.

Ja, das ist auch.

Ja, aber das hört sich jetzt so ein bisschen an wie

so Eventual Consistency für den

Reference-Counter. Ja, ich glaube, das ist genau.

Weil im Endeffekt

ist die Zahl, die in dem Reference-Counter

da drin steht ja auch, nur dann wichtig,

wenn es eine Null ist.

Also jetzt,

Vorbemerkung ist, das gilt

alles nur für Objekte, die eben von mehr als einem Thread

erreicht werden können. Ja, okay, klar.

Genau, aber für die hast du absolut recht,

da ist eben da eine Zahl

drin, die nicht unbedingt wirklich

alle References von allen Threads

dann

widerspiegelt und um das

Objekt dann wirklich wegräumen zu können,

muss man halt nochmal nachschauen, ob das

wirklich alles so gestimmt hat.

Genau, aber für mich der Knackpunkt, an dem das überhaupt funktionieren kann, ist, dass die Zahl, die tatsächlich in dem Reference Count drinsteht, die meiste Zeit ja uninteressant ist. Solange die Zahl größer als 0 ist, ist der exakte Wert nicht wichtig.

Ja, absolut.

Sondern es wird erst dann wichtig, wenn der exakte Wert 0 erreicht.

Also so ein bisschen so, als wenn du die Box aufmachst und guckst, ob die Katze noch lebt.

Ja, aber du musst es ja nur aufmachen, wenn du es wirklich wissen willst. Solange es dich nicht interessiert, ob die Katze noch lebt, kannst du außen den Schalter drücken oder nicht drücken, so viel du willst. Und ich glaube, das ist für mich in meinem Kopf so ein bisschen der Kern an der Sache, warum das überhaupt funktionieren kann.

Weil wir nur zu sehr wenigen Zeitpunkten wirklich den exakten Wert wissen müssen, weil wir nur zu wenigen Zeitpunkten wirklich draufschauen müssen und sagen müssen, okay, jetzt muss ich wissen, ob die Zahl wirklich null ist oder nicht.

Ich glaube, Eventual Consistency ist auf jeden Fall ein super Gedankenmodell, weil Eventual Consistency wird ja auch quasi aus den gleichen Gründen eingeführt. Also natürlich ist es besser, wenn meine Information halt die ganze Zeit konsistent ist. Aber das hat halt im Datenbankbereich dann auch entsprechende Nachteile, Performance-Nachteile.

Ja, und gerade in verteilten Datenbanken.

Genau. Und quasi aus den gleichen Gründen,

für mich halt quasi im viel, also auf einem ganz anderen Maßstab

natürlich, aber werden die Deferred Reference Counts verwendet.

Ja, cool. Super coole Sache.

Ja, genau. Aber es ist halt wie gesagt auch bisher noch

experimentell und standardmäßig nicht eingebaut.

Da gibt es auch noch so ein paar Nachteile.

Die Single Thread Performance ist auch quasi

in der Free Threading Version schlechter im Moment.

Ich glaube vor allem weil sie im Moment eben noch dieses Bytecode wo wir vorhin in der JIT dr gesprochen haben noch abschalten m Eben aus dem Grund dass wenn ich quasi mehr als einen Thread habe der die gleiche

Python-Version ausführt und alle wollen

jetzt den Bytecode umschreiben, dann habe ich

da eben auch wieder quasi

Mutationen

derselben Datenstruktur von einem Thread

und da will ich das nicht immer locken und

deswegen haben sie das bisher einfach abgeschaltet

in der Free-Threading-Version

und das sorgt dann eben für, weiß ich nicht,

10%, 20% Verschlechterung

der Single Threading Performance.

Oder

es gibt eben, ein anderes Problem

ist, es gibt eben einfach ganz, ganz viel

Python-Code, der so in der Welt ist,

in irgendwelchen Bibliotheken, der einfach nicht Thread-Safe ist.

Bisher konnte man sich halt

so ein bisschen immer so

durchmogeln mit der Tatsache, dass

meistens ist man halt vom Girl geschützt

und so viel

Multithreaded Python-Code gibt es halt auch oft nicht

und deswegen

finden wir jetzt wahrscheinlich die nächsten

zehn Jahre Locking-Bugs

in allen PyPI-Bibliotheken.

Und

für die C-Extensions gilt das natürlich erst recht.

Ja, aber die C-Extensions

hatten ja vorher schon die Möglichkeit,

den GIL freizugeben. Also NumPy

zum Beispiel.

Ja, sobald ich quasi was mache, was dann

wirklich weit

weg von jedem Python-Objekt.

Genau, was aus dem Python-Memory-Management

rausgeht.

Ja, gut, okay.

Also die große

Matrix-Multiplikation, die NumPy macht,

die hat halt mit Python dann nichts mehr zu tun.

Und die konnte halt dann auch schon

auf dem extra Core dann

den Lüfter heiß

laufen lassen.

Ja, das sind die wenigsten Operationen, das ist mir schon klar.

Die prinzipielle Möglichkeit gab es

vorher schon.

Wenn ich mein eigenes Memory-Management mache,

bin ich nicht auf den Gelenk.

Ja, aber da hat man sich dann ja auch wahrscheinlich

schon Gedanken drüber gemacht, wie man das dann tut,

ohne dass es kaputt geht. Oder wenn man

es falsch gemacht hätte, wäre es schon aufgefallen.

Aber ganz viel von dem, wo man sich keine Gedanken

gemacht hat, das wird dann jetzt wahrscheinlich irgendwann

auffallen, dass das nicht ganz richtig war.

Das ist auch in der Standardbibliothek. Da gibt es einfach ganz viele

solche Stellen. Wir hatten heute so ein

Bug-Report. Also

es gibt das Line-Cache-Modul.

Das kennt keiner, weil man das quasi

selber nie benutzt. Das ist quasi dafür da, dass wenn

ich Tracebacks kriege,

dass die Source-Code-Zeilen halt quasi

aus den Python-Dateien geladen werden

zum Anzeigen. Und das wird gecached, damit ich nicht

jedes Mal die Dateien eröffnen muss.

Und wenn ich jetzt aber quasi Python-Code

zu Laufzeit erzeuge mit exec oder so,

dann kann ich quasi auch da dann

in den Line-Cache so Sachen reinschreiben

und die will ich aber vielleicht auch

wieder löschen, damit eben der

Cache nicht mehr und mehr Speicher verwendet.

Und dann hatten wir einen Bug von SymPy oder so,

die schreiben da eben so Sachen in den Line-Cache

rein und löschen die dann auch wieder und dann

stellt sich halt raus, dass der Line-Cache nicht thread-safe ist.

Also wenn ich das quasi von mehreren

Threads mache, dann kriege ich halt irgendwelche

komischen Exceptions von irgendwelchen

internen Line-Cache-Funktionen, von denen

ich noch nie gehört habe.

Und ja, also wenn

klar, das ist jetzt alles schon

extra ultra speziell, aber

so Stellen wird es halt in der Standardbibliothek

auch noch an anderen Plätzen

geben, dass man halt dann feststellt, okay, es gibt

hier Python-Code. Da hat

halt noch nie jemand drüber nachgedacht, was passiert eigentlich,

wenn ich das auf vier Threads gleichzeitig ausführe.

Ja, und eigentlich sollte man sich ja

da auch keine Gedanken, beziehungsweise es ist ja der

Ansatz, dass man sich keine Gedanken

drüber machen soll. Viele andere Sprachen lösen

das Problem halt auf eine andere Art und Weise, indem

sie sagen, man muss jetzt halt selber explizit drüber nachdenken.

Also man wird da...

Das ist ja der Ansatz, dass man es in Python nicht machen muss.

Man wird in Python schon drüber nachdenken müssen. Also wenn du halt so was hast,

wie du hast irgendein globales Dictionary

und das wird jetzt von zwei Threads mutiert und ich habe

aber in beiden eine Iteration

darüber, dann sind halt

wahrscheinlich die Invarianten der Schleife kaputt. Egal,

ob die Datenstruktur jetzt...

Also klar, die Datenstruktur soll nicht kaputt gehen,

aber ich kann ja trotzdem dann plötzlich den Key verlieren,

den ich erwarte, dass er noch in der Dictionary drin ist.

Ja, auch diese ganzen Probleme,

die bei Multithreaded Programming auftreten,

also allein, wenn ich irgendeine Variable habe,

die ich inkrementieren möchte,

dann muss ich ja schon irgendwie einen Mechanismus haben,

der Multithreading ermöglicht.

Aber das ist ja noch mal eine ganz andere Ebene.

Ja, klar.

Und solche Bugs haben wir definitiv auch schon gesehen.

sowas wie, ja die sind ja auch leicht

also ich meine, die hat man ja sofort

ja, also sowas wie self.counter

plus gleich 1, das ist halt nicht

Atomic in

der Free-Threading-Version, ja also

wenn ich da mehrere Threads hab, die das machen

dann, ja

dann können halt komische Sachen passieren

Aber da gab's auch früher schon so

gab's auch früher schon so Stolperfallen

wo manche Sachen in Python Atomic

aussahen und dann aber irgendwie auch nicht

Genau, also viele von diesen Bugs

die sind quasi bisher auch schon, das sind jetzt quasi keine Bugs, die nur in Free Threading wirklich vorhanden sind.

Das sind quasi latente Bugs die es schon immer gibt die auch quasi in der ganz normalen GIL von Python Bugs sind und Crashes verursachen k

Nur bisher waren die quasi

einfach viel unwahrscheinlicher, dass man die wirklich

dann auch trifft, diese

Bugs. Aber

dadurch, dass jetzt eben mehr Leute versuchen

werden, mit Multithreading

in der Free-Threading-Version

Programme dann schneller laufen zu lassen,

wird die Wahrscheinlichkeit,

dass man diese Bugs halt dann auch quasi

in echt sieht, die geht halt hoch.

Das heißt, also ja,

ich meine das ernst. Wir werden jetzt wahrscheinlich

zehn Jahre lang Bugs in allen Bibliotheken finden, die

irgendwas mit Threading zu tun haben.

Ja, und es gibt ja auch keine so richtigen

atomaren Operationen in Python.

Oder keine, denen das ansieht,

dass sie atomar sind.

Das macht das Reasoning so ein bisschen

schwierig. Absolut. Und das ist ja auch

einer der großen Schwierigkeiten des

Free-Threading-Projekts.

Dass es sich quasi bei

allen eingebauten Containern, so wie Listen und

Dictionaries und so weiter, jetzt überlegen

müssen, welche der Methoden wollen

wir eigentlich als atomar

verstanden haben und welche

halt dann auch nicht.

Also sowas wie...

Das erkennt man nicht. Ich glaube, das

wird dann dokumentiert.

Ja gut, klar.

Also das muss man nachlesen, aber ja.

Aber die Entwickler, die quasi

Freethreading implementieren, die müssen sich eben bei

jeder Methode dann Gedanken darüber machen.

Also ListAppend ist halt Atomic,

aber ListExtend bin ich mir schon mal nicht mehr so

sicher. Wenn das, was ich dann

als Argument von Xtern reinreiche,

wenn das selber ein Iterator ist und da halt

dann irgendwie mit einem Generator irgendwie Python-Code

ausgeführt wird, dann kann das halt auch eine Weile dauern, bis ich da durch bin.

Und in der Zwischenzeit können natürlich

andere Threads dann laufen und

irgendwelchen Quatsch produzieren.

Ja, und jetzt machen wir uns auf einmal

Gedanken über Transaktionen und über

Transaktionsmanagement und das ist dann schon auf

Sprachebene was sehr Spezifisches.

Um die Frage zu beantworten, was für einen

atomaren Counter ich benutzen kann, da gibt es

irgendwie Iter-Tools

Punkt Counter oder so heißt es, glaube ich.

Und das gilt wirklich als,

also das ist die

Thread-Safe-Variante, um einen

atomaren Counter in Python zu haben.

Also hätte ich jetzt nicht

gewusst. Ich auch nicht,

aber wir hatten halt Bug-Reports, die gesagt haben,

self.x gleich 1 geht halt nicht.

Ja, genau.

Ich erinnere mich noch, das habe ich vor Jahren

mal diese Meinung

vertreten, dass das Global Interpreter

Log mich davor schützt, dass ich

x plus gleich 1 machen kann, so viel ich will.

Und dann haben wir

im Chaosdorf

an einem Abend das einfach mal ausprobiert

und es stellte sich als falsch

raus, die Annahme, weil man eben sehr schnell

falsche Zahlen rauskriegen kann.

Darf ich kurz fragen? Ja.

Das ist selbstverständlich.

Also das komplettes, wie heißt das?

Insider Baseball, also

das hat sich geändert in den letzten

Python-Versionen, also in den letzten

C-Python-Versionen. Du hast absolut recht,

dass quasi, also ursprünglich

war die Regel, ein

Bytecode ist atomar

und aber theoretisch kann ich

nach jedem Bytecode eben

einen Threadswitch haben und

sowas wie das erwähnte

Beispiel, self.x plus gleich 1,

das sind eben mehrere Bytecodes, das heißt, da kann ich dazwischen

einen Threadswitch haben

und entsprechend ist das nicht atomar.

In einer der letzten Versionen,

ich weiß nicht, 3.12

vielleicht oder so, haben sie quasi

in CPython die

Bytecodes, wo man Threadswitch

Thread-Switches machen kann,

also in der regulären GIL-Version,

stark reduziert.

Und es gibt jetzt eben nur noch ganz, ganz

wenige Bytecodes, wo wirklich dann

Switches stattfinden können.

Das sorgt dafür, dass die

quasi beobachtbare

Atomarität zunimmt.

Das heißt, plötzlich in 3.12

war dieses Counter-Beispiel atomar.

Und das ist natürlich total schlecht,

weil, wenn man

die Community darauf vorbereiten will, dass jetzt

irgendwann mal der Gild entfernt wird und

man quasi mit

Thread-Switches an viel mehr Stellen rechnen

muss, ist es halt schlecht,

wenn man in der Version davor

dafür sorgt, dass

viel weniger Thread-Switches an viel

vorhersagbareren Stellen, nämlich nur am Ende von der

Schleife oder sowas stattfinden kann.

Also das finde ich

so, also ich meine klar,

dieses Reduzieren der Thread-Switches,

das erhöht halt wieder die Single-Threading-Performance,

das war der Grund, warum sie das gemacht haben,

Aber ich finde es halt

unstrategisch.

Also ich glaube, wenn du in Teil 12 das mit dem Kauter

nochmal ausprobieren würdest, dann würdest du, das wäre es quasi

nicht mehr beobachtbar.

Dann mache ich das jetzt mal nicht.

Mach lieber gleich in der

No-Gill-Version.

Ja gut, aber damit

müsste es ja gehen.

Damit müsstest du es kaputt kriegen.

Ja, würde ich hoffen. Ja gut,

kaputt kriegen.

Ja, also.

Ich habe jetzt leider keine

No-Gill-Version hier kompiliert, deshalb

muss ich leider... Aber ich glaube, da gibt es auch zum Beispiel so,

also es gibt Packages davon. Ja, ja.

Also bei UV habe ich jetzt gesehen,

gibt es das auf jeden Fall. Ja, bei UV

beißen in Style. Genau. Und in

In...

In Panf weiß ich nicht,

aber in Ubuntu, in dem

Dead Snake PPA gibt's

es auch.

Ja, aber ich meine,

also ehrlich gesagt,

ich weiß nicht, habt ihr jetzt alle schon

einen Anwendungsfall, wo ihr unbedingt das

mal ausprobieren wollt, ob dann nicht alles

viel schneller wird? Weil ehrlich gesagt,

ich hab das

dann nicht so wahnsinnig viele Dinge.

Ja, aber es liegt halt vor allem

auch daran, dass wir daran jetzt gewöhnt sind,

es nicht zu brauchen. Gut, das kann natürlich sein.

Also ich glaube

schon, dass es dann einiges gibt,

wo das halt schon irgendwie auch

klar, man muss dann sich irgendwie

umgewöhnen und vielleicht gibt es auch ein paar schöne

Bibliotheken, die das halt alles ein bisschen weniger

gefährlich machen, dass man so ein paar

schöne Abstraktionen auf den Platz hat.

Aber ich denke

schon, dass wir an einen Punkt kommen können, wo

man dann eben sagen kann,

ja, also früher

hätten wir vielleicht Multiprocessing genommen und es wäre

nervig und

also frickelig gewesen, das dann gut

hinzukriegen und jetzt nehmen wir halt Threads und

es funktioniert gut.

Ja, das ist

halt auch mit Threads programmieren

ist halt auch was

gefährliches. Da gibt es ja, also ich meine,

selbst wenn diese Operationen alle atomar

sind und selbst wenn das so ist, dann gibt es ja immer noch

diese ganzen Probleme

und Deadlocks und Race Conditions

und Cloud-Anzweigs und das

ist einfach eine schwierige Sache.

Ich habe kurz, ich habe eben nachgeguckt, es gibt

in PyEnv gibt es eine 3.13.0

Version und es gibt eine 3.13.0

T-Version.

Und das werden die beiden unterschiedlichen

sein.

Gut, dann muss ich jetzt wo mal installieren.

Genau, und dann muss man ein altes Skript vom Chaos

drauf finden und dann...

Es war

nicht so ein beeindruckendes Testharnes.

Es war einfach nur zwei Threads,

die die Variable gleichzeitig erhöht haben.

Also das kann man relativ leicht

wieder rekonstruieren.

Ja, ich sehe das auch so.

Und ich habe so sehr gemischte Gefühle, was das Free-Threading angeht. Einerseits ist es halt cool, weil endlich diese endlose Diskussion aufhört auf der einen Seite und weil halt auch wirklich jemand mal Geld in die Hand genommen hat und das richtig gut macht.

Also richtig gut, klar, da kann man dann auch Details kritisieren,

aber die Tatsache, dass jetzt eben irgendwie einige Leute von Meta

dafür bezahlt werden, das halt wirklich zu machen

und auch quasi den Aufwand betreiben, das in CPython reinzukriegen,

was ja auch wirklich immer viele Diskussionen

und viel Überzeugungsarbeit und viel Debugging

und sehr, sehr viel Aufwand sind dafür nötig.

Und ich finde es erst mal gut, dass das halt jetzt passiert

und dass quasi auch die Community mitgenommen wird

und irgendwie verschiedene,

also es gibt ja jetzt wirklich auch schon einige an Bibliotheken,

die jetzt mitziehen und gucken,

dass sie halt auch Free-Threading-Versionen

dann Binares auf PyPI releasen und so weiter.

Und das ist schon wirklich gut.

Klar, auf der anderen Seite sehe ich das,

ich denke wirklich, das wird eine Riesenumstellung

und das wird schon auch, was die Bugs angeht

und was die Eingewöhnungszeit angeht

und sowohl in den Bibliotheken als auch in der Sprache selbst.

Ich habe mal einen Vortrag gehört von einem der Sun JVM JIT-Entwickler,

der auch in einem ganzen Laufzeitsystem

und dem Multithreaded Garbage Parallel Garbage Collector

und so gearbeitet hat.

Und der meinte so, im Garbage Collector

findet man halt zehn Jahre lang Multithreading-Bugs.

Und die werden halt immer schwieriger, die zu finden.

und ich weiß halt nicht so genau,

ob wir darauf so richtig

gefasst sind.

Ja gut, hat

ein bisschen Zeit noch populärer zu werden

und dann steigt die Wahrscheinlichkeit, dass man die Bugs findet.

Das ist doch gut. Dann kann man auch schwierige Bugs

finden.

Ist jetzt schon auf dem TIOB-Index ganz oben.

Also ich sehe es so

ein bisschen, hat ein bisschen eine andere Perspektive.

Ich glaube, dass dieses,

die Möglichkeit Multithreading zu machen,

eröffnet eine ganz neue Klasse an

Programmen, die man mit Python

bisher nicht schreiben konnte.

Spiele wolltest du bauen?

Ja, Spiele sind eine, ja, aber

da hast du dann immer noch die Performance-Differenz.

Aber gerade

so verteilte Anwendungen. Das, was

Meta macht, das, was halt die

großen

Anbieter machen.

Wenn man sich mal diese Erlang-Sachen anguckt

aus den 80ern, die einfach

viele Dinge gleichzeitig über einen

Computer laufen lassen müssen, weil es nicht anders

geht, da sieht man diese Klasse von

Anwendungen. Das ist die

eine Seite. Die andere Seite ist halt, dass die

wenigsten von uns diese Klasse von

Anwendungen schreiben.

So ein bisschen aus Henne und Ei

Problem heraus, weil wenn wir

diese Klasse von Anwendungen schreiben müssten,

dann müssten wir zwangsweise

bisher eine andere Sprache als Python

verwendet haben, weil es in Python eben nicht ging.

Und deshalb sind wir Python nicht gew diese Sorte Programme zu schreiben und auch nicht gew diese Sorte Probleme zu l

Und das bedingt sich so ein bisschen selber. Das ist so ein Catch-22. Du kannst es erst lösen, wenn du es gelöst hast und um es zu lösen, musst du es erst gelöst haben.

Also ich glaube wirklich, dass das nicht so super häufig ist. Also ein Fall, den ich halt, ich habe dann irgendwann mal in den Pepp auch geguckt, wo begründet wird, warum will man das eigentlich haben.

und da war zum Beispiel ein Beispiel, was ich dann auch

einleuchtend fand, also es waren ein paar,

aber eins ist mir jetzt noch in Erinnerung,

die anderen nicht mehr.

Da war es halt so, dass da

irgendwie auch im Data Science Umfeld

Firmen gesagt haben, also wir haben ein Problem

und zwar haben wir hier irgendwie dicke Maschinen

mit irgendwie jeder Menge GPUs drin

und jetzt wollen wir die GPUs

mit Bildern füttern oder sonst irgendwas

und klar,

irgendwie I.O. ist nicht so das Problem,

da haben wir kein Problem mit dem GIL,

aber wir müssen die jetzt auch noch

so ein bisschen transformieren. Wir müssen da irgendwie

so ein bisschen das irgendwie mal

so drehen oder manchmal

in Batches organisieren und

keine Ahnung. Und das machen wir halt in Python.

Und wir müssen das schnell genug

machen können, um halt die ganzen GPUs

ständig mit Daten versorgen zu können. Die Dinger sind

sauteuer. Wenn wir da nur die Hälfte

der GPUs verwenden können, dann lohnt sich das alles

nicht mehr. Und jetzt

haben wir ein Problem mit dem Gil, weil

wir kriegen das nicht schnell genug,

wir kriegen die GPUs nicht schnell genug

mit den Daten gefüttert. Und

eigentlich haben wir fast keine Alternative, als

eine andere Programmiersprache zu nehmen, weil

was sollen wir machen? Wir können es

auch nicht auf Prozesse aufteilen oder das geht

auch alles nicht, weil da haben wir das gleiche Problem,

dass halt der Overhead uns

irgendwie, das zu

verteilen halt so

viel Performance wegfrisst, dass wir dann die GPUs wieder

nicht gefüttert kriegen. Also

ja, was sollen wir tun? Und da

dachte ich, okay, das ist wirklich ein Anwendungsfall.

Ja, da braucht man das wahrscheinlich.

Aber ansonsten

Ja genau, aber das ist eben diese

Klasse von Problemen, die ich

meinte vorhin, ja, und früher waren es halt

Telefonverteiler oder

Netzwerkinterfaces oder

keine Ahnung

Damit bist du mit AISING gespannt, ich weiß auch gar nicht, ob

Erlang irgendwie das auch

kann, ich bin mir gar nicht so sicher

also ich glaube, die haben dann ja, also wenn du halt

irgendwie so ein

Parallelismus können, meinst du? Ja, genau

die fahren auch eine Reihe von Prozessen hoch

und haben dann halt eine schlaue Art

irgendwie die miteinander kommunizieren können

Und intern machen die halt,

das kannst du mit Python ganz genauso machen.

Startest du auch mehrere Prozesse und machst

in jedem einzelnen Prozess

dann irgendwie Kuroutinen.

Das kann man,

ist nur nicht so üblich, aber könnte man

wahrscheinlich tun.

Also ich meine, ja, diese...

Async ist ja jetzt auch nicht gerade eine uralte

Entwicklung.

Diese Probleme gibt es ja auch schon lange.

Und Async ist ja auch noch eine Version, das zu lösen.

Auch mit Vor- und Nachteilen, muss man auch sagen.

Ja.

Ja, aber das ist auch…

dafür, wird es stabil genug,

ist die Single-Threading-Performance

akzeptabel schlechter

und ziehen

die ganzen Bibliotheken mit und im Moment

ist das Risiko halt

nicht so hoch. Also das

quasi der absolute Worst-Case, der passieren könnte, ist halt,

wir finden in zwei Jahren raus, niemand benutzt das,

das stürzt die ganze Zeit ab und

Sam Gross hat keine Lust mehr

und dann kann man es halt auch einmal wieder

weglassen.

Also was ich, würde ich

nicht von ausgehen, aber also die Möglichkeit

besteht halt sozusagen.

Ja und wahrscheinlich haben wir, also ich meine,

das hat mich jetzt auch quasi

so eine andere Geschichte, diese ASEM-Geschichte,

es hat eine gewisse Ähnlichkeit

in der Hinsicht, als dass auch das

halt ein tiefgreifender Eingriff war quasi

und sich erst so

über die Zeit entfaltet hat, was das

alles für Probleme bringt und wo es überall reingreift

und so und das ist, bis heute ist das

noch nicht so, sagen wir mal so, da ist immer noch

Potenzial, also es ist schon viel, viel besser geworden,

aber es ist immer noch so, dass da

noch, das ist noch nicht ganz komplett fertig alles

und das hat auch vor zehn Jahren oder so angefangen

und

ja, das hat

ganz schön lange,

ist schon ganz schön lange auf dem Weg und das

wird wahrscheinlich da auch so sein, ja.

Klar, auf jeden Fall, es ist auf jeden Fall ein langfristiges

Projekt, das ist jetzt nichts, was wir jetzt in

in einer Version mal irgendwie so

ein bisschen reinbasteln, dann ist das Problem gelöst.

Also, ja.

Ja, und selbst wenn das alles auf

technischer Ebene einwandfrei funktioniert,

dann ist halt Multithreaded Programming

immer noch einfach auch eine schwierige Sache.

Also die

Dining Philosophers, die kann man

sich gerne mal ansehen und versuchen da eine L zu schreiben das ist nicht so einfach einfach Klar Und ob es dann klappt Mal schauen ob Dominik fragt was das bedeutet

Ich warte nur darauf, dass du es erklärst.

Die Dining Philosophers

sind ein Gedankenexperiment,

wo du fünf

Menschen an einem Tisch sitzen hast und die

wollen Spaghetti essen und zum Spaghetti essen

braucht man zwei Gabeln.

Spaghetti ist Dining.

Ja, okay.

Ja, Teigabeln.

Very fine dining.

Und auch geteilte Gabeln.

Es gibt es nur in den nobelsten Restaurants.

Weil jeder von denen hat nur eine Gabel.

Also bei jedem Teller liegt eine,

zwischen zwei Tellern liegt immer eine Gabel.

Also ein Philosoph hat eine Gabel rechts von links

und eine links von sich.

Aber auf diese Gabel haben immer zwei Menschen Zugriff.

Und jetzt wollen die alle Spaghetti essen

und brauchen dafür zwei Gabeln.

offensichtlich können die nicht alle gleichzeitig

Spaghetti essen.

Weil es gibt nur fünf Gabeln, wenn jeder

zwei Gabeln braucht,

bräuchten sie zehn Gabeln. Es ist also

so ein Ressourcenproblem. Das viel

schlimmere Problem ist aber,

dass man da ganz einfach

diese ganzen Probleme

visualisieren kann,

die auftreten können, selbst wenn

dieses System auf einer technischen Ebene

einwandfrei funktioniert.

Du meinst zum Beispiel, die haben alle eine große Schüssel Spaghetti

und die haben gleichzeitig zwei Enden einer langen Spaghetti im Mund.

Das ist das Disney, die Disney-Variante.

Nee, die meine ich jetzt hier an der Stelle nicht, aber ja.

Zum Beispiel, wenn man ganz naiv sagt,

wenn ein Philosoph Spaghetti essen möchte,

dann greift er zuerst mit seiner rechten Hand nach einer Gabel

und dann mit der linken Hand nach einer Gabel.

Und wenn da eine Gabel nicht liegt,

dann wartet er halt in dem Zustand, in dem er gerade ist,

bis die Gabeln verfügt.

Also sitzen da irgendwelche Leute, die haben alle eine Gabel in der Hand

und warten darauf, dass sie eine zweite bekommen.

Genau, also im schlimmsten Fall greift jeder nach der rechten Gabel und wartet dann auf die linke Gabel, die aber durch den Philosoph zu seiner Linken schon belegt ist.

Und die warten dann alle aufeinander und müssen für immer an diesem Tisch sitzen und verhungern, vor dem vollen Teller.

Dreadlock quasi.

Und das ist ja eine extrem simple Situation, das ist ja eine extrem vereinfachte Sichtweise.

Du meinst, du musst mit deiner Idee und sagst, gib mir mal eine Gabel, bitte.

Ja, aber tatsächlich Threads,

die kommunizieren, sind ja auch was extrem

schwieriges, insbesondere wenn die gerade auf

einen Lock warten, weil üblicherweise,

wenn so ein Thread auf einen Lock wartet, kann er ja derweil nichts anderes machen.

Das ist dann blöd.

Hat den Mund schon voll. Genau, das ist blöd.

Und jetzt muss man eben anfangen,

wie kriegt man das in den Griff?

Wie kann man das im Allgemeinen

lösen, dass die keine Deadlocks machen?

Mehr Karten verteilen?

Ja, das wäre eine Möglichkeit, aber normalerweise ist das

schwierig. Also zum Beispiel in dem Modell

von Jochen einfach mehr GPUs einbauen.

Ist prinzipiell eine Lösung.

Ist nicht ganz billig.

Und es sind halt goldene Gabeln.

Mehr Gabeln geht nicht.

Ja, es ist einfach ein

Gedankenmodell, um nachzuweisen,

dass auf dieser ganz simplen Ebene

schon Probleme auftreten, die ungeheuer schwierig

zu lösen sind und ungeheuer schwierig

in ihrer Allgemeinheit zu lösen sind.

Und wenn du sagst, okay, dann habe ich eine Lösung gefunden

für fünf, was ist, wenn du da sechs Philosophen

sitzen hast oder tausend oder

nur zwei?

die deine Lösung dann immer macht.

Also schon allein die Tatsache, dass quasi

einer der schwierigsten Probleme bei verteilten

Systemen ein Counter ist,

das ist ja eigentlich auch schon

relativ lustig.

Eine Zahl hochzählen.

Genau, eine Zahl hochzählen.

Also global, konsistent und so, das ist wirklich

auch, schon das ist nicht so einfach.

Ja, kennt ihr das, wenn irgendwie an so einem Festival-Eingang

irgendwer stehen muss mit so einem Klicker,

wenn man draufdrückt, muss jemand reinrennen oder wenn man

an der anderen Hand jemanden rausrennt?

also ich bin ja auch so sicher, der verdrückt sich die ganze Zeit

irgendwann mal und weiß gar nicht so genau, wie viele

Leute sind eigentlich auf dem Gelände, sondern ich weiß wahrscheinlich relativ

ähnliches Problem. Wenn es so 18 Eingänge sind und dann

dann finden die dann raus, jetzt sind

gerade minus 10 Leute bei uns auf dem Festival.

Das ist doch der klassische