Vlákno názorů k článku Zklamání jménem Aurora ukazuje na pokračující trápení Intelu od Heron - Tyhle historické spletité uličky jsou daleko širší. Můžete...

Tyhle historické spletité uličky jsou daleko širší. Můžete mít bezvadný procesor, ale když k němu nejsou programy, tak je k ničemu.

Vezmu jenom počet procesorů / jader. Někdy v letech 1997-2000 měl kámoš dva CPU (Abit BP-6 a dva celerony) a už tehdy programoval multithread programy. Já si koupil Core2Duo a následně Quadro hned jak to bylo možné. S příchodem 64b CPU jsem měl 64b OS (WinXP 64bit) asi jako jediný v republice.

Proč to píšu. Dodnes, tedy 20 let po té, je zázrak najít program, který využívá více než jedno jádro. Už na té střední škole před 25 lety jsme se bavili o tom, že výkon jádra možná neporoste tak moc, takže se to vykompenzuje počtem CPU. Když přišly první CPU atom, tak jsem snil o tom, mít doma na stole 512 atomů. Právě na tohle by byly dobré ty Intel Phi karty.

V SW světě na tohle dodnes čekáme. Ani programy, které mohou být multithreading levou zadní, třeba změna formátů obrázků a nebo jiných souborů (mám na převod 10 tis obrázků, tak to klidně může jet ve 32 vláknech). Ty programy jsou stále single thread. (A prosím neargumentuje tím, že si to v linuxu můžu snadno napsat, to já samozřejmně vím a dělám to tak, ale tohle není východisko.)

V době Buldozerů AMD doporučovalo dělat FPU výpočty na GPU. Velmi dobré doporučení. Ne, místo toho se tehdy nadávalo na AMD, jak nezvládá FPU operace. Místo, aby se to počítalo na kartě, kde je těch FPU jednotek tisíce.

Atd. atd. atd.

"V době Buldozerů AMD doporučovalo dělat FPU výpočty na GPU. Velmi dobré doporučení. Ne, místo toho se tehdy nadávalo na AMD, jak nezvládá FPU operace. Místo, aby se to počítalo na kartě, kde je těch FPU jednotek tisíce."

To je dobré doporučení nebo totální blábol, podle toho o jaké výpočty jde. GPU má tisíce _pomalých_ fpu jednotek a navrch platíte brutální latencí. Pokud nemáte velká data vhodná pro SIMT, tak si můžete výpočty na GPU strčit do špic.

Dále je třeba blbost paralelizovat program na převod obrázků, když můžete jednoduše pustit několik instancí toho programu nezávisle. Jednovláknový program je nesrovnatelně jednodušší na vývoj a škálovat se to bude možná ještě líp.
Kdybych měl psát nějaký převodní program pro BFU (ale jak často potřebuje BFU konvertovat 10k souborů?), tak budu z jednoduchého GUItka spouštět jednoduché převodní prográmky. Výsledek bude řádově jednodušší a spolehlivější, než kdybych měl něco paralelizovat sám.

Znáš programovací jazyk Erlang? Najdi si nějaké přednášky od jeho autora Joe Armstronga. To je příklad stylu programování, kdy se ani nepřemýšlí nad tím, že to běží paralelně, ono to prostě běží přirozeně paralelně.

Podobný styl jsem okopírovat do Golangu. Co lze paralelizovat, to se paralelizuje. Funguje to.

Já vlastně ani moc nevím, kde hledat problém. Možná je to v tom, že spousta lidí se našla v C, kde je fork a join, problém s hlídáním paměti a tak se raději vše píše singlethread, prostě pro jistotu. Jenže současně ti lidé ani neznají prostředky typu parallel nebo xargs v shellu, takže ani nevytváří snadno použitelné paralelizovatelné programy. A to ani nemluvím o možnosti pustit třeba něco na dalších strojích v síti.

Takže jsem se jednoho dne naštval a napsat si to (tehdy v pythonu, dneska v golangu) sám a můžu si pustit převod milionu souborů na všech procesorech, co mám v síti. (Opět, žádný takový program jsem v repositáři nenašel.)

A potom někdo napíše, že to BFU nepotřebuje. Ok no. Tak proto to 20 let nemáme.

Jenže Erlang nebo Golang opravdu nejsou tolik rozšířené. Navíc dělat desktop aplikace v Golang asi nebude ta pravá volba, Erlang netuším.

" ale když k němu nejsou programy"

Coz mimo jine vede k tomu, ze je Intel porad tim lepsim, protoze porad ma typicky lepsi vykon per jadro.

Mimochodem, ani to ze aplikace umi bezet na vice jadrech nijak neimplikuje, ze na nich pobezi rychleji. A to ani u aplikaci, o kterych si spousta lidi mysli, ze jsou vlastne zarnym prikladem paralelizovatel­nosti jako treba databaze.