Názory k článku Programovací jazyk LISP a LISP machines

No mělo by se na to jít naopak, ne procesor vybavit pamětí, ale paměovou buňku vybavit procesorovou funkcionalitou. Stav paměťové buňky by pak závisel na jejích předchozích stavech. To by pak bylo přirozeně paralelní paradigma.

To je podobne pristupu, ktery se pouzival u transputeru – tam se vlastne jednalo o mikroradic, ktery byl navic vybaven komunikacnim rozhranim a specialnimi instrukcemi pro komunikaci se sousedy. ta komunikace je totiz skutecne hodne dulezita, vice nez vypocetni vykon.

1) tak to je otazka, na kterou mozna odpovi docela velky boom v paralelnich systemech postavenych o uroven vyse (=clouds), kde je uzlem nejenom procesor+pamet, ale vlastne cely pocitac, tazke procesor+pamet+dis­k. Spis bych rekl, ze tech neparalelizova­telnych uloh je malo a problem je hlavne v nasem pristupu k programovani a zavislost na stavajicich systemech a technologiich,

2) viz 1

3) urcite, to je samozrejme zapotrebi resit a neni to vubec trivialni, spis naopak – kdyz se tady udela chyba, tak se bud paralelni uloha „serializuje“ (ceka na resource) nebo dojde k nejake nepekne veci (deadlock, starvation)

prave z duvodu 1)2)3) si myslim, ze se v budoucnu budou cloudy programovat mozna v necem podobnem *LISPu (asi to bude mit jinou syntaxi, kdyz dnes leti XML-like jazyky, ale principialne se to asi bude podobat)

Ono paralelizovat lze prakticky vše, jen se na to musí jít jinak než imperativně. Bohužel, možná je to setrvačností, ale neimperativní myšlení je pro mnoho lidí problém. Na druhou stranu imperativní programování možná bude brzy tak hrozně neefektivní, že vznikne velká poptávka po jiných paradigmatech, což tento stav může změnit.

Tak když mi poradíte, jak zapojit neimperativní programování do řešení diferenciálních rovnic, byl bych povděčen.

Diferenciální rovnice řešit bohužel neumím, ale jsem přesvědčen, že solver psaný například v haskellu by mnohé napověděl.

Neodpustím si narážku na červeného trpaslíka:
Rimr: Ale jaký je rok:
Holy: K tomu potřebuji více údajů.
Rimr: Jako třeba?
Holy: Hodil by se letošní kalendář.

Tady jde o to, jak neimperatinvě zapíšeš to, že po sobš dosadíš asi tak do miliónu vzorečků, kde jeden jasně navazuje na druhý. A bude nabude to jen hraní si pro hraní?

No, obycejne diferencialni rovnice skutecne dobre paralelizovat nejdou, to je pravda. Ale mozna staci podivat se na ten problem z vyssi perspektivy, a pak to muze byt paralelizovatelne lepe. Napr. skutecny problem je, ze se pocita cely soubor ruznych reseni. Tuhle ulohu je uz mozne paralelizovat.

No, já mluvil spíš o parciálních diferenciálních rovnicích. Tam se paralelizovat dá, ale metody výpočtu jednoduše paralelizovatelné jsou bohužel ty nejpomalejší. Pokud se na to kouknu z hlediska praktického použití – dělí se na dvě verze: buď se spočte jedno řešení, které pak analyzuje projektant, nebo je to součást nějakého optimalizačního procesu. Jestli ten paralelizovat jde, nevím (nemám zkušenosti). Jednoduše se daly paralelně řešit lattice gas cellular automata, aly ty mají omezenou použitelnost. Takže zbývají lattice boltzman models, ale použít je na složitější materiály je stále trochu fyzikální magie.

Tak nějak, přijde mi, že pan Program zatím moc reálných úloh nenaprogramoval (no offense).

Pokud pominu pár úloh pro funkcionální zpracování přímo dělaných, tak většinou je napsání „paralelně“ mnohem složitější ⇒ při stejných nárocích na spolehlivost dražší. A spolehlivost je dnes mnohem větší problém, než rychlost. A když už jde o rychlost, opět je větším problémem přenos dat z disku, než vytížení CPU. Samozřejmě jak kde, u určitých druhů vědeckých výpočtů je to zcela jistě naopak, ale v „business“ sféře si troufnu tvrdit, že je to vpodstatě všude stejné.

