Vyznam dual core

[Eagle]

me to docela smysl dava. stejne se to pouziva napr. v databazovejch aplikacich. ono je to mozna jen trosku nesikovne napsany...

Jenže v databázích s tím budeš mít úplně stejný problém. Pokud dva uživatelé otevřou ten samý záznam, následně ho modifikují a uloží, vznikne ti konflikt, popř. druhý ukládající přepíše práci prvního. A jak bys tohle chtěl u hry ošetřit?

[Fox!MURDER]

Jenže v databázích s tím budeš mít úplně stejný problém. Pokud dva uživatelé otevřou ten samý záznam, následně ho modifikují a uloží, vznikne ti konflikt, popř. druhý ukládající přepíše práci prvního. A jak bys tohle chtěl u hry ošetřit?

So, we just allowed all the threads to read any time they want, and only write when the data was locked to that thread.

tzn. neodstranujou zamky uplne. odstranujou zamky pro cteni.

stejne to dela napr. MySQL, ktery pouziva read-only zamky. dalsi, ale dosti komplikovana a nevim jak efektivni cesta by mohlo bejt pouziti transakci ...
mozna to, kdyby se nejakym zpusobem implementovalo v HW, by mohlo udelat docela divy ...

[Eagle]

tzn. neodstranujou zamky uplne. odstranujou zamky pro cteni.

To je sice hezký, ale co to mění na stavu věcí? Pokud jeden thread má přečíst data, změnit je, zapsat a následně druhý je přečíst, změnit a zapsat, tak tím, že druhému umožníš je přečíst v době, kdy první thread nedokončil svojí práci, způsobíš načtení starých dat, a tedy porušení integrity.

[Fox!MURDER]

To je sice hezký, ale co to mění na stavu věcí? Pokud jeden thread má přečíst data, změnit je, zapsat a následně druhý je přečíst, změnit a zapsat, tak tím, že druhému umožníš je přečíst v době, kdy první thread nedokončil svojí práci, způsobíš načtení starých dat, a tedy porušení integrity.

otazka je, jaky to jsou data. a otazka je, jak casto konkretne ve hre delas to, ze prectes data a znova ty samy data zapisujes zmeneny. dovedu si predstavit scenare, kde se to tak deje a scenare, kde tohle vubec neni potreba. a i kdyz to ted treba neumim presvedcive vyvratit, tak spis budu verit cloveku, kterej ma za sebou projekty ala Half-Life a Source engine, nez cloveku, kterej jediny jak tu prezentuje svoje zkusenosti s threadovym programovanim je ve forme 'a threadove jsi nekdy programoval?' ... sorry ...

[PiT]

Ja som hlavne zvedavy, kolko FPS to prida vyslednej hre, nakolko mi z toho clanku je jasne, ze oni neurychluju to gro hry, co uz maju, ale sa snazia paralelizovat a tym urychlit veci, ktore tam pridavaju - len niektore efekty (dazd, obrazovky na scene a pod). O AI a pod. su tam iba "vzrusene" dristy, ziadne dokazy (a prave AI je jedna z veci, kde ma Valve imho velke rezervy).

[tomase]

Eagle preco sa namiesto vyvracania vsetkeho nesnazis vrhnut svoju energiu a potencial na to aby si im naopak pomohol a napr. vymyslel system, ktory bude v praxi funkcny? Myslim, ze kazdeho normalneho cloveka potesi, ze niekto sa zacal zaujimat o multithreading, obzvlast firma ako Valve, ktora produkuju jedny z najhranejsich hier sucastnosti a blizkej minulosti.

[Fox!MURDER]

Eagle preco sa namiesto vyvracania vsetkeho nesnazis vrhnut svoju energiu a potencial na to aby si im naopak pomohol a napr. vymyslel system, ktory bude v praxi funkcny? Myslim, ze kazdeho normalneho cloveka potesi, ze niekto sa zacal zaujimat o multithreading, obzvlast firma ako Valve, ktora produkuju jedny z najhranejsich hier sucastnosti a blizkej minulosti.

zapominas na to, ze eagle je clovek ...

[Eagle]

Eagle preco sa namiesto vyvracania vsetkeho nesnazis vrhnut svoju energiu a potencial na to aby si im naopak pomohol a napr. vymyslel system, ktory bude v praxi funkcny? Myslim, ze kazdeho normalneho cloveka potesi, ze niekto sa zacal zaujimat o multithreading, obzvlast firma ako Valve, ktora produkuju jedny z najhranejsich hier sucastnosti a blizkej minulosti.

