Flame o smysluplnosti OpenCL

[Al]

[Fila]

Ne, sorry, ale celou tu dobu tu pusobis tak ze je ve skutecnosti ten spor o tom, ze vyvojar klikacich systemu nechape, ze jsou systemy, kde je zasadni rychlost vypoctu. Systemy, kde ma clovek zcela opravnene radost, kdyz neco nizkourovnove zoptimalizuje (necht je to treba spravnym pouzitim lokal promennych), protoze treba pro vypocetniho chemika je sakra dulezite, jestli se mu neco zadokuje za rok nebo za mesic, stejne jako je dulezite jestli prehravani 4k videa bude bezet 3fps nebo 30fps. Vec osobnich preferenci to neni, takoveto problemy proste volaji po nizsich jazycich, programovat je ve vyssich se bez vyznamne ztraty vykonu neda (pokud jen nelepis volani knihovnich funkci, cimz se ale rozhodne kazdy problem vyresit neda).

Existuje tuna prakticky orientovanych problemu, ktere vyzaduji zabyvat se nizkourovnovym kodem a pokud to nevidis, jen tu proste demonstrujes svou omezenost.

[igor]

Je vtipné, jak jsi začlenil tu KSČ k výroku, který právě kritizuje mj. to, že něco takového může k něčemu jako KSČ vést. Byla to reakce na něco, s čím se osobně často setkávám (od diskuzí na internetu přes lidi z mého okolí až po vysokou školu) - rozdělení programování na to správné řešící problémy reálného světa a na "dělání blbůstek". Dělají to často lidé, kteří opovrhují čímkoliv low-levelovým, při vyslovení slova software si jako jeho jádro vybaví databáze a SQL dotazy apod. Rádi si přivlastňují pojem "reálný svět" jako ty prý fakt skutečné reálné problémy lidstva jako právě vyplňování formulářů, evidenci zboží, informační systémy firem atd. Všechno tohle jsou záležitosti, které se v lidské společnosti vyvinuly a často by ani nemusely existovat.

Reálný svět ale pochopitelně zahrnuje naprosto vše - formuláře, zvířata, molekuly, galaxie, počítačové hry, hardware na kterém musí běžet databáze, programátory hrající si s asm apod. Proč je ten diskutovaný pohled omezující, je asi jasné. Nebezpečný je proto, protože ten trend je fakt hodně silný a pokud by mu všichni podlehli (což se samozřejmě nestane), tak třeba budeme mít úplně boží formuláře, ale za nějakou dobu to budeme moci na této planetě zabalit - buď nebudeme schopni vyřešit nějaký akutní problém nebo prostě lidstvo pod tíhou "formulářů" zdegeneruje. A rozhodně je lepší umět obarvit proužky než to neumět.

Je mi jasné, že snad všichni, co si to přečtou, mě budou považovat za magora, ale budíž Jinak ještě ale hlavně musím dodat, že podle tvého dalšího příspěvku nejsi z těch lidí, o kterých mluvím.

[pcmaster]

Prosim vas, Fila, Ondrasej, niekto, rozdelte toto vlakno, pretoze je velka skoda, aby sa realny problem s OpenCL a jeho mozne riesenia zasrali flamewarom. Potom sem ludia s OpenCL chodit nebudu
_________________
Off-topic flame-war addict since the very beginning. Registered since Oct. 2003!
Interproductum fimi omne est.

[Fila]

OK, jdu to vyzkouset (ac mam moderatorske prava, nejak aktivne nemoderuju).

Ono vubec pritomnost vlakna o OpenCL v 3D API je trochu divna, mozna bysme meli zavezt paralelni programovani jako extra sekci, jinak je to spis do sekce Obecne.

[Al]

Jo, taky jsem pro úklid a taky bych to dal do jiné kategorie než 3D. Vždyť šlo o sečtení deseti proměnných.

[Al]

[Fila]

Tak zase kdyz ja napisu nekolik docela zasadnich argumentu pro OpenCL a obecne smysluplnost nizkourovnoveho programovani, tak ty me prispevky pro jistotu ignorujes.

[Mem]

[Al]

Jj, přesně jak říká Mem.

[Fila]

Hm, tak tuto implicitni informaci jsem fakt nerozpoznal -- nejak su zvykly, ze se diskutujici vyjadri bud pro, nebo proti, nebo se tvari ze nic "neslysel" (holt sitova komunikace -- pokyvat hlavou je treba v textu ).

Krom toho nektere Alovy reakce me prisly ze zas moc na vedomi to co jsem napsal nebral.

[VladR]

Vsetko je to otazka realnych potrieb.

Ked sme potrebovali rychslo sparalelizovat kod, tak som bol sakra vdacny za to, ze mame OpenMP, lebo s niekolkymi riadkami kodu to zrazu bezalo neporovnatelne rychlejsie na octa-core.
V tom je OpenMP genialne - clovek len vlozi do kodu par riadkov kodu a whoops.


Pokial ale biznis preukaze potrebu ovela rychlejsie beziaceho kodu (myslim, ze nie je potrebne vysvetlovat preco - cas je drahy, servre su drahe, ...), vtedy panboh zaplat za OpenCL / Cuda. Netvrdim, ze by som sa hackovnaim v OpenMP neprbilizil k vykonu OpenCL, ale tu kontrolu tam mam proste vacsiu (vratane prilezitosti chyb, pravdaze).


A nikto mi nevyhovori, ze nie je cool mat v CVcku tieto dva buzzwordy

[Marek]

OpenCL pro CPU ještě automaticky vektorizuje (typicky SSE3), takže se o to programátor nemusí starat. Jestli je to vektorizace jen v rámci jednoho kernelu nebo jestli běží 2-4 kernely vedle sebe na jednom jádru na celé šířce SSE registrů, to už přesně nevím, ale ze samotné podstaty toho programovacího modelu se takové optimalizace přímo nabízí.
_________________
AMD Open Source Graphics Driver Developer

[Fila]

A ne jen vektorizace, dekompozice na jemne thready sdruzene do vetsich celku pracujicich nad lokalni pameti zase pro CPU generuje pekne cache-koherentni kod.

[Al]

Je to tak, ale mluvíte tu o okrajových případech. Většinou největší problém je stihnout vývoj v termínu a i když třeba web studijní agenty stag je pomalej jak prase, kdyby to dělali v OpenCL, běželo by to teda asi možná 8x rychlejc, ale bylo by to hotové tak 2030...

A jde i o hry. Uvidíme, jak dopadne lednová soutěž v Praze. Já tipuju, že lidi, co použijí high level nástroje, ať už to bude Flash nebo cokoliv jiného, tam vám pokoušejícím se to vyhrát s tím OpenCL, prostě natrhnou prdele. Ale good luck!