O pythone a rýchlosti (diskuse)

[Šangala]

Pokud je doba trvání testu nějaké jednotky až stovky µs, tak tomu moc nevěřím, bo to ovlivňuje i silnější prdnutí tchyně ve vaně a každé spuštění vygeneruje jiné výsledky (jak v testu, tak ve vaně)…

[mirec]

Je to čas prerátaný na iteráciu, všetky testy bežali min 100 iterácií u najdlhšie trvajúcich po 100000 po najkratšie trvajúce.

[Šangala]

Furt nic moc (nejkratší celkem jen 0.01 sec), ale už je to trochu lepší .

[mirec]

Pardon ušla mi jedna 0, najkratší bežal 1000000.

[Šangala]

Tak to máme .... celkem .... 0.1 sec / nejkratší test…

[frdrx]

Hlavně se lidi nenechte navábit k předčasným optimalizacím.

[Šangala]

Pomalu přestávám na chybu předčasné optimalizace věřit, bo spousta věcí už je tak pomalá a náročná, že by se styl vývoje měl přehodnotit a neměli by se některé jazyky používat na některé věcí (zrovna u Pythonu jsem si už říkal, kurňa zahoďte to a použijte už radši Javu, a teď jak to vidím, tak to přehodnocuji a říkám, kurňa přeložte to a pořádně ).

[frdrx]

No nevím, ale na úrovni na které mi předčasná optimalizace přijde jako jedno nejškodlivějších chyb, kterých se dokážu dopustit.

[frdrx]

Mělo být:

No nevím, ale na úrovni na níž jsem, mi předčasná optimalizace přijde jako jedna z nejškodlivějších chyb, kterých se dokážu dopustit.

[pavlix]

+1

[Šangala]

S ohledem na kód nebo uživatele? :)

[frdrx]

Na kód, samozřejmě, což přináší výhodu i uživateli.

[Šangala]

Jo-jo - jen než si toho uživatel všimne, chvilku trvá

[frdrx]

Většinou si toho ani nevšimne.

[Šangala]

No právě, ale zas určitě všimne toho, jak „dlouho to trvá“.

[frdrx]

Jenom do chvíle dojde na již nikoli předčasné optimalizace.

[Ilfirin]

Pěkné pěkné. Jinak pro zajímavost, existuje nový py_to_c kompilátor nuitka. Už jsem s ním něco zkompiloval, ale běželo to stejně jako v cpythonu, tak jsem to zase zahodil. A pokud už bych chtěl opravdu brutal výkon, tak se nejslibněji jeví numba. Pokus je pravda alespoň desetina, co se o ní píše, tak zrovna právě na to matematické blbnutí je ideální.

[mirec]

Na také bežné matematické blbnutie je python celkom rýchly. Numpy je pekne optimalizované, používa vektorové operácie a s pomerne rýchlym backendom je fakt super tam, kde sa python používa len ako lepidlo medzi knižnicami. Nedávno so sa tak dokonca hral s OpenCV a spracovaním videa, ale nakoniec som to aj tak prepísal do C++ (nie kvôli výkonu, ale ako príprava na jeden menší článok).

[Ilfirin]

Tak pokud vím, tak ani numpy není záchrana, pokud člověk dělá algoritmy s velkým množstvím kroků. Což byl ukázkový případ ten fibonacci a proto tak krutý čas cpythonu.

[mirec]

To áno, záleží od typu problému. Ja sa väčšinou hrajem s obrazom (fotky / video) a tam je to takmer vždy o vektorových operáciách zliepaných trochou interpretovaného kódu.

[Seraph]

To s tou type inferenci bude zase přehnané, Haskell ji má kompletní. Taková scala se taky chlubí type inferenci, přičemž ji dokáže použít pouze u deklarace proměnné. RPython na tom nebude líp, pouze odhaduji. Jo, a tail call rekurze je v Haskellu škůdce. Způsobuje thunk leak a musí proběhnout celá, což díky call by need rekurze v Haskellu nemusí.

[mirec]

