.[ ČeskéHry.cz ].
Multithreading dnes
Jdi na stránku 1, 2  Další
 
odeslat nové téma   Odpovědět na téma    Obsah fóra České-Hry.cz -> Obecné
Zobrazit předchozí téma :: Zobrazit následující téma  
Autor Zpráva
Dr.Sid



Založen: 11. 04. 2008
Příspěvky: 9

PříspěvekZaslal: 11. duben 2008, 20:22:38    Předmět: Multithreading dnes Odpovědět s citátem

Zdravicko.

Hledam nejakou dobrou literaturu/stranky (stranky radeji) ohledne mutlithreadingu, jde mi ovsem (a v tom je ta potiz) o aktualni informace, zejmena s ohledem na aktualni vicejadrove a uvazovane budouci procesory, a to vse se zamerenim na 3d hry.

Pokud se nekdo z vas v teto oblasti povazuje za machra, samozrejme to milerad proberu primo tady.

Zakladni dotazy:

- jak aktualni operacni systemy (XP,Vista,linux) distribuuji thready mezi jadra, delaji to vubec ? Jsou tam nejake rozdily z hlediska atomicicity operaci ?
- lze povazovat prirazeni pointeru za atomicke s ohledem na vsechny tyto systemy a blizkou budoucnost (rekneme 64 bitove stroje ?) - rekl bych ze jo, ale nerad bych se mylil.
- pouzivaji se dnes ve hrach nejake obecne uznavane modely a strategie pro aplikaci multithreadingu ? Nerad bych znovuvymyslel kolo, je zjevne ze thread na vsechno prinasi obrovskou rezii a prodlevy v synchronizaci, zatimco jeden thread vladne vsem trpi prodlevami napriklad pri diskovych operacich a pomale procesy na pozadi musi rozkladat.

Hruby popis proc to vlastne chci .. pisi takovy celkem obecny engine na simulatory. Ulohy tedy jsou uzivatelske rozhrani, 3d zobrazeni, fyzika, kolize, scriptovatelna ai. To vse potrebuji volne, rozsiritelne, a stremovatelne, tedy ze se objekty, skritpy a podobne budou dohravat i v prubehu simulace, ne jen na zacatku. Prosim pri diskuzi se omezte ciscte na aspekt threding modelu, nerad bych slysel 'proc nepouzijes tenhle engine ?' .. odpovidam predem, protoze mne to bavi.

Jo jeste aby jste si nemysleli ze jde o vapor .. http://www.commanders-academy.com/comsubsim

Dik.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Hardwire



Založen: 04. 09. 2007
Příspěvky: 117

PříspěvekZaslal: 11. duben 2008, 22:07:46    Předmět: Odpovědět s citátem

Erwin Coumans (autor Bullet) dal k dispozici slajdy ke svojí prezentaci o paralelismu ve fyzikální simulaci, tak se ti to možná bude hodit:
http://www.bulletphysics.com/Bullet/wordpress/uncategorized/gdc-2008-physics-tutorial-on-parallel-game-physics-for-spu

Jinak se v tomhle moc nevyznám.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Zobrazit autorovi WWW stránky
Marek



Založen: 28. 07. 2007
Příspěvky: 1782
Bydliště: Velká Morava

PříspěvekZaslal: 12. duben 2008, 03:38:59    Předmět: Re: Multithreading dnes Odpovědět s citátem

Dr.Sid napsal:
- jak aktualni operacni systemy (XP,Vista,linux) distribuuji thready mezi jadra, delaji to vubec ?

Ano, dělají to automaticky. Kdyby to nedělaly, vícejádrové systémy by pak na tom byly docela špatně, ne?

Dr.Sid napsal:
- lze povazovat prirazeni pointeru za atomicke s ohledem na vsechny tyto systemy a blizkou budoucnost (rekneme 64 bitove stroje ?)

