Reklama

Carter83

Příspěvky uživatele

Náročné fyzikální výpočty vs. procesory v praxi: AVX a GPGPU ještě ne

22.3.2013 Carter83(48)
5. Květen 2013 - 18:23 od Carter83

ad. DP - měl bych asi zmínit, že DP se pro proudění běžně nepoužívá, v drtivé většině případů stačí SP.

5. Květen 2013 - 16:27 od Carter83

 K obecnému využití pro GPGPU moc neřeknu, to už spíše někdo jako např. SamanCZ, který, pokud vím, používá Titany.

 Článek/recenze v dohledné době nehrozí, není o čem psát - výpočty proudění, to je totiž pořád stejná písnička. V ANSYSu se podpora pro GPU letos nechystá, tj. nejdříve příští (oficiálně ale není nic potvrzeno, takže klidně i později) a v té době už Titan určitě nebude to nej. Navíc, 3 GB paměti jsou na CFD zoufale málo, i kdyby už se na něčem takovém dalo počítat, tak by to musel být "velký" Titan.

 Osobně vkládám do budoucna mnohem větší naději v heterogenní architektury, jakmile budou CPU i GPU přistupovat ke stejné paměti, bude určitě snadnější portovat na GPU jenom některé části algoritmu, hlavně maticové operace.

P.s. Mimochodem, pro pevnostní výpočty už ANSYS GPU výpočty podporuje, nicméně žádná sláva to, co se výkonu týče, není. Dokonce je to tak, že GPU je pomalejší než CPU, a vyplatí se pouze díky rozdílné licenční politice. Tj, mám-li jeden 8-mi jádrový Xeon, přikoupením dalšího získám více výkonu než koupí Tesly. Přitom Xeon je levnější. Jenže, pro využití druhého CPU potřebuji další licenci, která je řádově dražší než hardware, zatímco CPU + GPU mohu používat v rámci jediné...

26. Březen 2013 - 22:45 od Carter83

 Bude mít to šíření vody nějaký dopad na hru? Třeba že by voda spláchla jednotky nebo něco takového (to by strategiím dávalo zajímavé možnosti...)? Z rychlosti proudění by přece nebyl problém určit sílu.

26. Březen 2013 - 22:42 od Carter83

 Velký problém se ovšem nevleze do paměti GPU...

 Na druhé straně, nepochybuji o tom, že GPGPU má budoucnost i v CFD, ale bude to chtít provázanější architekturu CPU a GPU.

 Ještě zmíním jednu věc. ANSYS není jenom o tom, jak kvalitní má či nemá kódy. Hlavně se jedná o to, že je považovaný za standard, tj. výpočty ANSYSem jsou "důvěryhodné". Nově vytvořený kód může být sebelepší, ale onu důvěru prostě nemá, a tím je pro komerční nasazení vlastně nepoužitelný.

P.s. Elektronové struktury budou asi taky dost náročné výpočty. ne?

26. Březen 2013 - 17:31 od Carter83

Má to jeden háček - nevím o tom, že by byl nějaký open-source CFD software, schopný počítat něco jiného než školní úlohy. Tedy ne že by se čas od času něco takového neobjevilo, jenže pak zpravidla vstoupí do hry ANSYS, kód koupí a implementuje do svých produktů.

CuBLAS mimochodem nemusí až tak pomoct. Možná se pletu, ale z nějakých diskuzí o GPGPU výpočtech jsem kdysi pochopil, že v současné generaci GPU je občas problém vyhnout se přesunům dat mezi RAM a GPU, takže je například možné, že MPI komunikace (která roste s počtem vláken) musí jít přes sběrnice a tím zmenšuje přínos rychlejších maticových operací. Ale to jen tak hádám.

25. Březen 2013 - 22:37 od Carter83

 Takže pokud jsem to z videa dobře pochopil, tak algoritmus zaplňuje po sobě následující úseky vodou v závislosti na výšce terénu a hladiny, jednotlivé vodní sloupce na sobě přitom nezávisí, je to tak?

 Je to kařdopádně asi poprvé, co jsem v nějakém herním enginu viděl šíření záplavové vlny. Každopádně, i když se fyzika ve hrách poslední dobou hodně vyvíjí, počítat proudění v reálném čase tak, aby byly podchyceny i víry (třeba při obtékání stromů se má proud zatočit) je v dohledné době nejspíše nereálné - byla by na to potřeba o několik řádů hustější síť než na samotné zobrazení grafiky...

24. Březen 2013 - 22:08 od Carter83

Nárůst 90% mezi 32 a 64 jádry? To je hodně dobré. Jakou konkrétní úlohu jste tím počítali?

A kde berete výpočetní síť? Vlastní generátor, nebo nějaký import?

