Názory k článku Clojure aneb jazyk umožňující tvorbu bezpečných vícevláknových aplikací pro JVM (4.část - kolekce, sekvence a lazy sekvence)

vďaka za perfektný článok

"Na tomto místě je však nutné varovat před tím, že použitím imperativního způsobu zápisu algoritmů se například zhoršují možnosti překladače programovacího jazyka Clojure v optimalizaci překládaných programů tak, aby mohly běžet paralelně."

No a umi Clojure tedy opravdu udelat ten program paralelnim? Ja jsem zatim mel vzdycky pocit, ze jsou to takove marketingove reci - mozna nekdy v budoucnu to bude mit potencial nechat se paralelizovat. To same plati pro .NET v posledni verzi, kde sice jsou nejaka paralelni primitiva, ale - fakt je to uz k necemu? Jedine jazyky, kde bych tomu i veril (ze je kompilator/runtime dokaze automaticky paralelizovat) jsou Go a Erlang, ale jak je to doopravdy? Mozna by to bylo tema na clanek.

+1 Mě připadá, že když se na to podívám z pohledu překladače, tak se to přímo nabízí paralelizovat. Ale ať jsem pátral sebevíc, nenašel jsem, že by to měl někdo v praxi implementované. Dají se najít algoritmy nebo různé články, ale v praxi se to nepoužívá.

Podle mě automatická paralelizace hraničí s umělou inteligencí. Aby se to dělalo pořádně, ve většině případů bude třeba znát velikost instance (pod)problému, aby se nepoužíval kanon na vrabce a režie způsobená použitím paralelní verze algoritmu nebyla větší, než skutečné paralelní zrychlení. Jinými slovy, tohle se obecně dá dělat rozumně až při běhu.

Na druhou stranu, pokud se použijí třeba actory v jakémkoliv jazyce (nejenom v Erlangu), vede to k paralelizaci přirozeně a bez velké práce (podobně v Haskellu třeba `par` a spol.). Aby to ale bylo možné snadno ex post paralelizovat, hodí se mít na to kód připravený (referenční transparence apod.). Jinými slovy si nemyslím, že to jsou marketingové bláboly, na druhou stranu ale tu paralelizaci za člověka obecně nikdo neudělá.

Já si právě myslím, že actory nejsou cestou, která by se mohla nějak rychle prosadit, protože zatím prostě nejsou programátoři co to umí. A přitom ten koncept je implementovaný snad ve všech běžně používaných jazycích, ale používá se celkem minimálně. A právě se prosazuje spíš ta JIT cesta (viz. třeba diskuze pro javu 8 pro paralelní provádění for each cyklů nad kolekcemi).

Největší brzda je asi to, že prostě na desktopu není moc poptávka pro paralelizaci a pro enterprise nasazení je zase hit map-reduce apod., protože tam není brzda výpočet v procesoru, ale přístupová doba k disku.

Největší brzda je asi to, že prostě na desktopu není moc poptávka pro paralelizaci

Další problém je, že některé úlohy není možné normálně paralelizovat - jde to pouze spekulativně.

A přitom ten koncept je implementovaný snad ve všech běžně používaných jazycích, ale používá se celkem minimálně.

Například v .NETu jsou k dispozici jiné a lépe podporované nástroje, tudíž není IMO důvod používat actory.

Aby se to dělalo pořádně, ve většině případů bude třeba znát velikost instance (pod)problému, aby se nepoužíval kanon na vrabce a režie způsobená použitím paralelní verze algoritmu nebyla větší, než skutečné paralelní zrychlení.

V některých případech může kompilátor transformovat nested data parallelism na flat data parallelism, kde je velikost úloh podobná. Takto funguje Data Parallel Haskell.

S tim v podstate souhlasim, a proto jsem se na to take ptal, jestli uz to ty jazyky nejak skutecne umeji, nebo je to zatim spis teoreticka moznost (a v tomto smyslu jest take chapat to "marketingove reci"). A docela rad bych si precetl clanek, ktery diskutuje ty, ktere to umi.

Nested data parallelism implementuje z běžně používaných jazyků jen Haskell. Mj. pěknou přednášku o tom měl SPJ - video http://www.youtube.com/watch?v=NWSZ4c9yqW8 a slajdy http://research.microsoft.com/en-us/um/people/simonpj/papers/ndp/ndpslides.pdf

AFAIK ostatní běžně používané jazyky buď umí automaticky paralelizovat pouze triviální cykly anebo programátor musí určit, co a jak se má paralelizovat. Například vámi zmíněný .NET neparalelizuje automaticky nic, v knihovně jsou však k dispozici funkce jako AsParallel nebo Parallel.For, kterými lze kód snadno paralelizovat, nicméně je pouze na programátorovi, aby zajistil, že jednotlivé úlohy mají vhodnou velikost, což Data Parallel Haskell vyřeší automaticky.

Děkuji za článek.

Několik poznámek:
1) Smyčka while nepotřebuje 'do' a proto funguje také

(def a 10)

(while (pos? a)
(println a)
(def a (dec a)))

2) V definici vektoru
(def vektor ['a' 'b' 'c' 'd' 'e' 'f'])
ve skutečnosti vytváříte vektor symbolů a ne znaků, jak jste zřejmě zamýšlel.

Zápis 'a' vytvoří symbol a' - symbol s apostrofem na konci.

=> 'a'
a'
=> (class 'a')
clojure.lang.Symbol
=> \a
\a
=> (class \a)
java.lang.Character
=> (str \z \n \a \k \y \space \s \e \space \p \i \s \i \space \t \a \k \t \o)
"znaky se pisi takto"
=> (str "mezera" \space "tabulator" \tab " a odradkovani" \newline "novy radek")
"mezera tabulator\t a odradkovani\nnovy radek"
=> (print (str "mezera" \space "tabulator" \tab " a odradkovani" \newline "novy radek"))
mezera tabulator a odradkovani
novy radek

PS: Hezky to je vidět například takto:

=> (seq "znaky se pisi takto")
(\z \n \a \k \y \space \s \e \space \p \i \s \i \space \t \a \k \t \o)
=> (seq "\t \n\r")
(\tab \space \newline \return)