Obecně nelze žádnou operaci považovat za atomickou. Tipuju, že možná přes nějakou specializovanou instrukci??? ale v tom se nevyznám... a co když bude existovat nějaká specializovaná instrukce, ale vyhodnocení vstupní a výstupní adresy v paměti nebude součástí té operace??? Pak se to může přečíst/zapsat moc brzo nebo se zpožděním a je problém.
Ad ten zbytek... 64bitové stroje nejsou budoucnost, ale současnost (od roku 2003).

Dr.Sid napsal:
- pouzivaji se dnes ve hrach nejake obecne uznavane modely a strategie pro aplikaci multithreadingu ? Nerad bych znovuvymyslel kolo, je zjevne ze thread na vsechno prinasi obrovskou rezii a prodlevy v synchronizaci, zatimco jeden thread vladne vsem trpi prodlevami napriklad pri diskovych operacich a pomale procesy na pozadi musi rozkladat.

Na konzolích se to vyplatí, protože máš po ruce X jader a můžeš je použít, jak chceš. Nicméně na PC je to problém a většina lidí má maximálně to dual-core. Nicméně v porovnání s konzolema (xbox a ps3), jedno jádro na PC může být 2x nebo 4x rychlejší, takže PC může malý počet jader dohnat surovým výkonem (už je to přece nějaká doba, co ty konzole vyšly). Z hlediska her to vidím asi tak: Pokud hodláš provozovat nějaký rozumný fyzikální engine (kolize + interakce), sám se umí postarat o přesunutí výpočtu na jiné jádro. Příprava na rendering si vezme asi 50% výkonu jednoho jádra + je třeba brát v úvahu, že driver grafické karty taky jede paralelně a něco to bude stát navíc. Dalších 50% můžeš použít na herní logiku a zbytek, takže se moc nemusíš s vláknama zaobírat, pokud vyloženě nechceš. Ostatní jádra snadno "vyžere" fyzikální engine. Vlákna stále mají smysl na asynchronní loading (čtení z disku) nebo když máš nějakou hru typu strategie, kde máš stovky až tisíce jednotek, potom se vyplatí přenést na jiné jádra třeba výpočet AI a pathfinding, ovšem otázka je, zda pak zbyde dost prostoru na fyziku.
_________________
AMD Open Source Graphics Driver Developer


Naposledy upravil Marek dne 18. duben 2008, 21:38:56, celkově upraveno 1 krát
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Quiark



Založen: 29. 07. 2007
Příspěvky: 816
Bydliště: Chlívek 401

PříspěvekZaslal: 12. duben 2008, 08:45:23    Předmět: Odpovědět s citátem

Atomické přiřazení pointerů:
Koukal jsem do MSDN a tam tvrdí, že přiřazení správně zarovnaných 32bitových proměnných na 32bitovém systému je atomické. Stejně tak 64bitové proměnné na 64bitovém systému. Možná se to ale týká jen Windows. Dále WinAPI nabízí funkce InterlockedXxx pro jednoduché atomické operace jako je přehození hodnot a podobně.
_________________
Mám strach
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Zobrazit autorovi WWW stránky
Dr.Sid



Založen: 11. 04. 2008
Příspěvky: 9

PříspěvekZaslal: 12. duben 2008, 11:42:52    Předmět: Odpovědět s citátem

Diky za odkaz na clanek ohledne atomicity pointeru, ten mi ovsem dosel mejlem, takze ho dam jeste sem:
http://msdn2.microsoft.com/en-us/library/ms684122(VS.85).aspx

JEstli to chapu dobre, tak momentalne mi to staci. Mam v podstate hlavni vlakno ktere resi smycku udalosti, kresleni, simulaci (koliza mam a budu mit dost jednoduche). Vedlejsi thready ted resim hlavne kvuli asynchronimu nacitani terenu a textur.

