Výkon vytváření vláken u 64bit aplikací

Na KernelTrapu se popisuje řešení problému, kdy jakmile přesáhne využití stacku 4 GB, vytváření vláken může trvat až 10 milisekund, což je nepřijatelné. Na vině je drobný hack, který zároveň zajišťuje 32bit kompatibilitu. Pro použití v glibc bude zaveden nový příznak, který problém odstraní.

19.8.2008 13:17 | Luboš Doležel (Doli) | Zajímavý článek

Komentáře

[David Watzke]

No já teda nevím... když si představím 4 GB ve stacku, poslední co by mě tankovalo je čekání 10 ms na vytvoření vlákna

[m1c4a1]

Až se budou velikosti aplikací běžně pohybovat ve stovkách megabytů, tak to oceníš.

[pasmen]

Až se tohle stane, bude něco špatně s jejich tvůrci...

[Profesor Hrbolek]

Jo ty budeš asi čistě uživatel svobodných aplikací, pro tvé info: už se tak stalo a do linuxu se to už taky začíná cpát.

[m1c4a1]

Tak to s takovou už teď - dřív se dělaly programy na pár bytů, dneska jsou to řádově kilo/megabyty. Prostě se víc využívá technologie, která je dostupná.

[Majkls]

No to by mě zajímalo, jaké čuňátko potřebuje 1GB zásobník, nicméně je dobře, že to je upravené. Je dobré říct, že mezi alokací na zásobník a pomocí (c|m)alloc je diametrální rozdíl. Doufám, že o něm víte.

[Michal Kubeček]

Proč hned mluvit o čuňátcích? Možná nečtu dost pozorně, ale v tom odkazovaném dokumentu to na mne nepůsobí tak, že by šlo o zásobníku jednoho threadu, ale o velikost zásobníku celkem. Je-li to tak, pak to nemusí vůbec znamenat čuněcí aplikaci, ale třeba extrémně velký počet threadů.

[mafo]

hmm ja nevim: calloc udela malloc + clear?

to ale nevidim jako problem ne?

[Luboš Doležel (Doli)]

calloc rozhodně nepoužívá malloc.

[Luboš Doležel (Doli)]

Kruci, spletl jsem si to s alloca.

[Andrej Herceg]

On tam píše o niečom inom. :)

Píše tam o alokovaní na zásobníku (napr. definovaním lokálnych premenných, alebo použitím funkcie alloca) s "klasickým" alokovaním pamäte pomocou (c|m)alloc.

[Mti.]

no tak uz mne nenapinejte. V zivote sem na AVRku nemel vic jak 2kB ram, tak to nevim, no Maloc sem tam "vedome" pouzil jen jednou, kdyz sem chtel vedet, kde zacina "volne" misto v ram... :-P

[*]

pekny priklad, jenze financni nekde stale jeste pouziva metriku lines of code na vyhodnoceni vykonnosti divizi a i podle toho se tvori jejich rozpocet...

[Cartman]

je to snadne prekrocit. Napr. klasicky rekurzivni quicksort miliardy prvku, v zavislosti na hodnotach pole, muze prekrocit 4GB stack. Pokud nekdo ma v pocitaci 64GB ram, jeho aplikace muze usoudit ze trideni 20GB pole by melo fungovat bez problemu. Ano, vim ze to lze udelat i ukladanim hodnot na heap misto stacku, ale dela se to prave proto ze na mnoha platformach je pouzivani stacku omezene (oproti heapu). Pokud se nekdo stara aby tomu tak nebylo v Linuxu, je to vyborne. Ne kazdy vytvari text editor nebo mail-klienta

[Luk]

Žil jsem v tom, že využití rekurze tímto způsobem je pouze doménou výukových příkladů, které mají za cíl ukázat, jak rekurze funguje. Už následující příklad obvykle ukazuje, jak rekurzi převést na iteraci

[Cartman]

a proc myslis ze "následující příklad obvykle ukazuje, jak rekurzi převést na iteraci" ? Protoze je zejemena na Windows, velikost stacku defaultne omezena. Zadny jiny duvod proc zneprehlednit program a zrusit rekurze neni.

[Luk]

Zadny jiny duvod proc zneprehlednit program a zrusit rekurze neni.

To není pravda. Důvodů je celá řada. V některých případech při rekurzi podstatně roste složitost, rekurze má obecně vyšší režii (neporovnávám s iteracemi řešenými tak, že se přialokovává paměť na haldě!), někdy se velmi obtížně ladí atd. Rekurzivní řešení je přehledné, to ano. Ale pro případy velmi hlubokého zanoření to většinou není to pravé ořechové.

[Cartman]

kazdopadne je to vec nazoru a je dobre ze 4GB stack problem je odstranen. Pravdepodobne se nato prislo prave v nejake implementaci rekurzivni funkce na vypocet nebo zpracovani cehosi.

[Michal Kubeček]

Znovu upozorňuji, že tady jde IMHO o celkovou velikost zásobníku, ne o velikost zásobníku pro jeden thread. Přeci jen 'ulimit -c 4194304' (nebo víc) má asi nastaveno málokdo.

[Ondrej 'SanTiago' Zajicek]

V některých případech při rekurzi podstatně roste složitost,

Coz ale vubec nesouvisi s pouzitim rekurze - pokud by se takovy program primocare prevedl na iteraci, tak by mel take velkou slozitost. (Pokud tedy slozitosti myslis casovou slozitost.)

[Luk]

Ano, je to tak. Neměl jsem na mysli přímočaré převedení na iteraci. Proto jsem napsal "v některých případech".

Ještě bych měl pro korektnost také dodat, že pokud je pro iterační algoritmus potřeba předem neurčené množství paměti, tak to znamená vyžádat si paměť přímo od systému (obejít správce haldy), což není zrovna příliš přenositelná záležitost.

[deda.jabko]

V některých případech při rekurzi podstatně roste složitost, rekurze má obecně vyšší režii

muzete se o tom rozepsat?

[Ladicek]

Jako implementátor Schemu přece tušíš o rozdílech mezi "běžnou" a tail call rekurzí

[deda.jabko]

no, prave proto se ptam.... mozna uz jsem z toho nejak zdeformovany... ale dosud jsem zil v domeni, ze iterace je specialni pripad rekurze... a pokud chce nekdo prevest ,,beznou'' rekurzi na iterace, obvykle se nevyhne pouziti nejake struktury (treba zasobniku ;-])

btw. nedavno jsem delal nejake optimalizace na rychlost a jednou z nich byla nahrada slozitejsich smycek ze ,,bezne'' rekurzivni funkce, proto me vyse zminene tvrzeni docela zaujalo.