Protože jsem ekonom a tohle mě nezajímá. Hry hraju jen staré (= ty, které měly nějakou hratelnost a nápad) a v IT by mě nikdo adekvátně nezaplatil.

[THX]

Jenže v databázích s tím budeš mít úplně stejný problém. Pokud dva uživatelé otevřou ten samý záznam, následně ho modifikují a uloží, vznikne ti konflikt, popř. druhý ukládající přepíše práci prvního. A jak bys tohle chtěl u hry ošetřit?

Tak si to precitaj este raz. Ak to mas problem pochopit. Sice sa tam pise, ze "lock-free", ale hned v tej istej citacii mas ze zamykanie sa pouziva pri zapise. Teda, lock-free to je len v tych 95% pripadoch, kedy sa cita.

Modifikacia = zapis/prepis dat = LOCK.
Pokial su data zamnknute, nikto iny s nimi nemoze pracovat, teda ani iny thread ich citat, alebo prepisat. Nedojde k strate integrity.

Ak sa data nemodifikuju, tak nie su zamknute, teda ako 20 threadov naraz chce na 20 jadrach citat, tak to proste precitaju naraz a subezne, bez toho aby sa to muselo zamykat a citat jeden po druhom.

"Zjistili, že autonehoda nastává jen v 0,1 % případů jízdy autem. Proto povolili automobily bez deformačních zón a bez bezpečnostních pásů."
Domnívám se, že jsem ti jasně řekl, co si o tobě myslím a co je podmínka další diskuze s tebou. Opět jsi projevil svůj deficit inteligence, tak si asi budeš muset hovořit sám se sebou. Ostatní mají aspoň nějakou kulturu projevu.

Lenze oni nepovolili zapis/prepis bez zamykania.
Ak sa ti nepacia petrikove prispevky, tak na ne nereaguj. Neviem co sa ti nepaci na petrikovej kulture prejavu, zatial som si nikde nevsimol, aby napadal teba a tvoju intelingenciu (zato ty jeho ano).

Ja som hlavne zvedavy, kolko FPS to prida vyslednej hre, nakolko mi z toho clanku je jasne, ze oni neurychluju to gro hry, co uz maju, ale sa snazia paralelizovat a tym urychlit veci, ktore tam pridavaju - len niektore efekty (dazd, obrazovky na scene a pod). O AI a pod. su tam iba "vzrusene" dristy, ziadne dokazy (a prave AI je jedna z veci, kde ma Valve imho velke rezervy).

V clanku je pekne rozobrate, ze pouzivaju rozne "druhy" threadingu a rozne pristupy. Staci sa pozriet na tie obrazky.
Takze o co ide:

Coarse threading: is the process of taking whole systems and putting them on to individual cores. It's a conceptually simple task to put rendering on one core, AI on another, physics on another and so on. Tom continues, "This essentially allows these systems to stay single threaded, and they only have to be multithreaded when it comes to synchronising them to a timeline thread to put them all back in order."

Teda renering bezi na jednom jadre. Ai na inom, fyzika na dalsom. Myslim ze AI a fyzika bola celkom dobra uz v hl2, takze tymto vlastne menia uz aj gro hry.

Fine-grain threading: takes a more intricate approach. The idea behind this method of threading is to take many similar or identical tasks and spread them across cores - for example, taking a loop that iterates over an array of data. In the case of a 1000 loop process, you just split it up by the number of cores. You need to make sure that each of the operations is independent and doesn't affect another data set - but this is tricky to do, because the time per work unit can be variable and managing the timeline of outcomes and consequences can get difficult.

Takze do threadov rozdeluju uz aj "single threaded veci", ktore same o sebe bezia dost dlho na to, aby malo zmysel ich delit a znova spajat. Napr. cyklus, ktory sa iteruje 1000x (a v kazdom ktoru napr. modifikuje nejaky objekt) rozdelis medzi viacero jadier, kazde z nich vykona nejaku inu iteraciu z tych 1000. Ale hned sa tam aj pise, ze toto je velmi tazke dosiahnut a neda sa to vyuzit vsade, takze to maju pouzite iba tam, kde sa im to podarilo rozumne implementovat. Myslim ze toto zasahuje aj do "gra enginu".

a nakoniec:

