Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Milfaus 04. 08. 2017, 00:27:01
-
Ahoj,
chvíli jsem to nesledoval a teď potřebuji něco celkem rychle.
Jaký projekt se prosadil pro výpočty na GPU?
Mám pole cca 90 mil * 90 mil prvků a potřebuji nad tím provádět bitové operace, sčítání, odčítání, rotace, porovnání.
Můžu vůbec GPU pracovat na úrovni bitů na GPU?
Než přišly ASIC, tak se na GPU těžilo ne? Tak by to mohlo jít.
CUDA je sázka na jistotu nebo se prosazuje OpenCL?
Naprasím to v C# (nebijte mě prosím).
-
Ahoj,
chvíli jsem to nesledoval a teď potřebuji něco celkem rychle.
Jaký projekt se prosadil pro výpočty na GPU?
Mám pole cca 90 mil * 90 mil prvků a potřebuji nad tím provádět bitové operace, sčítání, odčítání, rotace, porovnání.
Můžu vůbec GPU pracovat na úrovni bitů na GPU?
Než přišly ASIC, tak se na GPU těžilo ne? Tak by to mohlo jít.
CUDA je sázka na jistotu nebo se prosazuje OpenCL?
Naprasím to v C# (nebijte mě prosím).
Mám pocit, že vývoj OpenCL poslední dobou trochu vázne, ale pořád je to nejobecnější API. Na Applu běží dobře (=pekelně rychle) Metal. Jinak když je dat příliš (tj. kopírování na GPU zdržuje nebo se nevejdou), stačí někdy nějaká verze AVX, záleží na konkrétním výpočtu. CUDA je samozřejmě dobré řešení, ale jen pro výrobky jedné firmy.
-
cuda sa oplati ak netreba za kazdym kopirovat nove data na GPU;
napriklad nasobenie matice s vektorom : pokial zostava matica na karte a kopiruje sa len vektor novych dat je to naozaj zrychlene;
akonahle by sa mala za kazdym kopirovat aj ta matica neoplati sa to ...
treba lepsie popisat tu ulohu : hlavne co sa ma pocitat a ktore data sa menia a ktore mozu zostat na karte
-
Mám pole cca 90 mil * 90 mil prvků
Jestli je to "plné", tak to máš 8 Pb (8000 Tb) a s tím ti asi žádná GPU nepomůže.
a potřebuji nad tím provádět bitové operace, sčítání, odčítání, rotace, porovnání.
Můžu vůbec GPU pracovat na úrovni bitů na GPU?
Samozřejmě. Má to všechny takové ty běžné instrukce.
CUDA je sázka na jistotu nebo se prosazuje OpenCL?
CUDA je nVidia-only a osobně mi přijde, že má lepší pokročilá synchronizační primitiva. OpenCL běží na všech kartách i procesorech.
cuda sa oplati ak netreba za kazdym kopirovat nove data na GPU;
napriklad nasobenie matice s vektorom : pokial zostava matica na karte a kopiruje sa len vektor novych dat je to naozaj zrychlene;
akonahle by sa mala za kazdym kopirovat aj ta matica neoplati sa to ...
Nevím, jak v kterém runtime, ale když necháš naalokovaný CL buffer, tak snad zůstává na kartě, ne?
-
pokud nemáš zkušenosti, doporučuji se mrknout na tensorflow, umí gpu i cpu. Psát to low level v Cudě nebo OpenCL může být na dlouho.
Pokud nemáš zkušenosti s vývojem nad GPU, raději si pronajmi pár mašin a udři to na nich.
Práce nad maticemi lze dobře škálovat nebo rozložit. Mrkni ještě na Spark a Scalu, mají implementované distribuované práce s maticemi, komprimování sturktur atd.
-
.... pole cca 90 mil * 90 mil prvků
Jestli je to "plné", tak to máš 8 Pb (8000 Tb) a s tím ti asi žádná GPU nepomůže.
[/quote]
Je to bitové pole 0/1, okraje bývají prázdné a tak velké to není, na 80TB storage mám jednu stávající zkomprimovanou verzi a "přitéká" aktuální, potřebuji tu stávající kopii zahodit dřív, než dojde místo. Pokud jí zahodím, nic se nestane, signalizuje se reset a začne se zapisovat nový snímek, problém s CPU je, že se ty snímky zahazují až příliš často, resp. se jich vyhodnotí podstatně méně, než by mi bylo milé. Nejprve jsem zkoušel použít AVX, což není tak těžké, ale výkon vzrostl řádově, já potřebuji tak o pět řádů.
pokud nemáš zkušenosti, doporučuji se mrknout na tensorflow, umí gpu i cpu. Psát to low level v Cudě nebo OpenCL může být na dlouho. Pokud nemáš zkušenosti s vývojem nad GPU, raději si pronajmi pár mašin a udři to na nich.
Práce nad maticemi lze dobře škálovat nebo rozložit. Mrkni ještě na Spark a Scalu, mají implementované distribuované práce s maticemi, komprimování sturktur atd.
Koukají z toho do budoucna €, když to udělám hrubou silou, € půjdou do nákupu hrubé síly a ne mě, CUDA i OpenCL se zvládnu naučit, resp. za danou částku to udělám velmi rád.
Doplnění:
Zdá se mi, že CUDA má lepší učící křivku, že bych mohl dostat kýžený výsledek o poznání jednodušeji/dřív.
A jestli si s tím mám pak ještě půl roku hrát, abych znovu zvedl rychlost, proč ne.
-
Nešlo by to zkusit vyřešit nějakým chytřejším algoritmem?
-
Nešlo by to zkusit vyřešit nějakým chytřejším algoritmem?
Nešlo, moc dat, operace sama o sobě je jednoduchá.
Identifikované vzorky se dále zpracovávají, tam by prostor rozhodně byl, jenže to se dělá na jiném stroji a ten to stíhá s klávesnicí v CDromce (prstem v nose).
-
Mám pole cca 90 mil * 90 mil prvků
Jestli je to "plné", tak to máš 8 Pb (8000 Tb) a s tím ti asi žádná GPU nepomůže.
O tomhle si jeste neslysel?
https://pro.radeon.com/en-us/product/pro-series/radeon-pro-ssg/
http://pro.radeon.com/_downloads/radeon-pro-ssg-datasheet-27.7.17.pdf
Mela by uz byt druha generace, prvni byla postavena na FIJI (Fury) a byl to spis vyvojarskej kit.
-
O tomhle si jeste neslysel?
https://pro.radeon.com/en-us/product/pro-series/radeon-pro-ssg/
Dobrý tip, díky!
(Pro mě bohužel OT, mám k dispozici nVidia grafiky, ale žádnou AMD. Abych měl prašule, musím to rozjet, bez toho nebudou prašule atd.)
App, jeden z důvodů, proč upřednostnit CUDA před OpenCL je fakt, že nVidia s OpenCL 2.0 nespěchá a mimo beta supportu tam člověd shoří jako papírový čert.
-
zatím nic takového neexistuje ale pokud máš peníze mužeš si koupit tohle
http://www.mellanox.com/related-docs/prod_multi_core/PB_TILE-Gx72.pdf
nebo již hotové karty na PCI/PCIe nebo použít Xilinx/Altera ASIC čipy a naprogramovat
si dané PLA podle libosti. Je to ovšem jen otázka peněz. Pole 90x90mil pixels
by se ani do nejvýkonnějšího PLA Xilinx nevešlo ale sjednocením více PLA
to jde. do jednoho Xilinx Virtex se vejde tisíce obrazů v HD kvalitě a spojením
jednotlivých hladin do jednoh obrazu mužeš vytvořit okno do tvého dvoudimenzionálního
prostoru 90x90mil. a krok za krokem zpracovávat celé pole 90x90mil. řekněme
že ve 20 milionech krocích by si měl být shopen tvoje 90x90 okno zpracovat
Virtex jede na 400MHz základní frevence takže by si měl být schopen zpracovávat
jedno okno v čase 0.05 sec. To už je solidní.
-
Takže by si měl být schopen zpracovávat jedno okno v čase 0.05 sec. To už je solidní.
Tak to je dost rozdíl oproti stávajícímu časovému oknu ~0.033 měsíce :-D
Paráda, ale zatím to není potřeba, i když se dostanu řádově na stovky minut, bude se to celé flákat, protože dostat data na pole trvá.
-
Jak slozity je ten algoritmus? Mame vlastni PCIe jadro pro FPGA, takze pulka problemu by byla vyresena :) Takze uz zalezi jen na dobe pro vyvoj a rozpoctu.. kdyztak PM
-
Jak slozity je ten algoritmus? Mame vlastni PCIe jadro pro FPGA, takze pulka problemu by byla vyresena :) Takze uz zalezi jen na dobe pro vyvoj a rozpoctu.. kdyztak PM
Díky za nabídku, nechci do toho zapojovat někoho jiného, jednak čistě prakticky, nerad bych o to přišel a jednak protože peníze na vývoj prostě nejsou. Vážím si toho.
-
Tak musím říct, že jsem byl už rozhodnutý jít do CUDA, ale co čert nechtěl, našel jsem tenhle článek.
http://diit.cz/clanek/vega-10-je-dulni-kombajn-na-kryptomeny
Podle všeho to bude karta okolo 12 tisíc osazena HBM2 pamětmi s dobrou propustností.
Aneb, proč používat extra zařízení, když to stejné zvládne udělat grafika, kterou z "Alza dostanu do druhého dne".
Navíc za tři roky, až přijde nová verze, dostanu za stejnou cenu řádnou porci výkonu navíc.
I tohle je argument, proč jít spíš do univerzálního řešení, než použít byť třeba rychlejší ASIC.
Náhradní kartu můžu mít ve svém počítáku a v případě poruchy je přehodit.
-
Muzes nam prozradit co je to za dataset?
-
Ja bych s tim klidne pomohl i zadax, nejake zkusenosti s CUDA mam, grafiky jsou ted sice spis vyprodane, ale jedna GTX1080 se mi tu vali bez uzitku - temer ;)
Nemam potrebu to krast, penez mam dost, ale su desne zpruzlej z aktualni "prace", potrebuju nejakou "zabavu" ;)
Akorat :
* radsi c++ a Linux
* lepsi je vytunit algo na CPU, nez si hrat s grafikou
* lepsi je si hrat s grafikou nez s FPGA
* lepsi je experimentovat s FPGA nez vyrabet ASIC
* pokud "operace sama o sobě je jednoduchá", tak to asi nic moc nepomuze, ale treba jde udelat ukrok stranou napr. jako RSA TWIRL
-
OpenCL s HSA je asi najlepsie
openCL so zapnutim HSAv je 6,34 x rychejsie ak openCL a 8,55 x rychlejsie ako cez CPU n a uveden A10 od AMD
http://www.tomshardware.com/reviews/amd-a10-7800-kaveri-apu-efficiency,3899-5.html
Z Epycom a GPU do jeho scketu je dalsi levcel HSA
http://diit.cz/media-gallery/detail/79677/282777
dokonca moze stacit c++ STL pri Radeon Open Computer platforM (ROCm)
http://diit.cz/media-gallery/detail/79677/282759
-
Kdyby to někdo hledal, pěkné shrnutí projektů pro práci GPU je zde: http://campynet.com/
Náhodou jsem na to narazil při louskání práce s CUDA.
-
Hele, logicky -- pokud to neni vypocetne narocne, tak budes omezenej sirkou pasma a to bud sirkou pasma GPU memory -> GPU a nebo, pravdepodobneji, sirkou pasma pro transfer z RAM do GPU memory. Takze stoji za uvahu, jestli tu skutecne nejake ovoce k utrzeni existuje. Bitove operace pod GPU samozrejme funguji.