Python 3.13 ist da: Endlich ECHTES Multithreading!
Вставка
- Опубліковано 15 жов 2024
- Die neue Version gibts hier: python.org/
Zu Patreon:
www.patreon.co...
Zum Newsletter: the-morpheus.c...
Instagram: / themorpheustuts
Meine anderen Kanäle und Projekte: the-morpheus.de/
Selbst kostenlos Informatik lernen auf meiner Website: bootstrap.acad...
Discord:
the-morpheus.d...
Unterstützt mich - Danke!:
www.patreon.co...
www.paypal.me/...
Das wird dann ja eine schöne Herausforderung für die Python-Community, mit Race Conditions umgehen zu lernen :D
Und non-atomic Operationen, Deadlocks, Mutexe/Semaphoren... So viel "Spaß", den man sich bisher erspart hat.
@@Ph34rNoB33r Mutexe gibt es schon: mutex = Lock(); with mutex: critical_section()
Naja, passiert ja nur wenn man auch multi threaded arbeitet.
Webserver sind da eher die Zielgruppe, aber da muss man ja sowieso auf viele Faktoren achten, z.B. auf DoS durch zu viel verbrauchten Arbeitsspeicher und ob die Daten schon in der DB aktuell sind, oder ob man eher mit "eventuell konsistenten" Daten arbeitet
@@Kirides Ich tu mich ja immer schwer damit, "eventually consistent" zu übersetzen, das deutsche "eventuell" passt aber finde ich gar nicht. Das klingt wie "vielleicht ist es konsistent, vielleicht auch nicht", während das Englische den Zusatz hat "irgendwann wird es konsistent sein".
danke für die neue vorstellung, ich sehe das als gute entwicklung! als geograph/geoinformatiker wird das threading echt viel zeit bei den massen an daten/karten sparen :)
Finde ich super, habe schon Jahre darauf gewartet. Was mich noch interessieren würde : ist the t Version mit eingeschaltetem GIL gleich schnell wie die Version ganz ohne GIL? Müsste sie ja eigentlich, bis auf Bugs. Und ich nehme an, es ist auch nur das Risiko von Bugs, dass es noch zwei Binaries gibt? Von daher müsste es eigentlich relativ schnell in Richtung eines einzigen Binaries gehen, dass mit und ohne GIL laufen kann.
Also in Java ist ein i = i + 1 nicht atomar. Stimmt es, dass es in python nicht so ist?
Danke für das Video, hat mir sehr gefallen
Ich weiß ehrlich gesagt nicht ob ich es gut finde das GIL rausfliegen soll, es ist irgendwie schon charmant das das threathing damit so einfach ist
Gut focussiert das Video. Aber erwähnt hätte ich den JIT der auch in der Version kommt schon. 3.13 ist damit wrsl die heftigste Performanceoptimierung die Python erlebt hat. Da sind einige heilige Kühe geschlachtet und sehr heftige Hürden übersprungen worden.
Python 2->3 hat in der Praxis etwa 20 Jahre gebraucht, weil alle Libs angefasst werden mussten.
Die notwendigen Änderungen sind diesmal noch komplizierter. Bis das in der Fläche so angekommen ist, dass man GIL rausnehmen kann, haben wir 2050.
Ich mach seit 4 jahren data science mit Python und dachte ich wäre ganz fit in python. Aber ich habe absolut keine Ahnung wovon du sprichst 😅 ich glaube ich sollte meinen Job kündigen und irgendwas anderes machen. 🙈🙉
@@gemeinerwolfsfu4389 Wenn du numpy, scipy und so etwas nutzt, der C-Code nutzt teilweise schon Multithreading. Nur halt nicht alles, und nicht für den Python-Teil.
Haha, ist aber nicht schlimm. Ein data scientist muss glaube ich nicht unbedingt sich mit multi-threading und multi-processing auskennen. Ich glaube eher ein data engineer oder ML engineer, der deine Modelle in production deployed, sollte sich sorgen machen wie man das maximum an Leistung rausholt. Aber was du ganz easy machen kannst um z.B. die predictions eines Modells schneller zu machen ist eine parallel processing library wie "joblib" zu nutzen. Wenn ich ein Modell ausführe welches nicht alle CPU Kerne auslastet führe ich das immer mit joblib parallel aus und das kann alles entsprechend 10x oder mehr schneller machen (abhängig von deine CPU kerne und modell library). Auch für Experimente wo man viele Varianten eines Modells trainiert ist der Speedup hilfreich :) .
Dann ist noch viel zu lernen: ist doch perfekt ☺
@@st5er561 hahaha, danke leute für den Zuspruch:) ich arbeite eigentlich fast ausschließlich mit Pyspark auf Databricks, da werden die „Cluster“ soweit ich weiß bis auf ein bisschen Query optimization und repartitioning automatisiert ziemlich gut ausgelastet. Aber danke für den Tipp! :)
du kannst mutlithreading das ganz gut mit Rust lernen
gab es nicht letzte Woche eine Nachricht von Intel, dass man Hyperthreading aus den CPUs ausbauen wird?
gibt es hier einen Zusammenhang?
b) ultimaker cura wird wohl mit python programmiert. Dann dürfte die Berechnung von 3d Modellen schneller werden?
Zu den Multithreading-Anwendungen, ob pyQt dann schneller rennt? Momentan wird das im OpenGL-Modus durch die Single-Core Performance ausgebremst, frisst einen Kern und das war's. Ob was auch immer es damit macht parallelisierbar ist, ich weiß es nicht.
hatte auch ähnlichen Gedanken. Wird interessant ob Python vll doch noch mehr in die Anwendungsentwicklung reingehen wird...
In pyQt oder pySide übernimmt das Multithreading in Qt haupsächlich das "heavy lifting", oder sollte es. Und der Frontprozess mit User-Input Wartezeiten ist meist der langsamste. Das Neuzeichnen sollte aber auf einem anderen Prozessor laufen können. Wenn pyQt nur rein mit FFI-Calls arbeitet (Foreign Function Interface), ja dann lasse ich Qt keinen freien Lauf. Der GIL sollte damit nichts zu tun haben. Gibt es da keine 2 Prozesse?
@@stzi7691 Ich nutze eine pyQt-Anwendung, die spawnt anscheinend einen Prozess pro Webview.
Immer wenn das GUI im Webview eine neue HTML-Seite anzeigen soll geht genau ein Prozess in der Auslastung auf Maximum (der selbe Prozess macht auch eine leichte Auslastung auf der Grafikkarte). Wenn ich Rendering von OpenGL auf Direct3D umstelle, dann braucht der Prozess deutlich weniger CPU-Power, dann habe ich aber Grafikfehler. Kann also nicht nur Parsing/Layout vom HTML sein, die OpenGL-Implementierung macht irgendwie mehr auf der CPU, und das in nur einem Prozess, auf einem Kern.
Nun, es ist nicht so, dass Threads nur da sind, um sich gemeinsame Variablen zu teilen. Das ist eher die Ausnahme, wenn es um Ressourcen geht (Teilen eines Sockets, oder systemnäher eines GPIO-Pins). Der GIL ist eher die schlechteste Lösung von allen. Warum? Warum brauche ich Threads? Um leichtgewichtigere Prozesse zu haben, die das Programm selbst als Prozess erstellt, weil es mit dem Multiprocessing halt nun mal A**** langsam geht, einen zu starten. Wenn Du jetzt aber einen GIL hast, schaltest Du immer nur einen Thread ein + einem gigantischen Switch-Overhead, Cache-Loss (bei einem Controller), Pipe-Loss, usw. usf. Und es ist im Endeffekt nur Single-Threaded. Der einzige Fall, in dem das besser ist, ist wenn Du einen Thread hast, der lange Pausenzeiten hat (GUI, User-Input) . Dann hat man genügend Lücken, die man mit anderen Arbeiten füllen kann. Das hätte ich aber bei 2 Threads auf 2 CPUs nicht nötig, als reine Concurrency. Das verbietet mir aber der GIL. In den meisten Fällen kann ich dann auch Single-Threaded arbeiten, und bin schneller.
Ich nutze Python eher für lokale Tasks und Systemadministrator Themen, wo ich am Code häufiger Änderungen vornehme oder individuelle Anpassungen. Also keine Lust auf eine Kompilierung habe usw. PHP für Web Applikationen und Go für rechenintensive Multithreading Themen und Desktop Apps. Insoweit habe ich daran keinen wirklichen Bedarf und hoffe nur, dass Python nicht irgendwann zu unübersichtlich wird, dass man direkt Go für alles nutzt. Aber ich kann auch verstehen, dass sich eine Sprache weiterentwickelt.
Ein Thema ist mir bei Python 3.13 nun noch nicht ganz klar. Wäre das Multithreading unter Deaktivierung des GIL auf einen Kern beschränkt oder ginge dies auch kernübergreifend?
Erstmal: Super Video, genau das kann ich für große Modelle gebrauchen.
Ich habe noch Feedback: Rot und Grün sehen in den Grafiken für Farbenblinde gleich aus, matplotlib hat viele Farbskalen, die hier geeignet wären (oder manuell einfach nicht grün und rot in der gleichen Grafik verwenden). Alternativ kann ich auch das Programm Color Oracle (open source; für macOS, Windows und Linux) empfehlen, welches die Farbwiedergabe auf dem Bildschirm so anpasst, dass die Farben wie für Farbenblinde erscheinen. Deine Videos sind auch so schon gut, vielleicht ist hier ja aber eine Möglichkeit zum Feinschliff ohne viel Arbeitsaufwand.
Vielen Dank! Das ist wichtiges Feedback
Ich hoffe sehr, dass dann wie bei Java auch die collections threadsafe gemacht werden. Bestenfalls das verhalten der stdlib wie dict, list usw threadsafe gestalten.
Vermutung: Es wird eine threadsafe Implementierung geben, die nur zusammen mit free threading benutzt wird. Bzw. wird es eine nicht threading Implementierung der Locks und so geben die nichts tut.
Java hat gezeigt das diesdoof ist. Aber okay, python ist schon 100× langsamer , dann wird es dann halt 200x langsamer
Dieses Update von Python erinnert mich an Mojo und davon hab ich schon lange nichts neues gehört.🤔 Ein super Lvl up von Python.👍
8:20 bis 8:25 Was für ein bereich?
Vielleicht hilft es, um nicht alles Thread-safe machen zu müssen (es ist nicht alles gleich eine Resource), sich mal die Erlang BEAM anzuschauen. Die benutzt "Lightweight Prozesse" und verteilt auf die Kerne. Zwei Fliegen mit einer Klappe: Prozesse machen dauert nicht so lange, und ich brauche nicht unbedingt Locks. Ich glaube, die haben auch die Option mit gemeinsamen Speicherbereichen, wenn denn nötig. Der Python-Interpreter wäre dann aber umfangreicher.
Was ist der Vorteil von GIL statt Arbeiten mit einem Thread?
Es ist keine manuelle Synchronisierung nötig. Das spart overhead. Deswegen ist single-threaded im Test (siehe video) mit GIL schneller.
Ich habe einen anwendungsfall zur archivierung von Dateien mit zugehörigen Headern zur obligatorischen Indexierung. Bei momentaner Hardwareverfügbarkeit und strikt sequentieller Konfiguration würde der Vorgang ca 5 Jahre dauern. Bringt mir diese Neuerung daher irgendeinen Vorteil?
Ist dein Flaschenhals die CPU-Last oder die Plattengeschwindigkeit? ⇒ profile erstellen.
@@ArneBab Mache ich sobald möglich danke dir.
oder eventuell ein Wechsel zu einer hardware-näheren Sprache, der würde pro thread eine Verkürzung von ca. 80x beitragen. Unabhängig von multi-threading.
@@julians.2597 Laut dem Benchmarksgame ist es eher Faktor 30 - bzw. Faktor 10 für die Sprachen mit Java-ähnlicher Leistung.
@@julians.2597 Die Geschäftslogik der Anforderung ist nicht allzu kompliziert. Was schwebt dir da konkret vor? Ein Skript in C? Oder was Anderes?
Ich frag mich da, was eigentlich aus MoJo🔥 geworden ist... War da nicht das Prinzip "Alles was parallel laufen kann, läuft parallel" und sollte python ähnlich sein..? 🤔
MoJo ist nen kompletter Flopp. Einige Benchmarks die die selbst veröffentlicht haben, sind teilweise viel langsamer als Python - ich glaub das wird nix mehr.
@@RazzerPI Dann hilf vielleicht Codon. Aber eigentlich bist Du mit Numpy + Numba:
import Numpy
from Numba import njit
und der Funktionserweiterung:
@njit
def myQuickDeterminant(): # Oder was anderes
An Deiner numerischen Funktion im Vergleich zu CPython dort, wo es zählt, schon um Welten besser.
Und auch besser als Mojo.
PyPy tut's auch.
Das mit dem Multithreading wird, denke ich, noch eine Weile nach 3.13 brauchen. Würde ich erst mal vergessen.
Alles mit Locks versehen macht das Ganze Single-Threaded + Overhead. Dann kann ich mir den ganzen Bums auch sparen.
Und bis die Zuordnung auf einzelne Kerne dann noch gut läuft, das kann auch noch dauern.
Wenn das noch nicht reicht, gibt es für das Engineering "Collimator". Allerdings Cloud (was Sinn macht: Du fragst für extrem heftige Berechnungen dort an einem Supercomputer an, reservierst Dir ein paar Kerne) und kostet was.
Hat aber den Charme, dass es Python-Code (+ Simulations-Library) zu C transpiliert. Dann nimmst Du im zweiten Schritt den Compiler Deiner Wahl (meistens LLVM oder GNU).
Und Du brauchst nicht die Hypothek einer ganzen Stadt, um mit MATLAB arbeiten zu "dürfen".
Ja schoen ... das wird jetzt lange Zeit wie Anfangs in PHP ablaufen. "Ah schei... die Extension gibts nur als non-Thread-Safe Version. Verdammt!"
Also GIL vs non-GIL sind ~25% ? Das ist schon ordentlich. Es kommt aber noch ein JIT , vielleicht kann der Unterschied damit dann wieder "weg gemacht" werden.
Das UnWissen was hier in den Kommentaren gezeigt wird macht mir Angst
Wozu benötigt man Multithreading in Python? Python ist für leichtes spontanes Scripting aber richtige Anwendungen, die Performance benötigen, sollten auch in einer vernünftigen Programmiersprache geschrieben werden.
Python ist genauso eine "vernünftige Programmiersprache" wie alle anderen auch. Jede Programmiersprache hat nunmal Stärken und Schwächen. (Und so nebenbei ist das Backend von Reddit in Python geschrieben. Ich glaube, dass das schon eine "richtige Anwendung, die Performance benötigt" ist) Multithreading ist auch für Python super! Sehr viel der Entwicklung im KI-Bereich und Data Science genrell findet mit Python statt. Diese Leute und viele mehr freuen sich mit Sicherheit über Multithreaded Python. Python ist sehr schnell zu erlernen und alleine dadurch schon super stark. Es ist eine der am weitesten verbreiteten (Laut StackOverflow's 2024 Survery sogar die am weitesten verbreitetste) Programmiersprache. Also alles andere als unvernünftig
@@PaperPilz solange Python nicht compiliert wird sondern jede Zeile einzeln neu Interpretiert werden muss bevor sie ausgeführt wird, solange ist diese Sprache absolut nicht geeignet für jegliche Anwendung die Performance benötigt. Dieses Manko mit Multithreading zu überdecken ist ein reines herumdoktern am Symptom anstatt eine vernünftige Lösung. Es wird also nur noch mehr Strom auf das Problem geschmissen während man schon viel Ausführungszeit und somit Energie mit einem Compiler sparen würde. Anwendungen mit langer Laufzeit sind nicht geeignet für Python.
Außerdem mag diese Sprache einfach zu erlernen sein aber gerade weil sie nicht sichtbare Zeichen als Steuerzeichen verwendet ist sie eigentlich absolut ungeeignet für Anfänger. Die Fehleranfälligkeit, nur weil man einen Codeblock kopiert und die Einrückung verhaut ist absolut nicht beginnerfreundlich. Auch die Wartbarkeit des Quellcodes verschlechtert sich somit mit der Größe des Projektes.
Python ist also wunderbar um schnell ein paar Tests ober kleine Übungen abzuprogrammieren, auch um Programieren zu lernen. Aber für wirkliche Programme ist Python absolut ungeeignet und intrinsisch ineffizient. Wer diese Prinzipien schon nicht versteht, dem wird auch das Multithreading auch nicht groß weiter helfen weil es dann nur ein Tropfen auf dem heißen Stein des Performancegewinn ist. Es setzt eben an Stellen an, für die diese Sprache einfach nicht geeignet ist und nie sein wird.
Sobald aber ein Compiler auf diese Sprache losgelassen wird übersetzt er das Programm in eine Sprache, die deutlich schneller ist. Ein Compiler könnte Python auch ohne Multithreadingunterstützung parallelisieren. Das parallele Ausführen von interpretierten Codezeilen ist also einfach nur sinnlos.
@@daspie9907das performance problem hat nicht primary was mit interpretation und schongar nicht dem compiling into bytecode zu tun. Es ist die Speichernutzung, die darstellung von ints als mem object und nicht als NaN ist der Hauptfehler
@@llothar68 das mag vielleicht dazu kommen und die Performance weiter verschlechtern, aber solange jede Zeile einzeln angefasst und interpretiert werden muss gibt es alleine bei der Interpretation der Zeilen einen Overhead, der jeden compilierten Code mit gleichen Anweisungen schneller erscheinen lässt. Selbst die Übersetzung in den Bytecode des Python-Programmes ist hardwareunabhängig und wird nur in der Laufzeit Zeile für Zeile interpretiert und damit zur Laufzeit in Hardwareanweisungen übersetzt. Jede für diese Hardware compilierte Sprache wird also schneller laufen weil dann die Interpretierungsschnittstelle wegfällt. Genau das macht doch sprachen, die für die entsprechende Hardware compiliert und angepasst werden so schnell.
Laut Internet ist Python gegenüber der Interpretersprache von Java-bytecode ungefär nur ein Faktor 2 langsamer aber gegenüber der hardwarecompilierten Sprache C um ein Faktor 10 langsamer.
Wie dann Datentypen oder sogar ganze Programme implementiert sind ist eine ganz andere Ebene der Diskussion. Natürlich läuft ein Programm, dass optimiert wurde, schneller als ein Programm, dass viele Anweisungen mehr machen muss um das gleiche Ergebnis zu erhalten. Aber das gilt eben für alle Sprachen, auch die Compilierten. Wenn der Compiler also schlechte Abbildungen der Programmiersprache auf die Hardware hat (z.B. Emulatoren), dann läuft das Programm entsprechend ineffizient. Dein Argument wäre also, dass Python bei den Datentypen bewusst ineffizient bleibt um mehr programmierbare Flexibilität zu erreichen wie z.B. keinen Wertebereich bei Int beachten zu müssen, was eben nur auf kosten der Performance geht.
Ja auch das ist ein Grund, warum Python vielleicht einfach zu lernen ist aber damit gleichzeitig absolut ungeeignet für Programme mit langer Laufzeit ist. Wenn man nur eben mal schnell ein paar Daten auswerten will, die der Computer auch mit der ineffizienten Variante innerhalb ein paar Sekunden durchgerechnet hat, dann ist es vollkommen OK auf die Performance zu verzichten aber dafür den Komfort des schnellen und einfachen erstellen des Skriptes zu beharren. Wenn dieses Auswertungsprogramm dann aber wächst und mehrere Stunden oder Tage rechnet, dann ist eine Parallelisierung natürlich ein Weg das Problem mit mehr Energie zu erschlagen. Ein anderer Weg ist das Programm zu optimieren und dazu gehört eben auch eine vernünftige Programmiersprache zu verwenden, die wie gezeigt sofort einen Faktor 10 erreichen kann. Und wenn auch das dann zu langsam ist kann man über Parallelisierung nachdenken.
@@daspie9907 Sorry, du hast leider mal was gehoert aber keine Ahnung. Die Ausfuehrung von Byte Code ist ueberhaupt nicht das Problem. Ginge noch etwas schneller mit direct threaded code (siehe FORTH implementierungen) oder dem gcc feature calculated jumps natuerlich noch einfacher und etwas schneller als JITen.
Aber das Problem ist
- (a) Integers (ausser 0-255) und Floats sind Heap Objekte und erfordern indirekten Speicherzugriff zusammen mit retain/'release reference counting.
- (b) Das Codemodell ist zu dynamisch, jeder Method lookup ist ein Hashtable Zugriff. Wenns nicht in dem minimalen Method cache steht (der normalerweise gar nichts bringt). Das betrifft teilweise sogar Operatoren (weil man ja alles mit special methods ueberschreiben kann).
- (c) Datenstrukturen sind zu generell und daher nicht optimierbar.
Es ist nicht 10x so langsam, sondern bei algorithmischen Dingen wenn man sowas wie ein Zip Kompressionalgorithmus implementieren wuerde eher 100-300x langsamer als statisch typisierte compilierte Sprachen. Java ist schon langsam weil dort auch alles im Heap liegt (mit Cache Miss bedeutet das dann schon mal 100 Taktzyklen einfach nur warten).
Speed ist heute Memory Zugriff und nichts anderes. Denn RAM (Random Access) gibts schon lange lange gar nicht mehr. Es sind alles Cache Line Bursts
Nichts hat miit der Interpretierbarkeit zu tun. In einer Pruefung waerst du bei mir mit deiner Antwort gerade mal mit einer 4 durchgekommen.
Also, race-conditions und dead-locks sind grundsätzlich verschieden, d.h. race-conditions führen nicht einfach zu dead-locks. Race-conditions (timing-issues) führen zu Abstürzen und zu fehlerhaften Ergebnissen, während dead-locks (resource-blocking-issues) zu Endlosschleifen führen.
danke Sherlock
Er hat doch auch gesagt, dass Race-Ronditions zu Dead-Locks führen können, nicht dass das äquivalent wäre. 🤔
@@snygg1993 ...er sagte, im schlimmsten Fall kann es bei race-conditions zum dead-lock kommen (@ 2:43 ). Und diese Aussage stimmt so nicht, allein schon deshalb, weil eine race-condition bereits der schlimmste Fall ist. Und sollte eine race-condition zu einem dead-lock führen, dann ist immer noch das Problem die race-condition und nicht der durch sie verursachte dead-lock. Eine race-condition kann zu allem Möglichen führen, weil das Programm dadurch unkontrollierbar wird, weshalb race-conditions auch äußerst schwer zu entdecken sind.😉
@@knofi7052 Hmm, ne, also so ne.
Eine Race-Condition beim schreiben eines Pixels während eines Videospiels ist ... naja, da hat dann ein Pixel die falsche Farbe, definitiv nicht "der schlimmste Fall".
Eine Race-Condition ist auch nicht immer soooo unbeherrschbar. Der Pixel ist halt manchmal richtig und manchmal nicht ... das ist meinem Drucker ziemlich egal und das Spiel funktioniert auch sonst wie gewollt.
Ein Dead-Lock (unabhängig ob durch eine Race-Condition beim locken einer Resource oder einen Programmierer- bzw. ChatGTP- Fehler verursacht) erfordert idR. einen Neustart des Threads/Prozesses/Programms/Computers. Ich denke wir sind uns einig, dass das doch irgendwie schlimmer ist als ein falscher Pixel bei 4K Auflösung?
Eine Race-Condition kann der Auslöser für ein Fehlverhalten sein, während ein Dead-Lock ein Fehlverhalten ist, das durch eine Race-Condition ausgelöst werden kann.
... lediglich über das "im Schlimmsten Fall" kann man diskutieren.
Wenn zB. eine Race-Condition dazu führt, dass zwei pole bestromt werden, die nicht gleichzeitig bestromt werden sollten, was dann irgendwas abfackeln lässt, würde ich das als "deutlich schlimmerer Fall als ein Dead-Lock" bezeichnen.
@@snygg1993 Du kommst jetzt echt mit dem Beispiel von einem Pixel mit einer falschen Farbe daher? Ich glaube, wir sind uns einig, das sowohl race-conditions, als auch dead-locks äußerst kritische Programmierfehler sind. Wobei race-conditions zu völlig unvorhersehbaren Folgen und dead-locks zu einer Blockade einer Ressource führen. Wenn aber eine race-condition zufällig zu einem dead-lock führt, ist das Problem, d.h. die Ursache, die race-condition, oder? Davon abgesehen haben dead-locks zumindest den Vorteil, viel leichter erkannt werden zu können.
Jetzt NodeJS
Ich denke NodeJS mit seinen Worker Threads ist noch mal etwas anders.
Allerdings ist meine Erfahrung da eingeschränkt, habe bisher nur ein wenig mit Web Workern im Browser experimentiert.
@@Ph34rNoB33r Das ist noch Multiprocessing
@@xorda1337 Web Workers machen eigene Prozesse auf? Die werden überall als "background thread" bezeichnet, da hätte ich das nicht erwartet.
@@Ph34rNoB33r Vergiss was ich gesagt habe. Sowohl Worker Threads in NodeJS als auch Web Worker im Browser sind Threads und keine eigenen Prozesse. Allerdings sind diese isoliert voneinander. Die Verwirrung kommt, weil es an manchen Stellen verwirrend erklärt wurde.
"Es kommt einiges an Arbeit …" - das klingt arg nach soft Trauma. Such mal nach "Software developers should avoid traumatic changes". Dazu gehört auch, dass sich nicht immer wieder ändert, wie kanonischer Code aussieht. Was Pythonic ist, sollte auch in 10 Jahren noch Pythonic sein. Und es klingt, als würde das gerade kaputtgehen …
(ich freue mich, eines besseren belehrt zu werden)
Wieso wurde nicht direkt pypy genutzt?
Pypy ist wie alle versuche gehypter nicht funktionerender Mist. Es ist die interne Darstellung und das C ABI
@@llothar68 pypy holt im Mittel Faktor 4 an Geschwindigkeit raus - bei einigen Anwendungen auch Faktor 10, aber manche sind auch langsamer - aber ja: v.a. für pure Python, das stimmt. Wenn du schon komplexe Optimierung via C geschrieben hast, bringt dir das nichts. Es ist also der klassische Fall: wer am tiefsten in die Sprache eingestiegen ist, trägt den höchsten Schaden, wenn Infrastruktur instabil wird.
Durch die C-ABI wäre pypy wohl wirklich noch problematischer … die hatte ich nicht mitbedacht.
Hey ich schaue dich schon länger und ich bin dankbar aber es wirkt so als würdest du in letzter Zeit Amphetamine oder ähnliches kosnsumieren.. ich hoffe nicht, aber wollte nur das Feedback geben, und falls dann hör lieber früher als später wieder auf… man merkt es schon und es wird dich Stück für Stück sabotieren auf Dauer… kenne einige solche Fälle aus dem Bekanntenkreis die den Absprung nicht geschafft haben. Also, sorry aber das musste jetzt mal raus, ich hoffe ich irre mich und viel Glück in jedem Fall! 🍀
obiger Kommentar ist ein Bot, der Kanal wurde heute erstellt
Das hab ich noch nicht ganz verstanden. Der Kommentar vom Bot hört sich nicht danach an, etwas zu wollen. Wenn ich auf dem Account bin, sehe ich auch kein Link, Angebot oder ähnliches, was seine Daseinsberechtigung wäre. - Einzig Logisch wäre für mich, dass der Account "zu neu" ist und erstmal mit "Kommentaren aufgebaut" ?@@btntr