LUDO: zajímavé by bylo vyzkoušet, jak ta paralelizace dopadne v případě, že podmínka v tom cyklu je nějak složitější, než jen prosté počítadlo. každopádně dík za inspiraci, konečně sem někdo po několika týdenní flamewar vnesl nějaký ontopic :-)

LUDO: částečně máš pravdu, že vytvoření threadu má režii... neřeší tohleto právě ty go-routines?

tak mi napadá, že velká frajeřina by vlastně byla napsat v C kód, který recykluje již jednou vytvořená vlákna. normálně, po dokončení threadu by tehle thread nezanikl, neukončoval se - ale čekal by na nějakém semaforu, až se mu předá pointer na funkci, kterou má dále vykonat. takže by se nepracovalo přímo s phthreads, ale runtime by spravoval nějaký pool threadů (jako to dělá většina aplikací s podporou multihtreadingu, typu Apache)

začíná mi to do sebe v hlavě docela zapadat (stejně mi vycházelo, že ten můj highlevel zdrojový kód bude z řady důvodů překladač do C muset rozkrájet do řady automaticky generovaných funkcí, protože C prostě nemá nic jako anonymní funkce nemá... stejně tak všechny lokální proměnné budou ve strukturách, na které půjde předat pointer, apod.).

je pravda, že už se to celé začíná trochu podobat operačnímu systému :-) Jestli to OpenML dělá přesně takhle, tak je to dost zajímavé... ale v tom případě by stálo za to srovnat výkonost kódu který paralelizuje OpenML s tím mým :-)

LUDO: tak na druhou stranu, napsat paralelně na stdout 2x Hello World není moc praktický příklad paralelizace, obávám se :-) většina reálných algoritmů bude pracovat s nějakými vstupními daty, a i matematické modely, které teoreticky žádná vstupní data nepotřebují a pouze něco generují, se musí minimálně dohodnout, kterou část modelu generuje které vlákno.

můj příklad, kdy si vyžádáš paralelní zpracování prvků seznamu, je podle mě nejjednodušší možný. Akorát ten OpenMP příklad, který to rozdělí právě na dvě vlákna a polovinu intervalu, mi přijde nepraktický ... takhle jsem o tom přemýšlel celá léta, až mi došlo, že je to právě blbost.

většina kontejnerových struktur (nejhezčeji to má udělené právě ten Python), většinou nabízí dvě metody: "vezmi první prvek" a "vezmi další prvek" (hezkým příkladem je nějaké to otevření souboru a jeho čtení, stejně tak otevření socketu a jeho čtení, může jít ale i procházení dlouhého stringu v paměti...). Přičemž ne všechny kontejnery jsou schopny jednoduše zjistit "kolik toho je" - u spousty typů datových struktur musíš prostě projít všechny prvky a spočítat je, a někdy to vychází z logiky věci (např. tabulka v databázi může být na jiném serveru, apod.). Jindy se informaci "kolik toho je" vůbec nemusí vyplatit věřit (viz slavné Microsoftí bugy, které byly vzhledem k microsoftímu přístupu ke codeřině nevyhnutelné).

Takže moje myšlenka je, že právě vůbec nemusím dělit nějaké intervaly na předem známý počet intervalů... ale můžu jednoduše každý nový prvek posílat do nového vlákna, dokud mi nedojdou resourcy (možná to ostatně OpenMP dělá takhle, co já vím...). samozřejmě je tady otázka, jakou má start a konec vlákna režii.. protože v případě, kdy je samotný krok triviální a CPU čas žere to samotné procházení intervalu, by se mi doba běhu mohla prodloužit, místo zkrátit...

tohle ale všechno může právě řešit runtime! to místo, na kterém vzniká nový thread, si může samo změřit, jak dlouho thready běžely a jestli režie spojená s paralelizaci program zrychlila nebo zpomalila. někdy se to prostě nevyplatí (např. když úzké hrdlo jsou I/O operace).

samozřejmě kolem toho bude trocha přemýšlení. podívat se, jak to dělá OpenMP, by určitě bylo užitečné. a dokonce ten C mezikód, který budu generovat, může využívat to OpenMP, když se ukáže, že to dělají efektivněji než cokoliv, co bych vymyslel sám...

KEJML: tohle jsem neznal a je to velmi zajímavý!
OpenMP - Wikipedia
https://en.wikipedia.org/wiki/OpenMP
spustit všechno "co nejvíc paralelně" bez dalšího zadání mi nenapadlo, že bych potřeboval, ale svým způsobem, pro nějakej velmi masivní a současně velmi snadno paralizovaelnej výpočet.. hmm... až na to sraní s mutexama, apod.

jinak pojem https://en.wikipedia.org/wiki/Embarrassingly_parallel jsem neznal, a je to popravdě přesně ten případ, který jsem se tu snažil popsat - některé algoritmy jsou zcela zjevně paralelizovatelné velice přímočaře, bez nutnosti přemýšlet o re-entrantnosti, semaforech a takových věcech. přesto řada dnešních jazyky vícevláknovost často buď nenabízí, nebo nemá jednoduchý nástroj, který by byl aspoň ekvivalentní tomu, když si třeba v unixovém shellu vyžádám spuštění něčeho "na pozadí".

nejvíc mi zaujala jednoduchost paralelizace v go, tzn. co se týče "xjazyku" (což je vlastně jen nepodstatný syntaktický třtinový cukr), mělo by jít o mashup pythonu a intuitivních instrukcí pro triviální paralelizaci, jakou má třeba to go.

(jestli mnou zavedená specifikace jednou bude akceptována coby Python block 4, proč ne :-) spíš nebude, ale člověk musí celý život něco zkoušet, než umře o samotě a zapomenut...)