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...