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
|
Zaslal: 11. duben 2008, 20:22:38 Předmět: Multithreading dnes |
|
|
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 |
|
|
Hardwire
Založen: 04. 09. 2007 Příspěvky: 117
|
|
Návrat nahoru |
|
|
Marek
Založen: 28. 07. 2007 Příspěvky: 1782 Bydliště: Velká Morava
|
Zaslal: 12. duben 2008, 03:38:59 Předmět: Re: Multithreading dnes |
|
|
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 |
|
|
Quiark
Založen: 29. 07. 2007 Příspěvky: 816 Bydliště: Chlívek 401
|
Zaslal: 12. duben 2008, 08:45:23 Předmět: |
|
|
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 |
|
|
Dr.Sid
Založen: 11. 04. 2008 Příspěvky: 9
|
Zaslal: 12. duben 2008, 11:42:52 Předmět: |
|
|
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 |
|
|
Al
Založen: 23. 10. 2007 Příspěvky: 196
|
Zaslal: 12. duben 2008, 15:28:24 Předmět: |
|
|
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 , č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é! ).
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 |
|
|
Al
Založen: 23. 10. 2007 Příspěvky: 196
|
Zaslal: 12. duben 2008, 15:36:16 Předmět: |
|
|
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 |
|
|
Dr.Sid
Založen: 11. 04. 2008 Příspěvky: 9
|
Zaslal: 12. duben 2008, 20:06:00 Předmět: |
|
|
Dekuji za duveru
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 |
|
|
Al
Založen: 23. 10. 2007 Příspěvky: 196
|
Zaslal: 13. duben 2008, 12:23:57 Předmět: |
|
|
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.
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á. |
|
Návrat nahoru |
|
|
Fila
Založen: 31. 07. 2007 Příspěvky: 853
|
Zaslal: 14. duben 2008, 10:29:02 Předmět: |
|
|
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 |
|
|
Dr.Sid
Založen: 11. 04. 2008 Příspěvky: 9
|
Zaslal: 14. duben 2008, 16:24:02 Předmět: |
|
|
Momentalne nemam sanci CPU vytizit. Hlavni vlakno porad ceka na grafiku, a vedlejsi na disk. Zkusim nejake pokusy bokem. |
|
Návrat nahoru |
|
|
Marek
Založen: 28. 07. 2007 Příspěvky: 1782 Bydliště: Velká Morava
|
Zaslal: 14. duben 2008, 19:21:28 Předmět: |
|
|
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 |
|
|
Al
Založen: 23. 10. 2007 Příspěvky: 196
|
Zaslal: 14. duben 2008, 23:19:07 Předmět: |
|
|
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 |
|
|
Fila
Založen: 31. 07. 2007 Příspěvky: 853
|
Zaslal: 15. duben 2008, 10:18:45 Předmět: |
|
|
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 |
|
|
Tringi
Založen: 28. 07. 2007 Příspěvky: 290
|
Zaslal: 15. duben 2008, 17:07:50 Předmět: |
|
|
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 |
|
|
|