Názory k článku Rychlost CPythonu 3.11 a 3.12 v po­rovnání s JIT a AOT překladači

Clanek super. Dekuji. Hlasite vytky ke grafum -- mozna jsem barvoslepy nebo jinak poskozeny ale opravdu mam problemy odlisit jednotlive odstiny barev. Fujky.

to je výchozí chování Matplotlibu, což je zvláštní, protože mít víc než (řekněme) 5 kategorií je běžné. Zkusím to projet ještě jednou s explicitně nastavenými barvami, protože u těch liniových grafů to fakt mate. Vydržíte 1-2 hodiny? (mám ještě něco dalšího, urgentnějšího)

Tyjo, 12 kategorií, to je trošku challenge si vybrat paletu :-)

Hele bylo by to takto lepší?

první a čtvrtý graf: https://github.com/tisnik/most-popular-python-libs/blob/master/mypyc/benchmark_results/benchmark_results.ipynb

Zkusil jsem to zgrupovat do čtyř skupin: native, mypyc, numba, cpython

Pokud můžu názor - to barevné zgrupování je super posun, ale držel bych se jednotného gradování, tedy například udělat vyšší verzi vždy tmavší (nebo světlejší) - numba 4 je nejsvětlejší a Python 3.12 "nejtmavší" (resp. více do modra - čekal bych, že bude taky nejjasnější, aby to bylo podle stejné logiky).

diky, jdu na to!

Ono teda je to od nejtmavsiho po nejsvetlejsi:

color=["#a00000", "#a0a000",                  <- ANSI C
             "#00c000", "#00c030", "#00c060", "#00c090", "#00c0a0", < cpython
             "#ff0000", "#ff8000",             <- mypyc
             "#0000ff", "#0060ff", "#00c0ff"   <- numba

21. 11. 2023, 09:48 editováno autorem komentáře

Mnohem lepsi, dekuji.

Díky, ta nová verze vypadá super.

Barevně je to teď mnohem lepší. Díky, úžasný článek.

upraveno. Ale ty liniové grafy jsou pořád stejně špatný. Možná zkusím jiné styly bodů atd. ale to později. V každém případě v-barové :-) grafy jsou teď možná pochopitelnější.

Tak snad už lepší:
https://www.root.cz/obrazek/1110420/
https://www.root.cz/obrazek/1110421/

To, že se nedají moc rozeznat CPythony tady až tak nevadí, na to jsou další grafy (jen s CPythonem)

Narazil jsem na toto. Znáte? Ještě jsem to nezkoumal, tak sám nevím, jestli stojí za to se tím zabývat. https://github.com/bytedance/matxscript

popravdě jsem to neviděl. Ono takových pokusů o AOT je víc. Už jsem tady psal o Cythonu (to je možná zvláštní kategorie), Numba má také AOT (ale deprecated), teď mypyc. Zatím je to ale docela zklamání - ještě se k tomu vrátím ve čtvrtek, pokud to stihnu doměřit a dopsat :-)

Díky za článek. Docela by mě ještě zajímalo, kam se zařadí PyPy. A překvapuje mě, že 3.12 je pomalejší než 3.11, ale třeba to ještě v nějaké podverzi vylepší...

Me prekvapilo, ze 3.11 je opravdu rychlejsi tak, ze je to poznat. Jako vim, psalo se o tom vsude, ale stejne, kdyz to clovek vidi u cistych smycek a vypoctu (tj. nezvedli vykon napriklad tim, ze udellai nejaky optimalizace se slovniky nebo neco takovyho, fakt je to v interpretru)

Pokud jsem dobře pochopil Guida, přitlačilo se na kešování.
Původní interpreter při sčítání čísel vždy důsledně koukal na to, jak sečíst int a int (string a string, float a int apod.), v definici objektů a provedl. Nový interpreter optimisticky předpokládá, že se typ promenných nebude lišit a tedy že know how s operací může cachovat - vede to naopak ke zpomalení, pokud se typy často mění, a vyšší spotřebě paměti.

ajo to vysvetluje jak zrychleni, tak i ty trosku vetsi pametove naroky. diky!

Diky za hezky clanek. Pri dlouhych smyckach a pouziti Numpy mam s Numbou dobre zkusenosti. Trochu jsem doufal, ze do benchmark sady zahrnete i lpython, hlavne kdyz nese silnou ceskou stopu :) Jako priklad uziti maji na webu prave Mandelbrotovu mnozinu! https://dev.lpython.org/

