Stackless python (diskuse)

[Radek Miček]

Takhle se neustále načítají nové a nové tasklety s požadavky na webové stránky, takže program pořád něco dělá, místo aby vždy čekal 2 vteřiny na navázání spojení.

A to by nestačil CPython s nějakou knihovnou pro asynchronní zpracování?

[Bystroushaak]

V zásadě ano. Jenže ono by se to tak moc nelišilo a ve výsledku bych programoval skoro to samé, jen s tím rozdílem, že druhý kód by byl nepřehlednější a musel bych použít jiné knihovny, ne ty svoje oblíbené. Stackless je docela příjemná abstrakce pro programátora.

[sam]

Obavam se, ze ne GIL nelze obejit, musela by se prepsat vetsina kodu CPythonu.

Btw. pro takove pripady a nejen pro ne ocenuju genialni navrh Haskellu a vlastne i implementaci GHC. Nejen ze je trivialni paralelizovat, ale bezi to o rady rychleji.

[chrono]

Nebolo by dnes rozumnejšie používať greenlet (prípadne niečo, čo greenlet používa)?

[Bystroushaak]

Greenlet má jen kooperativní multitasking, pokud se nepletu.

[luky]

V cem je problem s 800 thready, GIL? Samotny Linux skaluje dobre a muzete si vytvorit desitky tisic threadu aniz by se to neja vyrazne projevilo v behu systemu.

[Bystroushaak]

Já jsem to ani moc nezkoumal, stačilo mi, že jsem musel provést hardreset jednou, poté co to sežralo všechny systémové prostředky tak dokonale, že pomohl až sysrq (jenže tam byla zábavná smyčka, která zase otevírala nové thready, takže proto hardreset).

[kralyk z abclinuxu]

Pokud si dobře vzpomínám, tak problém je v tom, že CPython nevytváří nativní (pthreads) thready, ale nějaké svoje vlastní a kód stejně běží v jednom threadu.

[Bystroushaak]

kód stejně běží v jednom threadu

Jo, tohle je jedna z bolestí pythonu.

[xkucf03]

Takže je pořád jediný způsob, jak využít vícejádrový procesor, spustit více interpretů Pythonu?

[Jakub Lucký]

reálně ano... Python k tomu má rozhraní jménem multiprocessing se stejným API jako thready...

Obecně se GIL považuje za největší problém CPythonu (referenční implementace Pythonu), se kterým se již roky marně bojuje. Třeba PyPy (alternativní interpreter) tímhle netrpí

[pavlix]

Nikoliv, ani tomu tak nebylo.

[Radek Podgorny]

cpython samozrejme vytvari native thready. problem je, ze kvuli gil muze spoustet pythoni kod jen vzdy v jednom z nich (v dany okamzik). pro paralelizaci veci mimo python (rozumej knihovny napsane v cecku) to slouzi skvele... ...a kdyz ne, tak mame multiprocessing.

[kralyk z abclinuxu]

Ok, dík za objasnění...

[pavlix]

To je o těch vlastních vláknech je velmi rozšířená fáma. Ve skutečnosti se jen používá globální zámek pro zpracování pythoního kódu.

[xm]

K čemu stackless v době kdy je tu gevent?

[Bystroushaak]

Je to založené na greenletech, tzn je to zase kooperativní, ne?

[Bystroushaak]

The greenlets all run in the same OS thread and scheduled cooperatively. This means that until a particular greenlet gives up control, by calling a blocking function that will switch to the Hub, other greenlets won’t get a chance to run.

Jo.

[pavlix]

To vadí?

[Bystroushaak]

Tak zrovna u práce s webem tě to nutí používat asynchronní moduly, nebo prostě budeš muset čekat, než se daná věc stáhne. A když už musíš používat asynchronní moduly, tak se to celé stává jaksi zbytečné.

Stackless ti dovoluje používat klasické moduly do té doby, dokud jsou napsané v pythonu a nejedná se o C API. Ty moduly ani neví, že běží paralelně. Já tak můžu používat moje oblíbené knihovny na stahování a parsování a nic dalšího neřešit, protože to za mě řeší Stackless.

[pavlix]

A když už musíš používat asynchronní moduly, tak se to celé stává jaksi zbytečné.

Právě naopak. Ve chvíli, kdy používáš asynchronní IO, to celé dávat smysl začíná.

[Bystroushaak]

Šlo mi spíš o to, že ve chvíli kdy používáš asynchronní knihovny, tak si vystačíš s čistým pythonem (můžeš používat generátory).

[pavlix]

Nějak nechápu, kam míříš.

