Názory k článku
Guido van Rossum chce dvojnásobně zrychlit CPython
-
Ž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
-
> 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.
-
To je ale hodně velké zjednodušení, v několika různých ohledech, které tady ani nechci vyjmenovávat. Mně by se hlavně líbilo, kdyby byl jeden interpret a všechno se v něm podařilo vyřešit - třeba i za cenu rozbití nějakých těch závislostí (s Pythonem 3 se velká změna zvládla). A jaká je situace? Jelikož CPython má některá omezení, udělal se PyPy, s podporou eurograntů a za účasti Guida, kterého na hlavní stránce https://www.pypy.org/ přímo citují:
"If you want your code to run faster,
you should probably just use PyPy."
-- Guido van Rossum (creator of Python)Zprávička, na kterou jsi odkazoval, kde je můj údajný hejt, píše o třetím interpretu, který není ani "vanila" CPython a ani PyPy, který Guido kdysi tak nějak doporučoval a který někteří z nás viděli jako budoucnost Pythonu.
No a teď ten samý Guido chce optimalizovat CPython, což je docela super, žádný hejt z mé strany nebyl, ale potenciál toho zrychlení je sporný, podle mě. Na tohle bych se soustředil, to je základ zprávičky pro mě - co a jak moc se dá změnit v rámci plánovaných úprav, kterými se Guido a spol. hodlají zabývat.
-
Je otázka, jak moc to dnes vadí. Teď jsem třeba zkoušel na svém domácím PC rozjet pypy3 (3.6), první start chvíli trval (byl subjektivně pomalý), druhý a každý další start jsem nepoznal. Hardwarové nároky (RAM?), to dnes taky nevidím jako zásadní brzdu. Vždycky jde o to zvolit nejméně bolestivý kompromis.
Spíš mě odrazuje, že PyPy zatím podporuje max. 3.7 a nekompatibilita s některými knihovnami.
-
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í. -
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.