P.S.: Prvni graf jsem taky nerozlustil, vychozi barevna sada Matplotlibu mi fakt nesedi :(

diky! uz na tom pracuji (barevna paleta)

upraveno. Ale ty liniové grafy jsou pořád stejně špatný. Možná zkusím jiné styly bodů atd. ale to později. V každém případě v-barové :-) grafy jsou teď možná pochopitelnější.

(repeat)
Tak snad už lepší:
https://www.root.cz/obrazek/1110420/
https://www.root.cz/obrazek/1110421/

To, že se nedají moc rozeznat CPythony tady až tak nevadí, na to jsou další grafy (jen s CPythonem)

Dobrý den, já jsem si teď zkoušel hrát s tímhle, přijde mi to impozantně rychlé a ambiciózně pojaté, ale zatím v plenkách. Neznáte to?

Jmenuje se to Codon

https://exaloop.io

Koukám, že každý den, něco co neznám. Díky za sdílení.

jj jak pise Wavelet :) pridavam se

Tak ze stejného soudku, https://www.modular.com/mojo a další, ale to by čék strávil mládí na tom.

Ještě existuje cinder of fb:

- https://github.com/facebookincubator/cinder

Taky má integrovaný JIT, možná by stálo za to to porovnat.

Díky, určitě zkusím příště. Zatím jsem se orientoval na technologie, které jsou production-ready, což mypyc a Numba jsou. Ale zkusit můžu i další JITy a AOTy, třeba cinder, lpython atd.

Jedna dalsi vec co mi nebyla uplne jasna je "zda se provedl optimalni preklad". Nejsem si uplne jisty, co to znamena v kontextu jit. Je to neco "trivialniho" jako ze zadna promenna nemusi byt C-style PyObject? Nebo neco jineho?

Kterou kapitolu/odstavec myslíte?

Konkretne jsem myslel kapitolu 7. Priijde hodne vagne/abstraktne napsane :). Ale neni to stiznost, dokazu si domyslet, ze s typovou informaci dokaze optimalizovat lepe.
Jinak, kdyz uz odpovidam, v jednom pripade se Vam to _5 prepsalo jako spodni index:
"O tom, že výše uvedený příkaz nebude importovat soubor mandelbrot_5.py, ale nativní sdílenou knihovnu, se můžeme přesvědčit například použitím nástroje strace:"

Aha díky. K tomu se ještě vrátím, protože to je na mypyc asi to nejdůležitější (a asi není náhodou, že je to součást mypy). Protože například taková funkce add(x,y) - o té může překladač v AOT říci jen to, že akceptuje dvě hodnoty typu PyObject a volá se tam metoda __add__ prvního předaného objektu. Tj. všechny ty kontroly typů, unboxing atd. se budou provádět v runtime - s tím mypyc nedokáže nic udělat.

Až u funkce add(x : int, y: int) může překladač vygenerovat int add(int x, int y) nebo si před to klidně dát i inline, pokud je to hodně krátký kód.

Fakt se k tomu vrátím, to je možná téma na celý článek :-)

K tomu indexu - s tím bohužel vůbec nic nedokážu udělat. Je to vlastně docela schizofrenní situace, protože text mám psaný v HTML, takže by ho redakční systém měl vzít tak jak je ("raw input"). Ale on do něj z neznámého důvodu hrabe a mění _x na dolní index. Dělá ještě nějaké další transformace, ale na ty jsem si za ta léta zvyknul a uhýbám mu z cesty :-) (třeba vyžaduje značky [b] a [em] a ne [strong] a [i], což je opět schizofrenní mix) ale zrovna ty indexy se tam objevují.

Pekny clanok. Dakujem. Je fajn mat aky-taky obraz, kde sa to pohybuje. Len ma to donutilo zamysliet sa, ci rychlost je to najpodstatnejsie, lebo doteraz som Python bral ako skriptovaci jazyk. Tak som si volaco precital a zistil, ze uz sa to povazuje za programovaci jazyk. V tom pripade je to este veeeelmi dlha cesta a asi to nepojde bez zasadnych zmien. Mozno Python 4.x.x ...uvidime.