Hybrid threading: is the approach that Valve eventually decided to take. It is, you'll be unsurprised to learn, a mixture of coarse and fine threading. "It's attempting to use the appropriate tool for the job in multiple combinations," according to Tom. "So, some systems operate really well just being parked on a core - an example is sound mixing. It doesn't really interact, doesn't really have a frame constraint, it works on its own set of data, and so it's really happy being pushed off."

Teda tu sa pise, ze napr. zvuk dali do oddeleneho threadu. To myslim tiez zasahuje do gra hry. Tiez treba este brat v uvahu, kolko ludi ma SB audigy, a kolko ma integrovanu "softwareovu" zvukovku na doske - u tychto ludi je spracovanie zvuku este narocnejsie na procesor.



a este...

Hybrid rendering: One example is in calculating what is going to be rendered, and this relies on a critical part of the Steam engine, the 'world list'. "We first have to figure out - what are the areas of the BSP that you're going to render? Then, okay, what objects are in those portions? Up until the point that you're actually going to draw them, you're CPU bound. You have to work out all these calculations from multiple points of view - the player's view, then say, the view of TV monitors in the scene, then the point of view of reflections in water."

"To apply a hybrid threading model, we revised the pipeline. Now, we construct the rendering list from the world list in parallel - we can calculate the TV, water and player rendering lists at the same time across cores. We can then do things like running all the character bone transforms across the cores, too."

Nebavili sme sa tu niekolko stranok dozadu, ze rendering sa neda /sa velmi zle paralelizuje? Valve to zvladli. A teraz otazka - bude episode 2 3x drahsia (ako tu eagle tvrdi ze multithreaded vyvoj je 3x drahsi) ako episode 1? Nemyslim.

Tiez mam nejake take tusenie, ze unreal engine 3 bude do istej miery vyuzivat mutithreading (aspon tak, aby vedel rozumne vyuzit druhe jadro)

Protože jsem ekonom a tohle mě nezajímá. Hry hraju jen staré (= ty, které měly nějakou hratelnost a nápad) a v IT by mě nikdo adekvátně nezaplatil.

no mne to dost casto pripada ako, protože JÁ a ostatní me nezajíma.

[Eagle]

2 THX: Fakt mám čím dál tím víc pocit, že jsi nikdy nic neprogramoval. Poukazování na to, že zápis = zamčeno, je neskutečná hloupost. Kdyby šlo jen o čtení, tak se jedná o zcela nezávislé záležitosti, u kterých by se žádná synchronizace nemusela řešit, a tedy by nebyl potřeba žádný zámek. Takových situací ale jistě nebude mnoho. Protože kdyby bylo, tak je multithreading legrace.

A k té reakci na PiTa - už tady kolikrát zaznělo, že AI, fyzika a rendering jsou čistě sériové záležitosti, neboť nemůžeš renderovat něco, o čem nevíš, jak se bude pohybovat. Pokud to někdo dělá nezávisle, tak to vede ke zhoršení výstupní kvality. Hodláš-li operovat se slovy typu "Valve to zvladli", tak laskavě dokaž, jak si to zvládnutí představuješ reálně provedené tak, aby to nebyla z nouze ctnost. Řeknu ti to samé co Petrikovi - pokud chceš, abychom se nadále nad tímto tématem bavili, přednes tady konkrétní programátorská řešení, jak bys to udělal. Kecy stažené z webu mě nezajímají, protože programátoři by samozřejmě nikdy veřejně nepřiznali, že jimi provedený multithreading je za cenu snížení kvality - u kodeku H.264 to taky běžně neříkají, protože to není věc, kterou by se mohli chlubit.


Uff, mám pocit, že jedině Fox!MURDER tady ví, o co kráčí.


PS: Samozřejmě, že mě zajímá to, co je výhodné pro mě. Co je dobré pro tebe, je mi úplně fuk. Tohle je kapitalismus, společnost preferující individualismus a vlastní užitek.

[THX]

2 THX: Fakt mám čím dál tím víc pocit, že jsi nikdy nic neprogramoval. Poukazování na to, že zápis = zamčeno, je neskutečná hloupost. Kdyby šlo jen o čtení, tak se jedná o zcela nezávislé záležitosti, u kterých by se žádná synchronizace nemusela řešit, a tedy by nebyl potřeba žádný zámek. Takových situací ale jistě nebude mnoho. Protože kdyby bylo, tak je multithreading legrace.

Ale ved tam ti prave ludia od valve pisu, ze takychto situacii, kedy sa len cita je 95% a zamykanie (a teda nemoznost paralelneho spracovania) nastava iba v 5% pripadov.

