Vyznam dual core

[Eagle]

blablabla

Ty neumíš číst? Přímo na CDR ti to v diskuzi vysvětlil WoodyIS. Dovolím si citaci:

"Nic ve zlem, ale docela jsem se pobavil u vety: "Přistupují k tomu celkem logicky tak, že pustí o jedno méně podřízených vláken, než je počet jader a k tomu jedno hlavní vlákno, které se stará mimo jiné i o synchronizaci". Problem totiz neni v tom, kolik vlaken vytvorit, ale co do nich dat tak, aby intenzivne pracovala na svych datech a byla navzajem nezavisla, aby na sebe navzajem nemusela cekat. Protoze je to jedna cast me prace, tak sem se tesil, jak nam to Gabe prozradi a ono nic "

[THX]

Ty neumíš číst? Přímo na CDR ti to v diskuzi vysvětlil WoodyIS. Dovolím si citaci:

"Nic ve zlem, ale docela jsem se pobavil u vety: "Přistupují k tomu celkem logicky tak, že pustí o jedno méně podřízených vláken, než je počet jader a k tomu jedno hlavní vlákno, které se stará mimo jiné i o synchronizaci". Problem totiz neni v tom, kolik vlaken vytvorit, ale co do nich dat tak, aby intenzivne pracovala na svych datech a byla navzajem nezavisla, aby na sebe navzajem nemusela cekat. Protoze je to jedna cast me prace, tak sem se tesil, jak nam to Gabe prozradi a ono nic "

"We gravitated towards creating a custom work management system that's designed specifically for gaming problems - its job is to keep the cores 100% utilised. We make it so that there are N-1 threads for N cores, with the other thread being the master synchronisation thread. The system allows the main thread to throw off work to as many cores as there might be available to run on, and it also allows itself to be subjugated to other threads if needs be."

The engine uses lock-free algorithms to solve one of the major problems of threading - access to data. Many of us have come across a similar problem before - if you're trying to edit a database or a web page whilst someone else is already doing a similar thing, you end up with one person overwriting the other person's data. The problem is the same when it comes to multiple threads accessing one data set in-game.

"We realised that, 95% of the time, you're trying to read from a data set, and only 5% of the time are you actually trying to write to it, to modify 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."


viac -> http://www.bit-tech.net/gaming/2006/...e_Engin/1.html

[Eagle]

blablabla

A co to jako dokazuje tahle tvoje citace? To mi netvrď, že jsi programoval multithreadově, když mi na mojí poznámku odpovídáš tímhle.

[THX]

"We realised that, 95% of the time, you're trying to read from a data set, and only 5% of the time are you actually trying to write to it, to modify 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."

Zamykanie teda pouzivaju, ale zistili ze nastane iba v 5% pripadov, preto povolili citanie bez zamku. Co je na tom nepochopitelne?

[Eagle]

Zamykanie teda pouzivaju, ale zistili ze nastane iba v 5% pripadov, preto povolili citanie bez zamku. Co je na tom nepochopitelne?

"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ů."

Už chápeš ten nesmysl textu?

blaboly

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.

[Fox!MURDER]

"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ů."

Už chápeš ten nesmysl textu?

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