Vtip je v tom ze jedno vlakno zadava ukol, druhe vlakno zpracovava ukol, skrz jednoduchou frontu, a je jen jeden zadavatel a jen jeden zpracovavatel.
Spolecne zapisuji pouze do pointeru ve fronte, pricemz pro zakazky zadavatel zapisuje nenulu pokud tam je nula, a zpracovatel nulu, pokud je tam nenula. Indexy do fronty maji kazdy svoje, tam kolize neni.
Pro vysledky potom pouziji podobnou frontu.

Jako psal uz veci s threadama celkem dost a nikdy jsem se bez synchronizace neobesel. Ale at koukam na tenhle model jak chci, tak v tom diru nevidim.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Al



Založen: 23. 10. 2007
Příspěvky: 196

PříspěvekZaslal: 12. duben 2008, 15:28:24    Předmět: Odpovědět s citátem

Nehci rýpat, ale mám dojem, že tazatel nás mystifikuje, neboť nepotřebuje informace "aktuální", ale "základní". Ty věci kolem chování operačních systémů a programování her nebo čehokoliv s vlákny nejsou žádým výkřikem posledních měsíců či let. Je to věc ve Windows 15 let stará a funguje to pořád stejně. V každé dobré knize na dané téma je to vysvětleno, i dost letité (5-10 let staré) knihy obsahují korektní popis. Základní informace podávají třeba VŠ učebnice (mně používat vlákna učili ve škole už v roce 1997, sám jsem taky už dvě učebnice o vláknech napsal Cool, čili není to nic nového).

Pro detailní informace o chování Windows (jakékoliv verze) můžu doporučit knihu Solomon/Rusinovich: Windows Internals (4.vydání, MS Press). Jednotlivé verze Windows se samozřejmě liší, ale není to pro programování her podstatné. V praxi se ty koncepční rozdíly projeví třeba na počítačích, co mají 32 nebo 64 procesorů - tam při využití všech z nich v jednom programu bude poznat, že novější Windows pojede rychleji. Ale toto není příklad běžného domácího počítače, tak bych to neřešil.

Přiřazení pointeru většina vyšších jazyků považuje za atomické, protože by jinak asi byl problém vůbec něco naprogramovat. Technicky vzato a čistě na počítačích PC platí, že atomické je přiřazení tehdy, když je provedeno jedním přístupem do paměti. Záleží tedy, kde ten pointer v paměti je. Doporučuji programovat s tím, že teda jako je to vždy atomické pro tolik bitů, kolikabitový je počítač (32 nebo 64) a aby to byla pravda, je třeba používat standardní memory alignment C/C++ překladače. Windows API má pro atomické přiřazení vícebitových hodnot systémové funkce. Na počítačích jiných než PC je to ale zase jinak. Nějaké technické informace jsem našel i na Wikipedii, pro příklad viz třeba popis paměťového modelu Itanium (IA64 - jen pro obzvlášť otrlé! Cool).

Jedna poznámka bokem: 64bit PC potřebuje 64bit operační systém, jinak pracuje jen ve 32bit režimu a nic 64bitového nejde použít. Je to věc hardwarové architektury, prostě nelze to míchat tak snadno, jako 16 a 32bit na procesorech 386.

Algoritmy s vlákny, tedy jak to efektivně využít třeba v konkrétní hře, nemají žádnou jednu "nejlepší" variantu. Každá konkrétní hra potřebuje něco jiného nějak jinak, navíc jak psal Eosie, každý PC počítač je úplně jiný. Takže představa, že někdo, kdo o tom nic moc neví, si něco přečte a podle toho napíše dokonalý engine s vlákny, je asi naivní. Je to složité, chce to léta praxe. Sám dělám s vlákny cca 8 let a strašně mě to vždycky bavilo, ale dost dlouho z těch 8 let jsem se plácal kolem "problémů", které jsou úplně začátečnické.

