CUDA/OpenCL a Debian

Založil Roman Horník, 07. 09. 2014, 00:00:46

Předchozí téma - Další téma

Roman Horník

Nazdar, jak jsem tak koukal do repa, co se tejče těchhle fičur (CUDA a OpenCL), repo nabízí prakticky jen desítky knihoven, pak programy Suricata, Pyrit a BOINC. A to je vlastně všechno. No, okrajově to umí použít Blender.
BOINC teda mám, používám ho jako přídavný topení, když mi je zima. Jak se rozjede dvoujádro přetaktovaný na 127% (dál je to kvůli limitu FSB procesoru nepoužitelný) a GPU, teplíčka je z toho dostatek.
A tak co s mejma 384 CUDA jádrama (GTX650)? Viděl bych jejich využití třeba při zpracování grafiky, videa (paralelní zpracování mnoha snímků najednou), ale taky i zvuku (několik kanálů naráz), jádro je může využívat tam, kde není potřeba řešit co nejnižší latence; něco takovýho už bylo, ale je to evidentně mrtvý. V serverech by se taky mohlo najít využití.
Ale proč nic takovýho nenacházím?
Možná se ptám zbytečně, když většina aplikací umí využít jen 1 jádro CPU, například Audacity, kde se jeden a ten samej filtr použije nejdřív na jednu stopu, pak na další, pak na další atd. - zářnej to příklad.
Debian Sid/Experimental 64bit + Mate Desktop Environment
* CPU: Intel i5 3570
* GPU: NVIDIA GTX650 1GD5
* MB: Lenovo IH61M
* RAM: 16GiB Deutsche Demokratische Republik 3 @ 1600MHz

čepi

K obecné diskuzi, programátoři jsou velmi líní a nevyužívaj (nebo je jednoduše neumí?) funkce/vlastnosti moderních GPU a CPU/APU už nějakou dobu (nezávisle na platformě). (Nejen) Paralelní zpracování pomocí CUDA resp. OpenCL se téměř vůbec nevidí v uživatelském softwaru (ať už na Linuxu nebo i Windows) ve kterém by mělo velmi účinné využití, je to škoda, při prezentací těchto technologií bývá naslibováno ale pak nikde nic. Snad se dá věřit že ty funkce jsou využívány v softwaru který se píše na míru zákazníkovi který si to zaplatí.
A jak jsi už psal, kolikrát je SW napsán tak že umí využít jen jedno CPU jádro/vlákno, přitom vícejádrové (2-16?) procesory tu máme už hodně dlouho.
Debian 9 Stretch --- in progress, XFCE
Notebook Acer Aspire TimeLineX 4830TG

Roman Horník

Teď jsem si přitápěl hezky dlouhým výpočtem, téměř 210 petaFLOPů (= 2.1×1017 FLOPů), trvalo to 52 hodin. Můj přetaktovanej procesor by to počítal 8-9 měsíců. To je ohromnej výkon, kterej ovšem můžu využít jen pro cizí potěšení a pro odpadní teplo.
Bohužel v Cčku prakticky neumím, teda v kódu se tak nějak vyznám, ale to je všechno, jinak bych upravoval stávající programy (zejména jejich knihovny, dělal k nim alternativy s co největším využitím OpenCL) a chrlil nový. Za ideálních podmínek by se 2 minuty práce smrskly do vteřiny, nehledě na ušetřenou energii (můj CPU má příkon kolem 70W, GPU 170W, ALE potřebná doba běhu je 120-130x kratší). Divím se, že zrovna tohle nikoho neláká, když dneska myslí zeleně každej, kdo má do prdele díru, neboť je to moderní.
Asi hodím výhružnej bugreport autorům Audacity, GIMPu, Inkscape, ImageMagicku a dalších, aby se trochu pochlapili a dali svejm chcípákům trochu elánu.
Debian Sid/Experimental 64bit + Mate Desktop Environment
* CPU: Intel i5 3570
* GPU: NVIDIA GTX650 1GD5
* MB: Lenovo IH61M
* RAM: 16GiB Deutsche Demokratische Republik 3 @ 1600MHz

Palo M.

AFAIK nie kazdy algoritmus sa da masivne paralelizovat. Ma to vyznam pre spracovanie velkeho mnozstva dat (rendering videa, analyza zaznamenanych radiovych signalov a pod.), ak skratka treba prehucat kvantum dat jednoduchym algoritmom. Akonahle je v algoritme vela podmienok/vetveni kodu, tak sa nevyplati GPU pouzit (napriklad aj v BOINC projekte SETI@home bol jeden typ jednotiek, ktore na GPU trvali prilis dlho a neoplatili sa). Okrem toho, prepisat algoritmus na masivne paralelny vyzaduje nemale usilie, vysledny program by mal byt usity na mieru konkretnej GPU aby bol naozaj efektivny (podla toho, ci je to Nvidia alebo ATI, kolko ma pamate, kolko ma vypoctovych jednotiek atd.), takze je s tym aj nemalo roboty. Sucasny stav je len vysledkom tychto faktorov (pusti sa do toho len ten, komu to za to usilie stoji - napriklad tie BOINC projekty, kde je tych dat naozaj obrovske mnozstvo a usetreny cas je vyrazny).

Pri viacvlaknovych (CPU) aplikaciach je to iny pripad, tam s prepisanim nie je az taky problem (netreba prerobit uplne cely algoritmus, akurat treba hodit casovo narocne podulohy do noveho vlakna a pockat si na vysledok) a aj sa to vo vacsej miere pouziva. Akurat sa neda ocakavat, ze sa uplne vsetci autori vrhnu na prepisovanie funkcneho kodu na viacvlaknovy, dost sa ich asi bude drzat zlateho pravidla "if it's not broken, don't fix it"...

Petr Krčmář

Můžete se přijít inspirovat na LinuxDays, bude tam HPC workshop.