Já si asynchronní službu představuju jako službu, jejíž základním kamenem je využívání neblokujících volání a hlavní smyčky za pomoci prostředků operačního systému pro čekání na vstup/výstup. Chápu, že asynchronní lze brát i v mnohem širším významu, ale v souvislosti s programováním různých síťových a systémových služeb a nástrojů, si s takto úzkou definicí vystačím a nepotřebuju k tomu preemptivní multitasking.

tak si vystačíš s čistým pythonem

K tomu si vystačíš i bez Pythonu, stačí ti C a pár systémových volání. Nicméně jak obecné C, tak obecný Python trpí tím, že na file descriptorech založené asynchronní knihovny mezi sebou nejdou vždy dobře kombinovat a už vůbec se dobře nekombinují s knihovnami, které používají vlákna, podprocesy a podobné prostředky.

Vidím to tak, že možnosty Pythonu i toho, jak se dneska používá C jsou na tolik špatné, že kdyby se tohle v obou jazycích vyřešilo (včetně interoperability mezi řešením pro C a Python), sníží se vstupní bariéra pro programování komplikovanějších aplikací v obou jazycích natolik, že bych se nebál to nazývat takovou malou programátorskou revolucí. Všiml jsem si, že v Pythonu už se o to nějakým způsobem snaží a chystám se zjistit, co v tomhle ohledu nabízí open source knihovny pro C.

[Mike]

Gevent umožňuje monkey patching všech standardních Python modulů (a v důsledku i externích modulů, protože patchuje takové základní věci jako socket, thread, select, os.fork, atp., aby běhaly ve skutečnosti přes gevent). Je extrémně rychlý (využívá event loop založenou na libevent, která na každé platformě využívá to nejlepší řešení jako backend - epoll na Linuxu, kqueue na FreeBSD, atp.).

Navíc má gevent skvělé jednoduché pythonic API, není to žádné monstrum jako třeba Twisted (ale dokáže s Twisted v případě potřeby spolupracovat). A na rozdíl od Stackless člověk nemusí mít speciální interpreter, je to normální modul do standardního CPythonu.

[JS1]

A co goroutines? To funguje ve srovnani s Stackless Pythonem jak?

[Bystroushaak]

S Go nemám zkušenosti.

[alfonz mucha]

A já si naivně myslel, že kvůli tomuhle mám vždy právě instalovat pypy > abych to nemusel řešit ;)

no nevadí... tak aspoň rychlé výsledky pro normální python kód.

$ time python tests2.py
('starting', 'prvni', 1383050839.110662)
('starting', 'druhy', 1383050839.677418)
('starting', 'treti', 1383050840.239811)
('ending', 'prvni', 1383050847.908535, '-', 8.79787302017212)
('ending', 'treti', 1383050848.091353, '-', 7.851541996002197)
('ending', 'druhy', 1383050848.176817, '-', 8.499398946762085)

real    0m10.093s
user    0m8.557s
sys    0m1.516s

$ time pypy tests2.py
('starting', 'prvni', 1383050858.987054)
('starting', 'druhy', 1383050858.987302)
('starting', 'treti', 1383050858.987473)
('ending', 'prvni', 1383050860.588778, '-', 1.6017239093780518)
('ending', 'treti', 1383050860.58912, '-', 1.601646900177002)
('ending', 'druhy', 1383050860.58933, '-', 1.6020278930664062)

real    0m1.982s
user    0m1.680s
sys    0m0.060s

Já to například dělám tak, že pokud jsou v cestě masivní výpočty, tak nejdříve testuji, jestli je to spustitelné přes pypy. Pokud jo, tak to obvykle dále neřeším. Další možnost beru threading a multiprocessing. Stackless vypadá také pěkně, ale není většinou součástí, takže se může těžko používat. Pypy například již často bývá.

[alfonz mucha]

ještě sem můžeme hodit rychlý výsledek pro python3

$time python3 tests2.py
starting prvni 1383051554.39305
starting druhy 1383051554.393192
starting treti 1383051554.393255
ending prvni 1383051565.460286 - 11.067235946655273
ending treti 1383051565.460516 - 11.067260980606079
ending druhy 1383051565.460628 - 11.06743597984314

real	0m11.192s
user	0m11.141s
sys	0m0.040s

[JS1]

Já to například dělám tak, že pokud jsou v cestě masivní výpočty, tak nejdříve testuji, jestli je to spustitelné přes pypy.

Je rozdil mezi concurrency (jak se tomu rika cesky?) a paralelismem. Viz prednaska.

Concurrency je o tom, jak strukturovat program, aby nemusel cekat na jine casti. Paralelismus je o behu na vice procesorech kvuli vykonu. Blogpost je o concurrency, vase reseni se tyka paralelismu.