Microsoft v poslední době hodně publikuje články o paralelizmu a i dělá nějaký software v této oblasti. Je to určitě zajímavé, ale berte to jako jen jednu z mnoha variant, jak se k tomu celému dá přistupovat. Podle mě oni to dělají prostě proto, že je lepší dát lidem srozumitelné informace, jak použít paralelní počítač nějak lépe, než mít jen jedno vlákno. To, že po několika letech studia dané problematiky a práce v oblasti přijdete na mnohem lepší způsoby, jak ta vlákna používat, je zas jiná věc.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Al



Založen: 23. 10. 2007
Příspěvky: 196

PříspěvekZaslal: 12. duben 2008, 15:36:16    Předmět: Odpovědět s citátem

Ještě k té atomicitě: Ty funkce Interlocked... jsou rychlejší, než používat synchronizaci zamykáním (semafory, mutexy, kritické sekce), a to dost výrazně. Ale spousta věcí se tím zase dělá dost složitě. Interlocked jsou přesně ty operace, které má CPU v instrukční sadě a jsou provedeny atomicky. Přitom na 1 CPU je atomické kde co (třeba instrukce inc - inkrementace proměnné o jedničku), zatímco na vícejádrových počítačích máloco (třeba inc není, ale právě existuje funkce InterlockedIncrement, která to provede atomicky).

Doporučuji prohlédnout DC++, je to program používající vlákna, ve kterém několik let autoři marně řešili chybu, že to nefungovalo na vícejádrových CPU. Používali tam prostě nějaké věci, co jsou atomické jen na 1jádrových počítačích. Poučení (aspoň pro mě): Program používající vlákna vždy důkladně testovat na (conej)vícejádrových počítačích, jinak se některé chyby neprojeví.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Dr.Sid



Založen: 11. 04. 2008
Příspěvky: 9

PříspěvekZaslal: 12. duben 2008, 20:06:00    Předmět: Odpovědět s citátem

Dekuji za duveru Very Happy

Problem prave je ze tohle presne jsem nevedel, tedy to, ze ty 5 let stare informace stale plati.

Softwaru ktery na vice CPU nefunguje korektne je spousta. Pojal jsem tedy podezreni ze neco je jinak. Pokud ne, tim lip.

Nicmene porad se mi nejak nedari prinutit sve Core 2 Duo (a XP) aby thready jednoho procesy byly na ruznych CPU. Nemusi se to nekde nastavit ?

Edit: pockat pockat .. ted jsme znovu koukal na ten clanek o mrkvosovftu (viz vyse) a mezi temi interlocked funkcemi je InterlockedExchange, ktera prave nastavuje 32 bit hodnotu. Pokud par radku pred tim pisou ze takova operace je atomicka, proc pak mit takovou funkci ?
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Al



Založen: 23. 10. 2007
Příspěvky: 196

PříspěvekZaslal: 13. duben 2008, 12:23:57    Předmět: Odpovědět s citátem

Co jsem viděl, tak jenom LispWorks běhá všemi vlákny na jednom jádru. Doufám ale, že se tu bavíme o C/C++ či C#. Pokud ano, běhají na všech jádrech. Systém se přitom snaží při startu distribuovat vlákna mezi jádra a pak se jich držet (tedy moc necestovat mezi jádry). Ale není to zákon, prostě většinou se tak snaží, pokud náhodou zrovna nemá nějaký jiný lepší nápad. Cool

Exchange = výměna dvou hodnot není na vícejádru atomická. Jsou to dva přístupy do paměti: 1. přečíst starou hodnotu, 2. nastavit novou hodnotu. No a klasicky na jednonádru je výměna (se zarovnanou adresou) atomická. Cool
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Fila



Založen: 31. 07. 2007
Příspěvky: 853

PříspěvekZaslal: 14. duben 2008, 10:29:02    Předmět: Odpovědět s citátem

Dr.Sid -- a vytezuji ty tve vlakna poradne CPU? Pokud ne, system je klidne muze nechat na jednom, protoze to proste jedno jadro upocita.

