Bei welcher Arbeitslast übertrifft der Free-Threaded-CPython-Build einen Prozess-Pool für einen gemischten E/A- und CPU-Dienst?

Offene Frage

Der Free-Threading-Guide hält fest, dass der Free-Threaded-Build beim Ausführen von Python-Code zusätzlichen Overhead hat, der in der pyperformance-Suite von etwa 1 % auf macOS aarch64 bis 8 % auf x86-64 Linux reicht, und dass der GIL automatisch aktiviert werden kann, wenn ein Extension-Modul importiert wird, das nicht als Free-Threading-fähig markiert ist. Ein Prozess-Pool vermeidet beide Kosten, bezahlt aber für das Pickling von Argumenten und Ergebnissen sowie für dupliziert gehaltenen Speicher pro Worker. Bei einem Dienst, dessen Anfragebehandlung Parsing, Datenbankaufrufe und etwas CPU-Arbeit in Python mischt: Bei welchem Verhältnis von CPU-Zeit zu Wartezeit, welcher Grösse des Working Sets und welcher Kernzahl liefert ein Thread-Pool auf dem Free-Threaded-Build mehr Durchsatz pro Kern und eine bessere Tail-Latenz als ein Prozess-Pool auf dem Standard-Build? Ändert sich die Antwort, sobald der heisse Pfad von C-Extensions dominiert wird, die den GIL bereits freigeben, und wie gross ist die Speicherersparnis durch das Teilen eines Heaps in der Praxis? Eine Nebenfrage ist, ob sich die Antwort zwischen einem Webserver mit vielen kurzen Anfragen und einem Batch-Job mit wenigen langen Aufgaben unterscheidet, da beide den Interpreter unterschiedlich belasten.

Was eine nützliche Antwort enthält

Python-Version und -Build (sys.version enthält «free-threading build»), die Bestätigung, dass sys._is_gil_enabled() während des Laufs False zurückgab, die beteiligten Extension-Module und ihr Free-Threading-Status, die Arbeitslast mit ihrem Verhältnis von CPU-Zeit zu Wartezeit, Kernzahl und Speicher pro Worker, das Lastmodell (offen oder geschlossen), Aufwärm- und Wiederholungszahlen, Durchsatz und Latenzperzentile pro Konfiguration mit ihrer Varianz, sowie das Datum, da sich sowohl der Interpreter als auch das Paket-Ökosystem schnell ändern.