[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 ...

[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.

[Petrik]

Jelikoz jsme tu vsichni (nebo min. vsichni co s tebou nesouhlasi) proti tobe asi jen tlupa blbcu s deficitem inteligence, nasel jsem ti doufam alespon trochu oponenta na urovni. Nejakej clovek jmenem Sambous1 v debate o valve a jeho engine http://www.cdr.cz/a/diskuze/8684/0#140288 napsal:

No predelavat hry co uz jsou.... je asi mrhani zdrojema , ale do budoucna je to nutnost... multicore je budoucnost tak proc to nevyuzit... a narust vykonu roste matematicky s poctem jader... u hernich engines budoucnosti se stim urcite pocita...nas engine uz ma podporu ncores/cpus uz prakticky od zacatku... predelavat jiz hotovej engine bude-je urcite dost narocny... u jiz napsanejch her.. byl problem hned od toho co se multicore reseni objevilo..... baz patchu ve voknech a modifikovanejch driverech procaku se prakticky kazda stara hra na multi core cukala kuli diferentnimu casu na jadrech.

Jestli te zajimaji konkretni algoritmy ci primo casti kodu, muzes si s nim o tom popovidat. Az ti vysvetli, jak udelat MT herni engine, aniz by to byla "prasarna se snizenou vystupni kvalitou" , podelis se o to s nama? Jestli te to opravdu zajima, jak tady porad tvrdis, urcite bys ho mel zkontaktovat Pak se treba uvidi, jetli "pravda boli", jak jsi napsal me

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.

[Petrik]

Eagle, nechci ti do toho kecat, ale co to ma co spolecnyho s tim, ze jim to dost pravdepodobne funguje? Ze nejaky WoodyIS nevi, jak to udelat, me uprimne moc nezajima. Spise me zajima, ze nekdo ve Valve to zrejme vi a ze mu to uz pravdepodobne funguje. Treba to je jen nejaka marketingova bublina, ale jestli jim to funguje a bude jim to uspesne fungovat i na mnoha jadrech, tak to je rozhodne pozitivni vec, ne? Krome toho to taky bude znamenat, ze jsi nemel pravdu, coz me uprimne ani moc netrapi. Me jen fascinuje, jak se zuby nechty snazis dokazat, ze neco, co uz nekomu velmi pravdepodobne funguje, nemuze fungovat. To, ze ty nevis, jak neco udelat, jeste neznamena, ze to nevi nikdo na svete. Premyslej o tom. Krome toho docela nechapu, proc se tak hrozne moc snazis delat anti-MC (multi core) kampan. Ty snad vazne chces, abychom zustali na veky veku u jednoho jadra a neslu nikam dal.

Ty neumíš číst? Přímo na CDR ti to v diskuzi vysvětlil WoodyIS. Dovolím si citaci:

"Nic ve zlem, ale docela jsem se pobavil u vety: "Přistupují k tomu celkem logicky tak, že pustí o jedno méně podřízených vláken, než je počet jader a k tomu jedno hlavní vlákno, které se stará mimo jiné i o synchronizaci". Problem totiz neni v tom, kolik vlaken vytvorit, ale co do nich dat tak, aby intenzivne pracovala na svych datech a byla navzajem nezavisla, aby na sebe navzajem nemusela cekat. Protoze je to jedna cast me prace, tak sem se tesil, jak nam to Gabe prozradi a ono nic "

A jinak cist neumis spise ty, eagle:
The engine uses lock-free algorithms to solve one of the major problems of threading - access to data. Many of us have come across a similar problem before - if you're trying to edit a database or a web page whilst someone else is already doing a similar thing, you end up with one person overwriting the other person's data. The problem is the same when it comes to multiple threads accessing one data set in-game.

Aby nedoslo k nedorozumeni, tak ti to prelozim. Oni tvrdi, ze jejich engine vyresil ten problem synchronizace tak, ze zadna synchronizace zrejmne neni Neptej se me jak, ale zrejmne nejakym novym zpusobem pristupu k datum. To mi pripomina reiser4 (linux FS), ktery funguje "atomarne". Operace budto probehnou uplne, nebo vubec. Zajimave na tom je to, ze neni potreba duplikovat data. Proste u obou zrejmne nejaky extra vychytany algoritmus. Takze opet jedna rada: v IT oboru nepouzivej slova jako "nikdy" nebo jako v tomto pripade "musis". Oni proste nejakou tvoji sychronizaci zajistit zrejmne nemusi. tecka

Muhehe. Ty jsi nikdy nemohl nic programovat multithreadově (zda jsi vůbec kdy programoval), protože tahle citace je úplně o ničem. Když máš nějaká data v RAM (typicky dynamická) a máš víc threadů s pointery na ně, tak musíš zajistit sychronizaci, aby ti některý z threadů nenačetl stará data dřív, než jsou přepsána aktuálními jiným threadem (to je mimochodem jeden z největších problémů i u více než jednoho CPU z pohledu hardware - synchronizace zpožděných zápisů do RAM). Tím, že uvolníš uzdu a umožníš čtení v libovolný okamžik, způsobíš to, že některé thready budou používat stará data, a tedy dojde k porušení integrity dat! Je samozřejmě možné, že Valve udělalo něco takového pro věci, kde je limitem lidské oko / vstup z periferií, a tedy tato prasárna nebude na první pohled poznat, jenže to není správná metoda multithreadingu, ale krok udělaný z nouze a s nepříznivými důsledky.

A ten největší problém multithreadingu je vytvořit víc než jedno vlákno, které budou mít pořád co dělat. Fakt si myslím, že jsi nikdy nic multithreadově neprogramoval, protože jinak bys tyhle elementární věci znal.

[PiT]

Petrik:

Uvidime, az vide EP2

[Eagle]

Eagle, nechci ti do toho kecat, ale co to ma co spolecnyho s tim, ze jim to dost pravdepodobne funguje?

To, že někdo sníží výstupní kvalitu a udělá prasárnu, kterou by si v normální situaci nemohl dovolit, neboť by tím program zhavaroval, ty považuješ za fungování? Nemáš vůbec žádné zkušenosti s programováním a celou dobu tady šíříš jen svoje ničím nepodložené teorie a bujné představy. Citace uvedená v textu je o ničem, protože takto to nemůže fungovat, aniž by v tom byl nějaký háček typu destrukce integrity dat. A pokud si myslíš, že může, tak uveď konkrétní postup, jak to udělat. Už jednou se ti to nepovedlo, tak máš druhou šanci.

Mimochodem, říkal jsem ti, že se s tebou nebudu bavit. Jednak se neumíš chovat a zadruhé nepřinášíš do diskuze žádné zajímavé informace, pouze distribuuješ svoje představy založené na jakýchsi tvrzeních z webu, aniž by ses zamyslel, nakolik jsou pravdivá. Od lidí, se kterými se bavím, předpokládám určitou inteligenci. Když jí druhá strana neoplývá, pak je taková diskuze pro mě ztrátou času. Čili pokud chceš, abychom tu nadále nad tématem DC diskutovali, uváděj nějaké konkrétní programátorské postupy, jak si multithreadování představuješ. Obecné plky mě neberou.

Krome toho docela nechapu, proc se tak hrozne moc snazis delat anti-MC (multi core) kampan.

Nedělám anti-MC kampaň, jen říkám pravdu. Ono to bolí, viď? Tvoje ideály a teorie se pod tíhou faktů rozpadají.

[Petrik]

Tyhle blaboly nebudu komentovat. Jen ti doporucim, aby sis precetl cely clanek, ze ktereho tu bylo citovano: http://www.bit-tech.net/gaming/2006/...e_Engin/1.html
Kdyz neveris takovymu loserovi, jako jsem pro tebe ja, treba mozna, mozna uveris vyvojarum ve Valve, ikdyz mi je jasny, ze proti tobe to jsou vylozeny zabari. A jak znam hry od valve, jsem na 100% presvedceny, ze ten jejich multi-threaded engine bude vylozene "prasarna se snizenou vystupni kvalitou" Tos me vazne pobavil

To, že někdo sníží výstupní kvalitu a udělá prasárnu, kterou by si v normální situaci nemohl dovolit, neboť by tím program zhavaroval, ty považuješ za fungování? Nemáš vůbec žádné zkušenosti s programováním a celou dobu tady šíříš jen svoje ničím nepodložené teorie a bujné představy. Citace uvedená v textu je o ničem, protože takto to nemůže fungovat, aniž by v tom byl nějaký háček typu destrukce integrity dat. A pokud si myslíš, že může, tak uveď konkrétní postup, jak to udělat. Už jednou se ti to nepovedlo, tak máš druhou šanci.

Mimochodem, říkal jsem ti, že se s tebou nebudu bavit. Jednak se neumíš chovat a zadruhé nepřinášíš do diskuze žádné zajímavé informace, pouze distribuuješ svoje představy založené na jakýchsi tvrzeních z webu, aniž by ses zamyslel, nakolik jsou pravdivá. Od lidí, se kterými se bavím, předpokládám určitou inteligenci. Když jí druhá strana neoplývá, pak je taková diskuze pro mě ztrátou času. Čili pokud chceš, abychom tu nadále nad tématem DC diskutovali, uváděj nějaké konkrétní programátorské postupy, jak si multithreadování představuješ. Obecné plky mě neberou.

Nedělám anti-MC kampaň, jen říkám pravdu. Ono to bolí, viď? Tvoje ideály a teorie se pod tíhou faktů rozpadají.

Ted pro vsechny: Dost me tam zaujal zaver:
But the chance of physics cards taking off is pretty minimal if we draw inferences from the views of Newell on hardware. He talks enthusiastically of the "Post-GPU world" - rather like the one envisaged by AMD and ATI with their Fusion project. In this world, we see a number of homogenous CPU cores all tasked with different projects - including graphics rendering. This allows for more flexibility when it comes to splitting up workloads, and means that engine-functions such as AI and physics can become a more integral part of the gaming experience because of the scalability such an architecture adds. "All of a sudden," raves Gabe, "If your AI isn't running fast enough, you can lower your graphics resolution. That's some awesome flexibility."

Ono to je docela logicke. Graficke karty se zacinaji stale vice podobat beznym procesorum a naopak nektere procesory, napr. cell, se zacinaji napadne podobat GPUckam. Ten 80-ti jadrovy terra chip od intelu je zrejmne tim, co mel autor citovaneho prispevku na mysli. Vysoce univerzalni, masivne paralelni a velmi vykonny CPU+GPU.