[alfonz mucha]

Ok, jasně... to jsem si hned neuvědomil. Stále mi však přijde, že paralelní řešení může řešit problémy concurrency. Jasně ne úplně a ne všechny, ale obvykle to může být řešení dostatečné, ne? Nebo je to jinak?

[JS1]

No, ne vzdycky. Stackless byl tusim treba pouzit v nekterych hrach, kdy kazdy akter bezel ve vlastni korutine. Tam opravdu neslo o paralelismus, ale spis o jednoduchost programovani.

Me by zajimalo, jestli nekdo zkousel takto (na hru, nebo simulaci mnoha agentu) pouzit jazyk Go. Myslim, ze by se to mohlo hodit.

[Bystroushaak]

K pypy jsem se popravdě ještě nedostal, ale už včera jsem si ho na základě diskuze přidal do TODO :)

Stackless vypadá také pěkně, ale není většinou součástí, takže se může těžko používat.

Tohle je aplikace, která poběží jen u mě na serveru, nic co bych sdílel mezi více počítači, takže v tomhle konkrétním případě to není velká vada.

[Bystroushaak]

Support for Stackless and greenlets are now integrated in the normal PyPy. More detailed information is available here.

Pěkné!

[Filip Svoboda]

Tohle mi prijde mega uchylne.. proc nepouzit neblokujici sockety a hlidat je select()em? pripadne je vyhradit do jednoho vlakna...

[Bystroushaak]

Proč jo?

[Filip Svoboda]

+ vyhnes se ztrate vykonu pri prepinani

+ je to standardni vzor kterymu kazdej rozumi

+ nepotrebujes hackovat interpret, tj lepsi kompatibilita

- potrebujes neblokujici knihovny pro zrani io streamu

- jednu smycku v programu atd,..

navic podle me muze to stackless, protoze to bude zahackovany dost v jadru interpretu zpusobit nepekny chyby, ktery bude tezky odladit.

[Bystroushaak]

+ nepotrebujes hackovat interpret, tj lepsi kompatibilita

Přidával jsem to na začátek blogpostu - v pypy je Stackless by default, takže se nic hackovat nemusí.

+ je to standardni vzor kterymu kazdej rozumi

Jo, ale je to hnus (pro mě). A když máš náhodou pracovat s víc asynchronníma knihovnama najednou, tak se to začíná špagetovat. Nehledě na to, že některé knihovny asynchronní imho neseženeš (např. html parser).

+ vyhnes se ztrate vykonu pri prepinani

Ok, tohle beru. Ta ztráta není moc velká, ale u některých aplikací by to vadit mohlo.

navic podle me muze to stackless, protoze to bude zahackovany dost v jadru interpretu zpusobit nepekny chyby, ktery bude tezky odladit.

Tohle je problém, který budu řešit pokud na něj narazím, nemá smysl se nervovat něčím, co dost možná ani neexistuje.

[Filip Svoboda]

v pypy je Stackless by default

OK, chapu, existuje interpret co to ma v sobe.. pro me je python to, co se spusti kdyz napisu do shellu "python", a uplne nejradej mam interprety/technologie ktery fungujou kazdymu naprosto stejne, tj jednou je to "python", tak ma konstantni syntax, zakladni lib set atd.. co kus interpretu to original mi na pythonu z hlediska profesionalniho nasazeni vadi uplne nejvic

Jo, ale je to hnus (pro mě). A když máš náhodou pracovat s víc asynchronníma knihovnama najednou, tak se to začíná špagetovat. Nehledě na to, že některé knihovny asynchronní imho neseženeš (např. html parser).

async http server/klient jsem si musel napsat sam, opravdu je o takovy knihovny nouze (nebo spatne hledam), to je dost velka nevyhoda. kod kterej si takhle stvoris je ale porad 100% ve tvoji moci a nebude ti ho nic nikde prerusovat kdyz nema (samozrejme krome prepinani procesu v OS), tohle ocenis predevsim jakmile zacnes ladit urcity casti kodu pro high-throughtput nebo predevsim low latency response, tam to proste vadi (urcite to ale neni pripad bezneho web crawleru, apod,..)

Tohle je problém, který budu řešit pokud na něj narazím, nemá smysl se nervovat něčím, co dost možná ani neexistuje.

Me moje situace dodavatele prumyslovych reseni mne nuti vytvaret kod kterej nepada a jsem schopnej za nej smluvne rucit (tj ze kod pobezi a nevyskytne se v nem zadna chyba), proto cim vice veci mam v moci a cim mene veci je dynamicky alokovanych/zavislych/rozbitelnych, .. tim lip