A k té reakci na PiTa - už tady kolikrát zaznělo, že AI, fyzika a rendering jsou čistě sériové záležitosti, neboť nemůžeš renderovat něco, o čem nevíš, jak se bude pohybovat. Pokud to někdo dělá nezávisle, tak to vede ke zhoršení výstupní kvality.

pozri - valve dokaze pri renderingu paralelne pocitat pohlady z roznych kamier, efekty atd. A nie nemam ti to ako dokazat, pretoze k zdrojakom sa asi v zivote nedostanem. Snad ked vyjde ta hra, tak si ju budes moct obenchmarkovat na jednom a na viacerych jadrach.

Hodláš-li operovat se slovy typu "Valve to zvladli", tak laskavě dokaž, jak si to zvládnutí představuješ reálně provedené tak, aby to nebyla z nouze ctnost.

ty si tu prezentoval jeden nazor (zalozeny na nespravnom pochopeni, ze locking nepouzivaju a teda u nich dochadza k strate integrity dat) a prezentujes ho ako spravny. Dokaz mi, ze to valve robi prave tak ako si napisal. Pozri si ten clanok znova - tam je dost do podrobna napisane, ako to spravili, ako a preco ktore veci paralelizovali.

Řeknu ti to samé co Petrikovi - pokud chceš, abychom se nadále nad tímto tématem bavili, přednes tady konkrétní programátorská řešení, jak bys to udělal. Kecy stažené z webu mě nezajímají, protože programátoři by samozřejmě nikdy veřejně nepřiznali, že jimi provedený multithreading je za cenu snížení kvality - u kodeku H.264 to taky běžně neříkají, protože to není věc, kterou by se mohli chlubit.

To mi pride ako keby sa tajilo, ze audio/video kodeky su stratovou kompresiou. Stoji ta strata kvality za to? Ano, stoji to zrychlenie enkodingu za to, ano.

Tiez by som mohol napisat:
Kecy nejakeho eagla stazene z webu (napr. tvoje recenzie), alebo z fora nemusia tiez kazdeho zaujimat, protože eagle by samozřejmě nikdy veřejně nepřiznal, že se mohl mylit.

A co sa tyka dokazov - urobme to naopak. Ty mi dokaz, ze niektore veci NIE JE MOZNE multithreadovat.

PS: Samozřejmě, že mě zajímá to, co je výhodné pro mě. Co je dobré pro tebe, je mi úplně fuk. Tohle je kapitalismus, společnost preferující individualismus a vlastní užitek.

Mozno ta prekvapim, ale tohne neni kapitalizmus, toto je overclocker a enthusiast diskusne forum, kde tvoje prispevky citaju aj iny ludia ako ty, a niekedy niektorych nemusi zaujimat iba ze pre teba je DC na hovno, a ze v tvojich programoch to nejde dobre vyuzit a ze ty si ekonom a kapitalista atd.
Prave diskusia (a prispevky do nej) by mala byt taka, aby citatel ziskal po precitani nove informacie (a nie iba niecie osobne nazory a postoje).

[Eagle]

Ale ved tam ti prave ludia od valve pisu, ze takychto situacii, kedy sa len cita je 95% a zamykanie (a teda nemoznost paralelneho spracovania) nastava iba v 5% pripadov.

95 nezávislých + 5 závislých situací != 100 situací s 5% pravděpodobností závislosti

pozri - valve dokaze pri renderingu paralelne pocitat pohlady z roznych kamier, efekty atd.

To možná ano, ale na to už potřebuješ mít hotovou fyziku, která je sériová.

si ju budes moct obenchmarkovat na jednom a na viacerych jadrach.

Benchmark ti řekne jen výkon. Pokud tento není za jinak stejných okolností (což třeba u WinRARu není), pak je výsledek zavádějící.

To mi pride ako keby sa tajilo, ze audio/video kodeky su stratovou kompresiou. Stoji ta strata kvality za to? Ano, stoji to zrychlenie enkodingu za to, ano.

Mně ne, já vždycky preferuju co nejvyšší kvalitu. Proto mám třeba hardware takový, jaký mám - novější totiž obsahuje více chyb, což mi za ten dodatečný výkon nestojí. Až je vychytají, bude upgrade. Do té doby nic.

A co sa tyka dokazov - urobme to naopak. Ty mi dokaz, ze niektore veci NIE JE MOZNE multithreadovat.