Že je Python interpretovaný a v něčem neoptimální, je jasná zpráva. Problém je GIL a problém jsou některá konkrétní místa podle zákona pana Amdahla. Řeší se to v Pythonu jako vždy - extension modulem v kompilovaném jazyce - C nebo třeba Rustu.

jak máš definovaný rozdíl mezi skriptovacím jazykem a programovacím jazykem? Trošku naivně jsem si myslel, že to první je podmnožinou druhého...

21. 11. 2023, 15:55 editováno autorem komentáře

To by mě taky zajímalo, zvlášť třeba když unix shell taky spousta über-programátorů (über=C/C++, Java …) nebere jako programovací jazyk :D

Jo také se jednou plánuji odklidit do jeskyně, poustevničit a nechat tento svět plný utrpení za zády. Ještě si ale něco musím v Pythonu naskriptovat na důchod.

asi to bude na flamewar, offtopic nebo jsem staromilec. snad mi to prominete a diskuze bude ve vsi slusnosti.

jasne uznavam, ze v perlu, pythonu, jave, php se dela rychleji, pohodlneji a asi i jednoduseji.

ale proc vznikaji nove a nove programovaci jazyky, kdyz to prezenu, proc nestaci C?

> jasne uznavam, ze v perlu, pythonu, jave, php se dela rychleji, pohodlneji a asi i jednoduseji.

Mne se zda, ze jste si odpovedel sam.

dobre, ale neni to jen pocatecni lenost?

Ne. Ty jazyky jsou prostě efektivnější.

Je to dlouhodobá zkušenost. Opakovaná a drahá.

> ale proc vznikaji nove a nove programovaci jazyky, kdyz to prezenu, proc nestaci C?

To je jako ptát se, proč vznikají nové nástroje, proč nestačí pěstní klín.

C je jazyk z IT pravěku. Ten jazyk má minimum featur a extrémní množství pastí. A to má každý překladač hromadu rozšíření, aby se ten jazyk dal rozumně používat.

IMHO je to jen další úroveň abstrakce a to je většinou naprosto v pořádku.

Málokdo asi v relném céčkovém userland kódu volá funkce jádra pro tisk zpráv nebo otevírání souborů. Raději použije něco ze stdio atd. Proč ne, je to ověřené a pohodlné, taky bezpečnější.

A přechod na další jazyk je ještě jedna úroveň abstrakce. Protože si nebudeme nic nalhávat - ani profíci nedokážou "uřídit" větší projekty a knihovny v céčku. Důkazem je CVE databáze (a ta obsahuje fakt jen bezpečnostní chyby, ne to, že něco padá na double free nebo přepsání zásobníku bez vektoru útoku).

Ano - teoreticky můžeme psát v C (teoreticky můžeme psát i v assembleru), ale lidé obecně to pro rozsáhlejší projekty prostě nezvládají. (opět IMHO, a to mám osobně céčko a assemblery rád; nicméně nebudu zavírat oči před realitou).

Děkuji za článek.

V článku vidím šotek 2x vypsal špatně název souboru mandelbrot5.py kde 5 je v dolním indexu. Správně by mělo být mandelbrot_5.py
Asi to špatně pochopil nějaký markdown pro tučné písmo.

to se asi resilo tadyhle https://www.root.cz/clanky/rychlost-cpythonu-3-11-a-3-12-v-porovnani-s-jit-a-aot-prekladaci-pythonu/nazory/1132490/

Je to tak - to je "vlastnost" redakčního systému, kterému se sice předává HTML, ale potom to je přefiltrováno a podtržítka (resp. text za nimi) je předělán na dolní indexy.

Jediné řešení je podtržítka nepoužívat. To je sice pro mě schůdné, ALE - pokud použiju pomlčky, tak zase s tím má problém mypyc, protože při překladu ze jména souborů tvoří interní identifikátory a tam (v C) se pomlčky použít nedají.

V podstatě je to vtipné, že tu řešíme takové hluboké niternosti tech světa, a na druhé straně narážíme na "temný středověk", když není bezobslužně vyřešena tak základní věc jako zobrazení běžných znaků.

Zase bacha, složitost práce s textem už dosáhla až absurdních rozměrů. Je to tak multikulturní a multioborový problém, že jen největší korporáty světa na to mají k dispozici dost mozků.
Zbytek světa to jen tak nějak plácá a lepí, protože jim nic jiného nezbývá. A bude to jen horší a horší.