A nyelv kitalálója, Guido van Rossum a pandémiára hivatkozva (unalmában) jelentkezett a Microsofthoz, ahol szabadon választhatott magának projectet. Így hát úgy döntött, visszatér a gyökerekhez és a Pythonnal és annak felgyorsításával fog foglalkozni egy jelenleg kisebb (3 fős) csapatával:
- a HotPy és HotPy 2 során szerzett tapasztalatokra építenek
- tervezett 5x gyorsulás 4 év alatt (1.5x / év)
- type layout, base object és az eredeti API, ABI nem változik, extrém esetekben sem lehet lasabb az új megvalósítás
- a compiler, interpreter, bytecode és "most object's internal" változhat
- elképzelhető egy "machine code generation" a jövőben
- "CPU-intensive" python kódok és pythonos weboldalak profitálhatnak leginkább a fejlesztésekből
A változások leghamarabb a jövőre megjelenő, 3.11-es verzióban lesznek elérhetőek, 2x sebességjavulást prognosztizálva.
Részletek a közzétett pdf-ben.
Hozzászólások
Tök jó. Bár lehet, hogy a PyPy projektbe kellene több energiát beletolni
Biztos oda nem vettek fel a tagot. De az unokatesoja pypynel dolgozik, vannak reszvenyei es ha nem lesz meg evente a 150%, akkor majd ms felvasarolja a pypy-t.
@BCsabaEngine
Valós szoftverekben azért közel sincs meg ez az arány.
Az a szoftvertől függ. Nekem sikerült egy adatfeldolgozó appon kb. 10-szeres különbséget mérni.
ha jol tudom a pypy-vel a libek/importok jelentos resze nem mukodik... innentol kezdve lehet egyszeru szoveg feldolgozkat meg for ciklusokat benchmarkolni vele, de gyakorlatban nem sok mindenre jo
Épp itt az ideje, a perl már most 2x olyan gyors.
Szkriptnyelvek közül a pehelysúlyú, amit az OpenWRT luci webes adminfelülete is használ és sok más programba bele van építve (apache, nginx, nmap, ...), az a LUA.
Ezt mérd meg lua-5.4 futtatókörnyezettel
XOR ~ jelén mondjuk kitéptem a hajam. Miért kellett eltérni?
A LUA 5.2 és régebbi időkben a bit csomagból kellett használni. A luajit még 5.1 szintaktikás, de nagyon fürge.
Ezt is megmérheted. Ilyen jellegű feladatokhoz ritka fürge a szkriptnyelvek között.
Hurrá, kíváncsi vagyok mit sikerül elérni (így tippre nem sokat).
Mindenesetre ha mégis, remélem a következő nagy lépés a valódi multithreading irányába fog történni.
Kifejtenéd, hogy mire gondolsz bővebben? Nem mélyedtem még el ebben a részben, így érdekelne a meglátásod.
...úgyis jönnek...
Kerese ra: python + gil
Gyakorlatilag a Python egyszalu, mert hulyen irtak meg (jo, ennek is van oka, de roviden ennyi). Letrehozhatsz uj szalakat, de van egy global lock, ami mindig csak egy-egy szalat enged egyszerre futni. Multiprocessinggel persze athidalhato a dolog valamennyire, de akkor meg a processek kozti kommunikacio korlatozza a dolgot.
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin
Hülyén írták meg -> hülyebiztos(abb)ra írták meg
A rosszul kezelt versenyhelyzet rosszabb, mintha nincs versenyhelyzet, mert egzotikus nehezen reprodukálható hibát okoz. Ez itt nincs, cserében tényleg lassabb. Ritkán zavar, lehet több példányt futtatni és akkor példányonként van egy gil, nem akad össze.
Ha felsz a versenyhelyzettol (teny, komplexitast hoz a rendszeredbe), akkor nem muszaj thread-eket hasznalni, es nincs rosszul kezelt versenyhelyzet sem.
Ha azonos adaton kell dolgoznia, nem annyira jo a tobb process, mert az adat ide-oda kuldozgetese felesleges overhead.
Volt olyan projectem, amiben jo lett volna, ha normalis threadek vannak, es az sem zavart volna, ha van egy masik, buta thread implementacio, ami minden mast blokkol.
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin
Vajon Rust-hoz hasonlóan valamiféle parallel iterátor is lesz benne? /* Rust esetén frankón szétrobban a sok magra a feladat */
A multiprocessing pool-ja most is tud map-et meg ennek az aszinkron valtozatat. A problemam nem a kenyelmevel van, hanem az, hogy ez kulon processben fut, es az adatot oda-vissza szerializalnia kell.
Pl. van egy ilyen egyszalu kod, ami egy l lista elemeire (lehet mas is) raereszti az fv fuggvenyt, es visszaadja az eredmenyt:
result=map(fv,l)
Ez tobszalukent arra modosul, hogy:
result=pool.map(fv,l)
Ha elotte letrehoztad a pool-t: pool=multiprocessing.Pool(4) # ez 4 szalon fog feldolgozni.
Kuldheted hatterbe is, pool.map_async(fv,l,1,done_callback), itt a visszaterese nem erdekes, a done_callback fuggvenyedet hivja meg az eredmennyel, aszinkron modon. Persze ebben az esetben utolag leloheted, ha megsem erdekel mar az eredmenye, mert megy tovabb a kodod, vagy ha gondolod (kene mar az eredmeny) megvarhatod, stb..
When you tear out a man's tongue, you are not proving him a liar, you're only telling the world that you fear what he might say. -George R.R. Martin
A hozzászólásod alapján arra gondolnék, hogy még sosem kellett többszálú python programban hibát keresned. :)
Miért ne lenne versenyhelyzet?
Lehet versenyhelyzetet csinálni, csak nem tolja a képedbe, hogy használd és igyekszik kerülni amíg lehet. Ennek jó példája az async io, ami látszik, hogy még mindig idegen elem kicsit a nyelvben, de pl pont arra ad alternatívát, amikor először elérsz a falig és eszedbe jutna thread szaporítás.
Nincs bajom a versenyhelyzet kezelésével. De azzal igen, hogy nehezen derül ki élesítés előtt, hogy egyáltalán van ilyen hiba a rendszerben.
Hint: ne az egyszemélyes hobbi projektre gondolj, ahol tudod, hogy mennyire dolgozol minőségben, vagy hol hagytál pár kompromisszumot. Hanem amikor nem tudod, hogy a kollégák hol hagytak... Tudom, code review.
"hülyebiztos(abb)ra írták meg"
Sajnos nem igaz, a GIL egyszerűen lecseréli a versenyhelyzeteket deadlockokra. Csöbörből vödörbe. Ráadásul emiatt a natív OS hívások (pl socket, file IO) sem blokkolhatnak, ami egy külön agyrém. Trust me, debuggoltam ilyen hibákat nagy python projektekben (értsd: openstack subproject). A legszörnyűbb, hogy sokszor nem is maga a GIL, hanem a GIL workaroundolására kitalált eventlet, green threads meg hasonló library-k idéznek elő teljesen elképesztő hibákat.
Régóta vágyok én, az androidok mezonkincsére már!
Ezt csak úgy ide bedobom a GIL-less Pythonról: https://lukasz.langa.pl/5d044f91-49c1-4170-aed1-62b6763e6ad0/
Egyébként van olyan Python implementáció (Jython, GraalPython) amikben nincs GIL. (PyPy-ban van).
Egy másik érdekes irány szerintem a mypyc: https://mypyc.readthedocs.io/en/latest/index.html
Ugyanitt: "Trabant igényeseknek extrákkal eladó"
Ez mit jelent?
Azt, hogy ha az alapok rosszak, akkor reszelheted nagyon sokat, de sose lesz igazán jó.
Érdekességképpen nim script vs python script a legvégén nim compiled bináris vs pypy3 python. :-)
Ezzel azt szeretnéd mondani, hogy a kétfázisú (fordít, futtat) programfuttatás második szakasza gyorsabb, mint amikor mindkettőt egybe el kell végezni első alkalommal?
Fordításnál figyel oda, nehogy így járj: https://rust.godbolt.org/z/MaoaYTeKs
Látható hogy fordításidőben már végigszámolja és az eredményt direktben adja vissza.
Ha valaki még kíváncsi a Talk Python to me podcast két november eleji adásában pont ezekről volt szó:
https://talkpython.fm/episodes/show/339/making-python-faster-with-guido-and-mark
https://talkpython.fm/episodes/show/340/time-to-jit-your-python-with-py…
Az utóbbihoz kapcsolódva, láttam fentebb páran észre vették, hogy a Pypy - ami egy jit compiler - gyorsabban hajtja végre a Python kódot mint a CPython - ami egy Ahead of time compiler - cserébe a nagyobb memória használatért meg, hogy nem lehet C-ben írt modulokat használni. Ha valakinek ez elfogadható kompromisszum akkor csak tessék. Egyébként meg létezik már Pyjion. Ez a .net runtime-ot használja, habár több szálúságot még ez sem tud.
A CPython sose volt AOT fordító, teljesen interpreter alapú. Van C API-ja, amivel lehet Python Extensionoket illeszteni hozzá bármilyen C API kompatibilis nyelvből, azok valóban általában előre le vannak fordítva, de a Pythonban írt kód interpretálva fut.
Python AOT-re van több próbálkozás is, pl. a Cython, ami nyelvi kiterjesztéseket is hoz, és a Mypyc (amit fentebb linkeltem), ami a szabványos Python type hinteket felhasználva próbál hatékony natív kódot generálni.
.NET-re épülő Python implementáció már ~15 éve létezik, úgy hívják, hogy IronPython. Támogat többszálúságot, a Python kód CIL-re fordul és onnan a .NET JIT futtatja, nincs benne GIL. Sajnos az utóbbi időben kicsit lemaradt nyelvi támogatás szempontjából a CPythonhoz képest (most jelent meg nemrég a 3.4 alpha). Hasonló történt a Jython-nal is, ami ugyanez Java platformra. Itt a GraalPython tűnik érdekes projektnek, de sajnos lassabban halad, mint ideális lenne.
A Pyjion-t nem ismertem, de a projekt leírása alapján ez a CPythonhoz csinál JIT támogatást biztosító API-t, aminek az első implementációja CoreCLR alapú, de a projekt célja, hogy mást is lehessen illeszteni hozzá. A projekt README-ben egyébként elég jól összeszedték, hogy miben különbözik az ismertebb alternatív implementációktól: https://github.com/tonybaloney/Pyjion#how-do-this-compare-to