Už jsem ti tady uváděl příklad s fyzikou ve hře. Logickou posloupnost akcí v tomto případě nelze změnit (... protože je to podobné jako priorita operátorů v matematickém příkladě).

kapitalista atd.

Nejsem kapitalista. To jen na okraj.

Prave diskusia (a prispevky do nej) by mala byt taka, aby citatel ziskal po precitani nove informacie (a nie iba niecie osobne nazory a postoje).

Ano, to získal. Ale ne od vás, protože vy se jen oháníte větami typu "jde to, támhle Pepa to umí". Už ale nedokážete zdůvodnit, jak je to možné. Jen názory převzaté z webu, ale logická posloupnost vesměs žádná. Nikdo tady nebyl schopen zodpovědět, jak by bylo možné počítat fyziku ve hře paralelně s renderingem scény.

no ale to len ak by si tie odlesky pocital v jednej fukncii. Tiez by si to mohol spravit nejak tak (i ked neviem ako presne) ze by kazda fukncia pocitala iba odlesk jedneho objektu. Na zaciatku vsetky thready si nacitaju informacie o svojich objektoch, spocitaju paralelne a nakoniec zapisu pomocou zamkov. Ide len o to, ci to ma zmysel takto rozkladat - teda o kolko sa predlzi zapis koli zamykaniu oproti zrychleniu sposobenemu paralelnym vypoctom.

S tím se dá jakž takž souhlasit (ty odlesky by nesměly ovlivňovat jeden druhý, což ale asi nelze zaručit - např. odlesk postavy o vodní hladinu na skleněnou zeď, na kterou svítí ještě něco), ale bohužel tohle není paralelismus, který by ti přinesl nějaké obrovské množství výkonu navíc. Jenom kdybys měl hodně objektů, mohlo by ti to něco dát, ale to řádově tak pár desítek procent navíc IMHO. Mimochodem, není tohle náhodou věc, kterou dělá grafická karta?

[swarm]

Mno....koukám, že vás to tu ještě stále nepustilo...někteří z vás (většina?) si tu představuje programování her asi jako Hurvínek válku, tak si myslim, že ta diskuze je úplně bezpředmětná. Nebo tu snad někdo programoval nějakou hru? Klidně se přihlašte. Tady vám nikdo hlavu neutrhne .

Popravdě jsem myslel, že horší diskuze než když se baví vývojáři o sexu už být nemůže. Ale když se baví nadšenci do overclockingu o programování her, tak je to možná ještě slabší .

[Fox!MURDER]

Mno....koukám, že vás to tu ještě stále nepustilo...někteří z vás (většina?) si tu představuje programování her asi jako Hurvínek válku, tak si myslim, že ta diskuze je úplně bezpředmětná. Nebo tu snad někdo programoval nějakou hru? Klidně se přihlašte. Tady vám nikdo hlavu neutrhne .

Popravdě jsem myslel, že horší diskuze než když se baví vývojáři o sexu už být nemůže. Ale když se baví nadšenci do overclockingu o programování her, tak je to možná ještě slabší .

buhuheheh dobrej postreh ...

nahodou, ja ted budu do skoly programovat damu. a just to napisu multithreadove

[Petrik]

No jisteee, napsal jsem tetris v textovym rezimu v turbo pascalu Mimochodem, co si o tom pripravovanym valve engine myslis ty?

Mno....koukám, že vás to tu ještě stále nepustilo...někteří z vás (většina?) si tu představuje programování her asi jako Hurvínek válku, tak si myslim, že ta diskuze je úplně bezpředmětná. Nebo tu snad někdo programoval nějakou hru? Klidně se přihlašte. Tady vám nikdo hlavu neutrhne .

Popravdě jsem myslel, že horší diskuze než když se baví vývojáři o sexu už být nemůže. Ale když se baví nadšenci do overclockingu o programování her, tak je to možná ještě slabší .

[šaman]

To možná ano, ale na to už potřebuješ mít hotovou fyziku, která je sériová.

Mohl by mi nekdo vysvetlit, proc se tu po několikáté "fyzika" uvažuje jako nevhodná k paralelizování?
Podle mych informaci leží budoucnost (a vlastně už i současnost-Havoc,Ageia) simulace mechaniky (i te herni) v MBS(MultiBodySystem). A MBS je problematika,pro jejiz reseni je paralelizace velmi vyhodna.

[PiT]

THX:

