Guido van Rossum: Felgyorsítjuk a Pythont!

HUP cikkturkáló

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.

( hg2ecz v | 2021. 05. 18., k – 14:19 )

Szerkesztve: 2021. 05. 18., k – 14:35

Tök jó. Bár lehet, hogy a PyPy projektbe kellene több energiát beletolni
 

#!/usr/bin/python3

import sys
print (sys.version)

def teszt(num):
    acc = 0
    for i in range(num):
        for j in range(num):
            acc += i^j
    print(acc)

teszt(10*1000)

 

$ time python3 teszt.py
3.9.4 (default, Apr  4 2021, 19:38:44)
[GCC 10.2.1 20210401]
642122061696

real    0m10,555s
user    0m10,552s
sys    0m0,000s



$ time pypy3 teszt.py
3.6.12 (7.3.3+dfsg-3, Feb 26 2021, 04:58:43)
[PyPy 7.3.3 with GCC 10.2.1 20210220]
642122061696

real	0m0,231s
user	0m0,188s
sys	0m0,024s

( suckit | 2021. 05. 19., sze – 14:39 )

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.

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

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

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. 

( bocs | 2021. 05. 20., cs – 09:34 )

Ugyanitt: "Trabant igényeseknek extrákkal eladó"