Hmmm, servrovým aplikacím věřím. Ale například vědeckotechnické výpočty řadíte do minority, nebo jste takový géniu, že je mu tam paralelizace a message passing jasný? Mně totiž tam přesně přijde přirozené sekvenční zpracování. Napřed spočítám jedno a pak druhé. Mimochodem v té vědecké práci je zrovna příklad velké daně za paralelizaci. Administrativa message pasingu zabere 90% času vědce.

Ano, v serverech (typicky webovych serverech) jsou ty ulohy paralelni z podstaty. A presto poptavka po nejakych extra masivnich paralelnich masinach pro tyto ucely moc neni. Takze problem bude asi jinde ;-)

Zrovna v tomto oboru to vypada no docela dobry kseftiky :-) Ono to opravdu chce definovat paralelni masinu – je to neco jako CM-5 s blikajicimi cervenymi LEDkami vsechno v jedne skrini (uvnitr jsou bezne „komoditni“ procesory) nebo nejaky cloud z milionu „komoditnich“ PCcek? Proste se jen zmenilo chapani slova uzel/node, dneska je to cele PCcko, takze se paralelizuje i ten zminovany pristup na disk.

Erlang je prece taky funkcionalni jazyk ne? Dokonce se snazi o minimalizaci side-efektu, jeste vic nez Lisp.

Tak proti tomu bych se ohradil (vzhledem k tomu, že jsem například vyvýjel pro Standforskou univerzitu), ano z diferenciálních rovnic si toho už moc nepamatuji (nikdy jsem to nepotřeboval). Ale problém je v něčem jiném. Pořád se tady točíte kolem stejné věci. Většina algoritmů je psána v imperativním stylu a většina lidí si to ani neuvědomuje. Vy chápete programování ve stylu: „Teď se udělá tohle, pak tohle…“ To je imperativní přístup a tam se objevují problémy s obtížnou paralelizací a taky spolehlivostí. Funkcionální paradigma je paralelní implicitně, protože tam je jasné, co je na sobě závislé a co se může vypočítat paralelně.
Ještě jednou to zopakuji funkcionální programování se neparalelizuje žádnými příkazy ve stylu vytvoř vlákno, či pragmaty, nebo podobnými věcmi (např. MPI), tak už to těmihle tvrzeními laskavě nevyvracejte.

Nevyvracím Vám, že jsou problémy, které se dají pohodlně zapsat neimperativně. Ale tvrdím, že jsou problémy, které se paralelizují obtížně. Třeba stavba domu. A jsou to bohužel velmi výpočetně nákladné problémy.

Ale ono tech paralelizovatelnych uloh je praveze dost, akorat na soucasnem hardware je nema cenu realizovat. Stejne jako nemelo cenu realizovat paralelni rendering v dobe, kdy graficke karty mely jedno GPU. Dneska s prokladanim apod. to uz neni problem, naopak je to vyzadovano.

Samozrejme souhlas, ze resit na soucasnych jazycich paralelni algoritmy chce lepsiho programatora, ale vsak oni se to budou muset naucit. Kdyz nastoupilo OOP, taky nakonec vsichni presli z proceduralnich jazyku na jejich OO-nasledovniky (i kdyz pri pohledu do kodu to nekterym trvalo dele :-)

A u tech procesu, ktere maji bezet paralelne se to jiz dnes resi treba jiz zminenym cloudem, load-balancingem atd. atd.

Ja programujem v DataFlow jazyku LabVIEW.

A s paralelnym programivanim nie je problem.
Ale samozrejme, ze ked chces poslat data z jedneho „vlakna“ do druheho tak musis pouzit queue alebo semafor.

Celou dobu si rikam neprispeju a neprispeju, protoze nic konstruktivniho k veci nemam, ale toto je takova blbost, ze musim. Ne – paralelizovatelnost je vlastnost algoritmu, runtime neruntime, spousta uloh je proste neparalelizova­telnych (oplodnenim 9 matek neziskate dite za mesic)