Ten clanok som si cital, nemusis mi to tu prekladat. Kecy su to pekne ale jedina ukazka su tam tie videa. Pekne to tam okecavaju ale to je asi tak vsetko. Preco tam neukazali nieco realne? Ved ta hra ma vyjst o dva mesiace, gold musi byt o par tyzdnov skor...

Ak mi niekto povie, ze AI v HL2 je dobra, tak sa len zasmejem. Kvalitu nahradzali kvantitou, vsetky tie coop postavy boli naskriptovani blbci. Q3 obdobne, v D3 vylepsene, no stale obdobne. Slusna AI je imho v UnrealTournamente.

Fyziku mal HL2 dobru, ale tu som nespominal.

Ako chces paralelizovat koliznu scenu? Bez lockov velmi tazko. Jedine, ze by vymysleli nejake algoritmy, ktore rychlo pred vypoctom odhadnu nejaky kluc, na zaklade ktoreho by rozdelili scenu - a to dost pochybujem, pretoze by to sice mozno v 90% pripadov bolo rychlejsie, no v 10%ach by sa to bud rozsypalo alebo to bolo vyrazne pomalsie ako na SC... Pripadne by ani zdaleka nebolo vyuzitych viac jadier.

[edit]

Kamerovy pohlad tej istej sceny spolahlivo neparalelizujes pokial nebude kazde jadro pocitat cast udajov 2x. (a hadaj ktoru - prave koliznu, ktora zabera drvivu vacsinu casu aj na SC)

[THX]

THX:
Ten clanok som si cital, nemusis mi to tu prekladat. Kecy su to pekne ale jedina ukazka su tam tie videa. Pekne to tam okecavaju ale to je asi tak vsetko. Preco tam neukazali nieco realne? Ved ta hra ma vyjst o dva mesiace, gold musi byt o par tyzdnov skor...

Ja myslim ze nechceli ukazovat viac z hry pred vydanim. Ak su tak skoro k dokonceniu, tiez by si mohol nadavat, ze preco este nevyslo demo.

Ak mi niekto povie, ze AI v HL2 je dobra, tak sa len zasmejem. Kvalitu nahradzali kvantitou, vsetky tie coop postavy boli naskriptovani blbci. Q3 obdobne, v D3 vylepsene, no stale obdobne. Slusna AI je imho v UnrealTournamente.

ja len tvrdim, ze AI je v hl2 "gro hry". V q3 nejaka ai skoro vobec nebola, lebo hra bola viac multiplayerovo zamerana. Snad teraz ked bude k dispozicii vyssi vykon pre AI (vdaka paralelizacii a dalsim jadram) sa to zlepsi. Inac single player hry prave koli nizkej AI velmi nehram. Tych blbeckov z HL2 co blokuju chodby som vzdy okamzite postrielal nech nezavadzaju (teda - ak to v danom mieste dovoloval skript ich pozabijat).

Ako chces paralelizovat koliznu scenu? Bez lockov velmi tazko. Jedine, ze by vymysleli nejake algoritmy, ktore rychlo pred vypoctom odhadnu nejaky kluc, na zaklade ktoreho by rozdelili scenu - a to dost pochybujem, pretoze by to sice mozno v 90% pripadov bolo rychlejsie, no v 10%ach by sa to bud rozsypalo alebo to bolo vyrazne pomalsie ako na SC... Pripadne by ani zdaleka nebolo vyuzitych viac jadier.

ale ved predsa oni zamykanie pouzivaju...

[edit]
Kamerovy pohlad tej istej sceny spolahlivo neparalelizujes pokial nebude kazde jadro pocitat cast udajov 2x. (a hadaj ktoru - prave koliznu, ktora zabera drvivu vacsinu casu aj na SC)

Povedal by som, ze pohlad z kamery je vec, ktora nejak velmi nemodifikuje objekty na ktore sa pozera. Prave preto si viem predstavit ze dva rozne jadra pocitaju pohlady z dvoch roznych kamier. Ak by si tie jadra nemal dva, tak single core by ti tak ci tak muselo spocitat pohlad z tej druhej kamery.

[PiT]

Ja myslim ze nechceli ukazovat viac z hry pred vydanim. Ak su tak skoro k dokonceniu, tiez by si mohol nadavat, ze preco este nevyslo demo.

Skor si myslim, ze je to preto, lebo tu ich dokonalu paralelizaciu poznas v novej hre len vdaka efektom ako ten dazd a ked to portujes na HL2 a EP1, tak tam bude narast podobny ako u Q4 = max 10-25%, imho skor este mensi.