Ten thunk leak je jedna z vecí ktoré sa mi dosť na haskelli nepáčia (prekvapilo ma to u funkcií ako fold), ale vlastne to celkom vyplýva z lenivosti vykonávania.

Čo sa týka typov ... rpython (aspoň čo som si všimol) všetko kompletne prekladal na natívne typy, žiadne obaľovanie. Typ majú nie len premenné, ale aj polia (homogénne), tuple (pevná veľkosť, nemôže sa na jednom mieste vo funkcii vrátiť ("a", 1) a (1, "a"), položky musia mať rovnaký typ) ...

[Seraph]

Thunk leak vznikne když je použita tail call rekurze a nevynutí se pomocí funkce seq či bang patterns striktní vyhodnocení operací. Pak thunk leak nehrozí. Nejlepší je tail call rekurzy nepoužívat vůbec (pokud se v tom člověk moc neorientuje). A když by nám hrozil stack oveflow, tak si prostě zvětšíme limit pro stack. Samozřejmě například u funkce length (a podobných) je výhodnější použít tail call rekurzi se striktním vytuněním. Částečné výsledky funkce length jsou k ničemu, takže správně napsaná tail call rekurze nenese nevýhody.

[Seraph]

Kouknul jsem se do zdrojáků Prelude na funkce z rodiny fold. Jsou tail call rekurzivní a spoléhají na GHC strictness analizer. Který ne vždy detekuje místo kde se hodí vynutit striktní vyhodnocení. Takže z toho důvodu jste měl thunk leak při použití fold{l|r}. Řešení je napsat si vlastní verzi funkce fold{l|r}, jedná se o 3 řádky, takže to ani nezdrží.

[lmbot]

foldr negeneruje thunky, takze smysl ma psat jen striktni verzi foldl, pokud je potreba vyhodnocovat z leva.

Zavrhovat (TC) rekurzi je nesmysl, jen je potreba si uvedomit jaka struktura rekurzivnim volanim vznika a podle toho se zaridit - aplikaci striktniho vyhodnoceni na parametr(y) a/nebo v kombinaci s guard rekurzi.

[lmbot]

Zvysovat limit zasobniku je cesta do pekel, pokud neni jednoznacne znama velikost mnoziny nad kterou se funkce vykonava. Staci pak vetsi objem vstupnich dat a k preteceni stejne dojde.

Pokud k tomu neni hodne dobry duvod, tak je lepsi na vhodnych mistech vynutit predcasne vyhodnoceni nebo upravit algoritmus a vystacit si s vychozim stackem. Velkou cast optimalizace zvladne i prekladac GHC, ale nelze se spolehat ze vyresi veskery nevhodne napsany kod.

[pavlix]

Má akési objekty, ale plnohodnotné OOP ako smalltalk to nie je.

Konkrétně?

[mirec]

Zapuzdrenie

[pavlix]

Zapouzdření je věcí návrhu aplikace a lze v Pythonu implementovat a dokonce k tomu existují zavedené zvyklosti. Jediné, co Python neumí, je vynucení dodržování toho zapouzdření, ale umělá omezení není něco, o čem bych se chtěl u jazyka typu Python bavit.

[mirec]

Nič to nemení na tom, že skutočné vynútené zapuzdrenie nemá. Mne to samozrejme nevadí, dokonca sa mi páči, že nie je striktne OOP / striktne funkcionálny ... jednoducho podľa mňa celkom dobre vybraný mix kadečoho.

[pavlix]

Nič to nemení na tom, že skutočné vynútené zapuzdrenie nemá.

To ovšem tvůrce pythoních programů nijak neomezuje, naopak jim to umožňuje dělat věci, které by jinak dělat nemohli a nejspíše ani neměli. Ale to je obecná vlastnost pythonu, že součástí jeho návrhnu není ochrana proti nekompetentním programátorům.

Nicméně tato vlastnost (volný přístup k privátním datům) lze podle mě implementovat i pro libovolný jiný jazyk a i se to tak pro účely debuggerů dělá. Stejnětak není problém přidat kompilátoru volbu, aby zapouzdření nevynucoval.