24. Březen 2013 - 21:24 od Carter83

 A máte změřené, jak dobře algoritmus škáluje? V ANSYSu musí mít pro postup, který používá CFX, nějaký důvod, zřejmě by jinak bylo obtížné dosáhnout dobrých výsledků i na tisíci jádrech.

24. Březen 2013 - 21:21 od Carter83

Píšete vlastní CFD kódy? Klobouk dolů. A bavíme se i o komerčním využití, nebo je to pro akademické účely?

CFX každopádně - pokud je mi známo - funguje trochu jinak, než máte zřejmě na mysli. Kód sám o sobě paralelní vlastně není, místo toho je celá výpočetní oblast rozdělena na podoblasti, a pro každou podoblast je spuštěn samostatný řešič (který využívá pouze jedno jádro). V místech rozdělení je potřeba přenášet okrajové podmínky, což se děje přes MPI. Hlouběji do této problematiky nevidím, takže detaily ode mě nečekejte. V praxi se ale ukazuje, že s rostoucím počtem podúloh je výpočet problematičtější, na vině budou pravděpodobně zaokrouhlovací chyby při přenosu okrajových podmínek.

Numerické výpočty CFD jsou vůbec kapitola sama pro sebe, tenhle koncept "podúloh" má například tu zvláštnost, že při ukončení a uložení úlohy se jednotlivé rozpočítané oblasti před uložením znovu "sjednotí" (to aby výsledný soubor nebyl nikterak závislý na počtu jader). Jenže zaokrouhlovací chyby dokáží své, takže se může stát, že zatímco při výpočtu řekněme 200 iterací dostaneme výsledek A, tak v případě "100 iterací - uložit - načíst - dalších 100 iterací" dostaneme výsledek B, který není úplně shodný s A. V horším případě B ani nedostaneme, protože úloha po "restartu" jednoduše začne divergovat a posléze spadne. (Což mimochodem z ukládání mezivýsledků činí vcelku zbytečnou činnost... :))

24. Březen 2013 - 20:23 od Carter83

Díky za příklad. Stejná rychlost navzdory rozdílnému teoretickému výkonu krásně potvrzuje, že limitace je hlavně ze strany pamětí a rychlosti komunikace mezi procesory - tyto hodnoty jsou u obou architektur stejné. Sandy Bridge-EP by měl být každopádně rychlejší.

24. Březen 2013 - 19:39 od Carter83

 7970 - když člověk navíc uváží, že se jedná o grafiku a procesor srovnatelné ceny, tak je to opravdu neskutečný rozdíl. Co bychom dali za to, kdyby takhle fungovalo i CFX... :)

 Program který používáte podporuje GPGPU sám o sobě, nebo jste si něco napsali sami?

Výpočet spadne = místo konvergence začne divergovat (rezidua začnou prudce růst) a nakonec skončí s chybovou hláškou.

22. Březen 2013 - 23:19 od Carter83

150 fps na 50*50 vs. 150 fps u 4096*4096? :-o To je rozdíl výkonu o tři řády, ne? Předpokládám, že se musí jednat o úlohu, která jde rozdělit na jednotlivá, na sobě nezávislá vláka, tj. pro GPGPU ideální. A na jaké grafice se počítalo?

V CFD je s paralelizací ještě jeden problém - úlohu je potřeba dělit, a s rostoucím počtem jader se zhoršuje konvergence, což také snižuje výkon (je potřeba provést více iterací). Navíc se občas stává, že na větším počtu jader se úlohu ani nepodaří spočítat (např. 4 jádra - ok, 8 - výpočet spadne), a GPGPU by situaci ještě zhoršilo.

22. Březen 2013 - 23:03 od Carter83

 Nedostatečná velikost pamětí u GPU je další problém, který jsem zapomněl zmínit. Ale výpočty čerpadel ještě nejsou z nejhorších, do 6GB by se vešlo poměrně dost úloh.

22. Březen 2013 - 22:57 od Carter83

Takže pokud tomu správně rozumím, tak Windowsy při přehazování vláken mezi jádry vybírají "špatná" jádra. Proto je pokles výkonu pokaždé jiný. Ale stejně pořád nechápu, proč se tak přestane dít při zapnutém HT. Nebo mi něco uniká?

22. Březen 2013 - 13:13 od Carter83

104% škálování je způsobeno zřejmě hlavně tím, že na jednom jádru dochází k propadu výkonu, zřejmě kvůli onomu problému s NUMA, který výše zmiňoval DougQaid. Bohužel nevím, jak tenhle problém vyřešit, a na využití počítače nemá praktický dopad - takže nebyl moc prostor se tím zabývat...

Stránky

Reklama