ja len tvrdim, ze AI je v hl2 "gro hry".

A to je imho to, co bez odrbov neparalelizujes. Odrby = naskriptovanost. Naskriptovanost != AI.

Snad teraz ked bude k dispozicii vyssi vykon pre AI (vdaka paralelizacii a dalsim jadram) sa to zlepsi. Inac single player hry prave koli nizkej AI velmi nehram. Tych blbeckov z HL2 co blokuju chodby som vzdy okamzite postrielal nech nezavadzaju (teda - ak to v danom mieste dovoloval skript ich pozabijat).

jj, AI tam takmer nebola... a ta, co bola, tu imho neparalelizujes

ale ved predsa oni zamykanie pouzivaju...

hej, ale prave to zamykanie ti z principu spravi z vyhody viacerych threadov nevyhodu, lebo bude vypocty predlzovat a zvysne jadra sa budu flakat. Tych 95% lock-free pripadov moze snad nastat iba v pripade, ze hovoria cisto o ich "skript-AI".

Povedal by som, ze pohlad z kamery je vec, ktora nejak velmi nemodifikuje objekty na ktore sa pozera. Prave preto si viem predstavit ze dva rozne jadra pocitaju pohlady z dvoch roznych kamier. Ak by si tie jadra nemal dva, tak single core by ti tak ci tak muselo spocitat pohlad z tej druhej kamery.

Ak ma kamera ukazovat to, co sa deje na scene, tak musi pred tym nasledovat vypocet koliznej sceny, ktory ti zaberie drvivu vacsinu vypocetneho casu, a ktory imho spolahlivo neparalelizujes, nakolko by si musel pri tej paralelizacii bud urcit presne hranice objektov alebo sa Ti moze lahko stat, ze cez seba dva objekty na scene preletia. Ak to chces pocitat poctivo, tak proste 80-100% narast vykonu s dvoma a viac jadrami nedosiahnes, preto som napisal, ze su to pekne okecavacky.

[THX]

No ale este moze nastat situacia, ze tie dve kamery nevidia tu istu scenu a pre tu druhu mozno teda pocitat kolizie paralelne.

[Fox!MURDER]

Uff, mám pocit, že jedině Fox!MURDER tady ví, o co kráčí.

Zas me prilis neprecenuj. S threadama mam zkusenosti jen minimalni (v C a par skriptovacich jazycich - napr. perl) a hru jsem taky zadnou nenapsal. Spis se na to snazim koukat 'selskym rozumem' a vnest do toho trochu vlastni invence.
Zrovna ted mi vrta hlavou jak by byly realizovatelny ty transakce (hlavne transakcni izolace) na pametovy urovni.


THX: vis ten problem s tema zamkama je trosku jinej. ono totiz nepotrebujes zamky jen pri zapisu. pokud mas scenar takovej ze mas napr. dva thready, ktery posouvaj bod po obrazovce, muze nastat nasledujici situace

#include <stdio.h>
#include <pthread.h>
#include <stdlib.h>
int a=0;
int b=0;
pthread_mutex_t mut_a = PTHREAD_MUTEX_INITIALIZER;
pthread_mutex_t mut_b = PTHREAD_MUTEX_INITIALIZER;

void *f_thread1(void *);
void *f_thread2(void *);
int main(void)
{
     pthread_t thread1, thread2;
     int  iret1, iret2;
     int  i1=1,i2=2;
     iret1 = pthread_create( &thread1, NULL, f_thread1, (void*) i1 );
     iret2 = pthread_create( &thread2, NULL, f_thread2, (void*) i2 ) ;
     pthread_join( thread1, NULL);
     pthread_join( thread2, NULL);

     printf("a = %d\n",a);
     printf("b = %d\n",b);
     exit(0);
}