Řešení, které používá python, vede k tomu, že se stírají technické rozdíly mezi standardním během, testováním a debugováním. Samozřejmě každá sranda něco stojí a toto rozhodnutí má i své nevýhody, jen podle mě nespočívají v tom, že by byl programátor jazykem nějak omezován.

[JS1]

Pokud bys tak stal o to vynucene zapouzdreni (nechapu proc, ale dejme tomu), muzes si tusim celkem bez problemu napsat metatridu, ktera ho vynuti.

[Seraph]

Díky GC není predikovatelný okamžik zavolání destruktoru objektu. Tím pádem není možné použít RAII, což je unikátní vlastnost daná objektovému paradigmatu. On vlastně ani ten destruktor není třeba v OO jazyce s GC...

[pavlix]

To je pravda a vcelku očividně se toto pythoní API snaží dohnat podporou with. Na druhou stranu tvrzení, že je RAII vlastností objektového paradigmatu podle mě narazí na to, že různí lidé chápou objektové paradigma různě a to nejčastěji s ohledem na svůj oblíbený programovací jazyk.

[pavlix]

Mimochodem, používá smalltalk RAII, když už jsme u toho?

[x]

Na druhou stranu tvrzení, že je RAII vlastností objektového paradigmatu podle mě narazí na to, že různí lidé chápou objektové paradigma různě

Příkladně Alan Kay: OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. Kde se v tom skrývá RAII fakt netuším.

[rADOn]

Mě python dovedl ke stejnému pohledu. Když chci poškádlit céčkaře nebo Javisty tak jim říkám že v těch jazycích nejsou objekty ale jen tečky ve jménech

[Seraph]

Tak jako funkcionalni paradigma ma unikátní vlastnost teoreticky implicitního paralelismu bez synchronizace. Tak OOP ma takřka zdarma management zdrojů.

[Michal]

A co cython? Osobně vždy vytvořím většinu kódu v cpython a pak těch pak řádku kódu co mají běžet rychle přepisu do cython a s trochou snahy dostanu výsledky na úrovni C++. I když rpython vypadá taky zajímavě

[mirec]

RPython nie je moc známy pretože je to interný projekt PyPy určený na implementáciu interpretovaného jazyka. Ja som ho zneužil na trochu iné veci hlavne zo zvedavosti a chcel som ľuďom tak trochu predstaviť práve tento projekt lebo moc sa o ňom nepíše a pritom je to najrýchlejšia implementácia pythonu kde nie je potrebné zadávať hinty.

Samozrejme cython je vďaka kompilácii kritických častí rýchlejší len ... treba dopísať hinty a odekorovať.

[Ilfirin]

A v tom je právě (opakuji se) kouzlo numba, která dovede být rychlejší jak cython bez toho, aniž by se kod jakkoli optimalizoval na C. Takže si osobně myslím, že Cythonu zvoní hrana (ve smyslu rychlostní optimalizace, jako nástroj na tvorbu rozšíření samozřejmě nemá chybu).

[pavlix]

bez toho, aniž by

Ale fuj.

[lmbot]

S Cythonem jsem si kdysi hral, ale vidim ze podobne jako Numba to je zakryvane zoufalstvi (jako predzahradky ). Dokaze optimalizovat jen podmnozinu pythonu, u cisel vetsich nez uint64 se stejne pouzije pythonni kod (ktery vola gmp) a pomale volani funkci a omezeni behu jen na jedno vlakno zustava. Ma smysl jen u omezenych pripadu pri vypoctech, ktere se pokud mozno provadi jen v ramci jedne fce/metody.

To uz je rozumnejsi misto CPythonu pouzit Jython nebo PyPy, ale co jsem mel moznost testovat, zatim o moc lepsi vysledky nedavaji, nekdy dokonce i horsi nez CPython. Dynamicke typovani ma proste svou dan, kterou nelze nezaplatit.

[henkye]

máš špatně název článku - je tam protimluv

[Bystroushaak]

Nigga please.