Guido van Rossum chce dvojnásobně zrychlit CPython

Jinými slovy - pořád tady bude strašit GIL, Amdahlův zákon je neúprosný. Zajímalo by mě tedy, jak došli k odhadům možného zrychlení a jestli se někdy pustí do odvážnějších změn nebo jestli si myslí, že půjde dál a dál zrychlovat v rámci vykolíkovaného prostoru.

Kdyz uz mate potrebu si kopnout pod kazdou zpravickou o (c)Pythonu, mohl byste alespon sledovat vyvoj. Problem GILu resi PEP 554.

Python je skriptovaci jazyk, rychlost vetsinu uzivatelu netrapi.

17. 5. 2021, 10:42 editováno autorem komentáře

Že rychlost většinu uživatelů pythonu netrápí je, myslím, poměně odvážné tvrzení. Ve skriptovacích jazycích píši léta a věřte, že jak GIL, tak rychlost provádění nejen mě trápily celkem odjakživa. Dokonce bych řekl, že je to jedna z hlavních issues. Skriptovací jazyky se už léta opravdu nepoužívají jen pro primitivní skriptování.

GIL ma svoje vyhody v jednoduchosti a rychlosti pri jednovlaknovem provozu. CPU-bound ulohy se vetsinou resi v C-cku pres NumPy, IO-bound ulohy se casto take provadi v C-cku (DB driver, sockety...) a v obou pripadech neblokuji GIL. Diky cloudu a microservices je multi-threading pro (vertikalni) skalovani cim dal min atraktivni a je nutne skalovat horizontalne. Spousta problemu nevyzaduje masivni sdilenou pamet a timpadem multi-processing neni az tak velky problem pro prekvapive mnozstvi uloh z realneho sveta. A i pro zero-copy sdileni pameti mezi procesy uz existuji reseni (shmem + struct.pack) a rysuje se snadnejsi (buffer protocol + sub-interpreters).

Koho by zajimal stav temat kolem CPython performance, postupne jsou zverejnovany zapisy z language summitu: https://pyfound.blogspot.com/2021/05/the-2021-python-language-summit.html

17. 5. 2021, 11:53 editováno autorem komentáře

No vida, někdo píše k věci. Konečně!

Kde vidíš jaké kopání? Mě Python živí už spoustu let a dělám v něm dobrovolně, ale to neznamená, že se nebudu zajímat o jeho mantinely a možnosti. Moje otázky byly zcela konkrétní k dané zprávičce.

> Kde vidíš jaké kopání?

treba tady https://www.root.cz/zpravicky/cinder-cpython-implementace-s-jit/#newIndex1

Je sice hezké, že mě stalkuješ a vedeš si seznam mých příspěvků, ale NE. V daném vlákně NEPÍŠU nic proti (C)Pythonu. Pokud snad potřebuješ dovysvětlit moje příspěvky, můžu to udělat v nějaké privátní konverzaci, případně ses mohl ozvat, dokud ta zprávička byla aktuální.

Zároveň bych byl rád, kdyby ses soustředil, pokud to umíš, na Guidův počin, o kterém je tato zprávička a nemíchal dohromady hrušky a jabka.

No a podle toho, co jsem četl, například zde https://lwn.net/Articles/820424/ ,
PEP 554 zase taková výhra není. Taková evangelizace je fakt kontraproduktivní.

ma to asi jen specificka vyuziti, ale jinak to bez rozbiti zpetne kompatibility nejde. Kdyby to slo, bylo by to uz davno implementovane.

No tak vidíš.

Osobně, co se týče GIL, tak se bojím, že se ho zbavíme až ve chvíli, kdy se někdo rozhodne celý interpret komplet přepsat (nejdál je dnes snad Oracle, který se snaží naimplementovat Python pod GraalVM - tím, že je to v podstatě JVM jsou tam Pythoní vlákna něco jako Java vlákna a GIL tam tím pádem není).

Co se týče výkonu nicméně nesouhlasím s tím, že by nebyl v Pythonu problémem. Skrz scipy ekosystém se Python dnes stal standardem pro počítání/simulování prakticky čehokoliv a jeho mizerný výkon je v těchto oblastech primárním limitujícím faktorem. Člověk pak řeší dilema, zda-li použít Python, který je sice šíleně pomalý ale většina numerické matematiky je pro něj odladěná v nejrůznějších knihovnách, nebo se do toho pustit vlastními silami v cpp s tím, že to bude řádově rychlejší, ale musí si naprogramovat vše sám.

Já osobně se hodlám naučit PyO3, Rust je pro mě lepší volba než C++. Nicméně vidím to asi dost podobně.

Ale ten scipy ekosystem neni naimplementovan v Pythonu.

"stal standardem pro počítání/simulování prakticky čehokoliv"
Nevidel bych to tak. Zadny graf zastoupeni neznam, ale sposuta lidi jede matlab/octave, sposuta jede Rko, a pak jsou tady hromady specializovanych nastroju pro CFD jako solidworks, femlab atd.