void *f_thread1(void *q){
 int x=0;
 for(x=0;x<65535;x++)
 {
        int temp1, temp2;
        {
#ifdef WHOLELOCK
                pthread_mutex_lock(&mut_a);
                pthread_mutex_lock(&mut_b);
#endif
                temp1=a+1;
                temp2=b+1;
#ifndef WHOLELOCK
                pthread_mutex_lock( &mut_b);
#endif
                b=temp2;
#ifndef WHOLELOCK
                pthread_mutex_unlock(&mut_b);
                pthread_mutex_lock(&mut_a);
#endif
                a=temp1;
#ifndef WHOLELOCK
                pthread_mutex_unlock(&mut_a);
#endif
#ifdef WHOLELOCK
                pthread_mutex_unlock(&mut_a);
                pthread_mutex_unlock(&mut_b);
#endif
        }
 }
}
void *f_thread2(void *q){
 int x=0;
 for(x=0;x<65535;x++)
 {
        int temp1, temp2;
        {
#ifdef WHOLELOCK
                pthread_mutex_lock(&mut_a);
                pthread_mutex_lock(&mut_b);
#endif
                temp1=a-1;
                temp2=b-1;
#ifndef WHOLELOCK
                pthread_mutex_lock( &mut_b);
#endif
                b=temp2;
#ifndef WHOLELOCK
                pthread_mutex_unlock(&mut_b);
                pthread_mutex_lock(&mut_a);
#endif
                a=temp1;
#ifndef WHOLELOCK
                pthread_mutex_unlock(&mut_a);
#endif
#ifdef WHOLELOCK
                pthread_mutex_unlock(&mut_a);
                pthread_mutex_unlock(&mut_b);
#endif
         }
 }
}

livecd ~ # gcc -pthread threadtest.c -DWHOLELOCK -o tt-wholelock
livecd ~ # gcc -pthread threadtest.c -o tt-nowholelock
livecd ~ # ./tt-nowholelock
a = 429
b = 702
livecd ~ # ./tt-wholelock
a = 0
b = 0
livecd ~ # ./tt-wholelock
a = 0
b = 0
livecd ~ # ./tt-wholelock
a = 0
b = 0
livecd ~ # ./tt-wholelock
a = 0
b = 0
livecd ~ # ./tt-wholelock
a = 0
b = 0
livecd ~ # ./tt-nowholelock
a = 181
b = 73
livecd ~ # ./tt-nowholelock
a = 340
b = -61
livecd ~ # ./tt-nowholelock
a = -4862
b = 333
livecd ~ # ./tt-nowholelock
a = 588
b = 257
livecd ~ #

tj. jeden thread posouva ten bod (klidne to muze bejt v pripade 3D treba kvadr, nebo neco jinyho) o 1 doprava a o 1 nahoru, druhej posouva bod o 1 doleva a o 1 dolu. kazdej z nich to udela 65536krat. tj. bod by mel ve vysledku skoncit na miste, kde zacal (pravej dolni roh napr.) jenze, kdyz zamykam jen pri zapisu, ejhle ... ono to skonci na uplne nepredvidanym miste.


a jeste dodam, ze to samozrejme dosti podobne kravi i na singlecore
(testuju na C2D E6300 a CeleronuD 325, oboje Gentoo s nptl a gcc 4.1)


kdyby nekdo mel problem s pochopenim toho C kodu, tak dejte vedet, ja to vysvetlim...

jooo a vim ze by to asi slo napsat jednodusejs a prehlednejs, ale a) jsem prase, b) nemam cas si s tim tak moc hrat

[PiT]

Fox!MURDER:

Teraz som zvedavy ako by pomohlo to optimalizovanie kompileru, ktore THX navrhoval par stran dozadu

[Fox!MURDER]

Fox!MURDER:

Teraz som zvedavy ako by pomohlo to optimalizovanie kompileru, ktore THX navrhoval par stran dozadu

no, v tomhle ohledu si pockame, s cim intel prijde treba vytahnou neco, ze nam vsem padne celist, treba ne ...

[THX]

pit - ten kompiler ma optimalizovat iba rychlost, teda ma hladat v kode "paralelizovatelne" casti a tie sa snazit pustat naraz - neopravuje chyby v programe

Fox: vsetky locky/unlocky mas v ifndef, teda ked nedas WHOLELOCK, tak nezamykas vobec - ani pri zapise. Navyse - niekedy zamykas/odomykas znova uz zamknutu/odomknutu vec (snad to nevadi, ale nemalo by sa )

[Masster]

Nebavili sme sa tu niekolko stranok dozadu, ze rendering sa neda /sa velmi zle paralelizuje? Valve to zvladli. A teraz otazka - bude episode 2 3x drahsia (ako tu eagle tvrdi ze multithreaded vyvoj je 3x drahsi) ako episode 1? Nemyslim.

Episoda 2 samozrejme 3x drazsi nebude a to z jednoho prosteho duvodu.
Valve nevyviji Source engine jen pro Episodu 2, ale pouziva ho pro x dalsich projektu a od vydani HL2 se na enginu neustale pracuje.