Eosie -- mas na to IMHO zbytecne kratkozraky pohled. To, ze maji dnes PC obvykle 1-2 jadra neznamena, ze to tak bude i v budoucnu -- a zvlaste pri vyvoji nejakeho obecneho enginu, u ktereho se pocita s nejakou zivotnosti, by bylo dobre pocitat s tim, ze za par let bude bezne v PC jader mnohem vice.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Dr.Sid



Založen: 11. 04. 2008
Příspěvky: 9

PříspěvekZaslal: 14. duben 2008, 16:24:02    Předmět: Odpovědět s citátem

Momentalne nemam sanci CPU vytizit. Hlavni vlakno porad ceka na grafiku, a vedlejsi na disk. Zkusim nejake pokusy bokem.
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Marek



Založen: 28. 07. 2007
Příspěvky: 1782
Bydliště: Velká Morava

PříspěvekZaslal: 14. duben 2008, 19:21:28    Předmět: Odpovědět s citátem

Fila> Máš recht.

Dr.Sid>
1) Použij AMD GPU PerfStudio nebo nVidia PerfKit na detekci problematických míst při zpracování grafiky.
2) Zvaž použití komprese pro data uložená na disku (sám komprimuju jenom ty soubory, kde se kompresní poměr vyplatí).
_________________
AMD Open Source Graphics Driver Developer
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Al



Založen: 23. 10. 2007
Příspěvky: 196

PříspěvekZaslal: 14. duben 2008, 23:19:07    Předmět: Odpovědět s citátem

No pozor. I když CPU není využit 100%, systém standardně distribuuje vlákna rovnoměrně. A jak jsem psal výše: Snaží se držet vlákno pořád na stejném jádru. On si doslova pamatuje, na kterém jádru chtěl, aby to vlákno běželo, a i když ho pak třeba nechává nějaký čas běžet jinde, pořád si to pamatuje a inklinuje k tomu, aby se t vlákno vrátilo zpátky, kde ho chtěl mít od začátku. A když je úplně nevyužitý CPU a jede třeba jen 1 vlákno, co něco pořádně počítá, tak klidně může cestovat po všech jádrech (to se týká Windows, jednotlivé verze se mohou ještě lišit).
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Fila



Založen: 31. 07. 2007
Příspěvky: 853

PříspěvekZaslal: 15. duben 2008, 10:18:45    Předmět: Odpovědět s citátem

No dobre, ale pokud vlakna vyuzivaji CPU opravdu malo, tak neni duvod, aby je system cpal na rozdilne jadra, kdyz ma dohromady stovky vlaken, ktere mezi tato dve jadra distribuuje, ne?
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu
Tringi



Založen: 28. 07. 2007
Příspěvky: 290

PříspěvekZaslal: 15. duben 2008, 17:07:50    Předmět: Odpovědět s citátem

Jaký k tomu mají Winy důvod nevím, odhaduju to na spotřebu a zahřívání, ale opravdu vlákno které více vytěžuje procesor poskakuje po jednotlivých jádrech. Vlastní zkušenost s vlastním prográmkem, Windows Vista, Core 2 Duo.
_________________
WWW | GitHub | TW
Návrat nahoru
Zobrazit informace o autorovi Odeslat soukromou zprávu Zobrazit autorovi WWW stránky
Zobrazit příspěvky z předchozích:   
odeslat nové téma   Odpovědět na téma    Obsah fóra České-Hry.cz -> Obecné Časy uváděny v GMT + 1 hodina
Jdi na stránku 1, 2  Další
Strana 1 z 2

 
Přejdi na:  
Nemůžete odesílat nové téma do tohoto fóra
Nemůžete odpovídat na témata v tomto fóru
Nemůžete upravovat své příspěvky v tomto fóru
Nemůžete mazat své příspěvky v tomto fóru
Nemůžete hlasovat v tomto fóru


Powered by phpBB © 2001, 2005 phpBB Group


Vzhled udelal powermac
Styl "vykraden" z phpBB stylu MonkiDream - upraveno by rezna