Vyznam dual core

[Petrik]

No jasne ze to s fyzikou nema nic spolecneho tohle je pouze rendering sceny. To byla reakce na to, jak Eagle tvrdil, ze krome fyziky nema cenu nic jineho paralelizovat. Kdyby to skutecne nemelo cenu, tak by se s tim ve Valve asi nedelali, ze. O tom, jakym zpusobem je delana fyzika jsem nikde nic nenasel, ale predpokladam, ze u ni aplikovali fine grained therading, predevsim asi proto, ze u pokrocilych fyzikalnich enginu jako je treba havok, by to nemel byt problem. A jsem rad, ze tu alespon nekdo z odborniku potvrdil, ze to, co jim uz realne funguje, je skutecne mozne udelat, coz Eagle porad odmita prijmout jako fakt.
Takze eagle: uvazujme nyni, ze fyziku to skutecne dela MT a paralelne to dela jen ty veci, ktere na sobe nejsou zavisle, cili zadna prasara se nekona, coz je IMHO od valve prirozene ocekavat. Dale budu uvazovat, ze plati ten vyrok, ze s mene nez 4-mi jadry by to, co predvadeli na tom demu, proste udelat neslo. Co na "vyznam dualcore" reknes potom? Aby to bylo jeste jasnejsi: vse nasvedcuje tomu, ze vetsina high-end novych her, postavenych na Unreal engine 3, Source engine ci na Cryo engine 2 bude na SC a casem i na DC budto uplne, nebo jen velmi spatne hratelna. A jelikoz se asi shodneme na tom, ze hry hraje hodne lidi, jak to pak tedy bude s vyznamem DC?

Ok, možná, že jsem jenom natvrdlý, ale kde se tady mluví o nějaké paralelní fyzice (tj. tom nejdůležitějším pro nějaký advantage u MC procesorů)? Ok, rendering listy pro víc scén. Jo to je možné celkem vklidu (pro nechápavé, to je rendering do textury). Počítat transformace skeletálních animací pro více charakterů najednou je taky jednoduché (ovšem nemá to s fyzikou až moc společného - skeletální transformace je ten krok, kdy už vygenerovanou kostru v nějakém pohybu "napapujeme" na konkrétní model; tj. vyřešení pootočení jednotlivých částí těla a deformace kloubů mezi nimi). Počítat stíny pro celé charaktery paralelně po několika taky neni problém.

Tohle všechno je samozřejmě fajn, ale třeba o fyzice tu nepadla ani zmínka. Ta fyzika podle mě bude úplně zásadní (zvlášť, když některé ty operace si dokážu u budoucích her představit právě přes shadery (myslim, že vertex shader 3.0 už má na ty transformace dost možností; a stejně tak i stíny by se daly řešit přes grafickou kartu - jakože to tak je i u některých her, záleží na použité technice stínování).

Btw obecně se ti vůbec nesnažím odporovat, jenom se tu snažím naznačit, že tvůj způsob diskuze:

1 - přehodit citát z nějaké stránky aniž k tomu cokoli napíšeš, totálně bez tvého názoru (který pravděpodobně hlubší k dané problematice ani nemáš)
2 - chtít po ostatních, aby na to reagovali stylem: "tak co na to napíšeš?"

...se mi vůbec nelíbí. Pokud chceš proti někomu diskutovat, tak se snaž text pochopit a těmi nejdůležitějšími body konfrontuj protivníka v diskuzi. Pokud jenom z nějakého anglického textu vytáhneš pár odstavců a předhodíš to do diskuze, tak tě nikdo brát vážně nebude. Ono totiž to svědčí o tom, že třeba ten text nechápeš natolik, abys na to mohl jít jinak. Konkrétně když z tebe vypadne něco, co se týká grafických karet, tak to bych si mohl smlsnout nejspíš na každém tvém příspěvku, ale vim, že to nemá cenu. Stejně tak ani zápornou karmu jsem ještě na tomhle foru nikomu nedal a v této diskuzi se jí ode mě nikdo nedočká. To ale neznamená, že si občas nerejpnu.

[Eagle]

Co na "vyznam dualcore" reknes potom?

Ty swarma asi moc neposloucháš, viď? Jasně ti tady řekl, že obecně kecat není žádná věda. Neustále se opíráš o prohlášení kohosi, ale sám nejsi schopen přinést žádný názor, jak to udělat (zjevně z toho důvodu, že žádný nemáš, neboť tomu nerozumíš). Diskutovat s tebou je zcela bezcenné, protože i když ti napíšu na tvoje přitroublé útočné dotazy, že v tom vidím řadu problémů s deathlocky, ty si opět najdeš nějaký žvást a snažíš se to zahrávat tím směrem, že multicore je úžasná věc, bez které se neobejdeme. Tak ti tedy znovu opakuju, že dokud nebudeš schopen přinést konkrétní návrh, jak ty věci paralelně provést (tj. ne že budeš kopírovat obecné plky z netu), nebudu se s tebou na tohle téma bavit.

A k tvému dotazu - jediný, kdo mě tady přesvědčil o tom, že dual-core může mít velký význam, je Fox!MURDER a to s tím šifrováním. Ty jsi mě přesvědčil tak maximálně o tom, že k tématu nemáš co nabídnout.


2THX:

ad cena - Jasně jsem řekl, že procesor, který nemá výhodný poměr price/performance (P4), nelze brát jako etalon. Proto tvoje tvrzení o 15 % navýšení je úplně mimo. Tohle už nebudu dál probírat. S touhle logikou bych totiž mohl argumentovat, že když bude Intel nabízet P4 za 10 tisíc jako historický exponát, že C2D je velmi levný.

No praveze nie je to jedno, lebo je tam navyse polka cache (ktoru by si vedel tak vyuzit).

Cache nijak s dvoujádrem nesouvisí. Intel klidně mohl udělat single-core se 4 MB L2. Neudělal, protože by na to nemohl nabalit dual-core BS a prodávat to za dvojnásobnou cenu. Lidi nejsou zas tak hloupí, aby nevěděli, že velká cache není něco, za co by se nechali nachytat a za co by byli ochotni zaplatit dvojnásobek.

Intel nebude teraz vyvijat novy procak

Litografická maska na levný single-core Core 2 (byť jen s 1 MB L2) existuje asi tak od října a už jsou i samply. CPUID 10660, revize A0. Použijí ořezanou verzi s 512 kB L2 (zbytek deaktivovaný) pro Celeron. Taky je úplně jasné, že vývoj takového procesoru stojí jen na kosmetické změně už vyvinutého dual-core, a není tak nijak náročný.

V tom teste "solo" verzie si vypol aj polku cache?

Nevypnul, protože to nijak nesouvisí s dual-core vs. single-core. Beztak u spousty aplikací 1 MB L2 stačí, takže až na výjimky typu Photoshop nebo Civilization III by rozdíly nebyly příliš znát (latence cache, ILP a frekvence hrají mnohem větší roli). Podívej se do toho článku, jak si dual-core "skvěle" vede proti jednojádrové variantě.

lenze ak si porovnas napr. taky E6400, E6600, tak procak od AMD s rovnakym vykonom stoji viac

Víš, jakých procesorů se prodá nejvíc, zejména ve státě typu ČR ? Jsou to levné Semprony a levné A64. Takových čipů se prodává hromada, C2D E6300 je teď v cenové relaci, která je pro hodně lidí příliš vysoká. Modelů jako E6600 se u nás prodá naprosté minimum. A jen pro zajímavost - CPU v ceně nad 20 tisíc se prodá v pár desítkách, maximálně stovkách kusů za rok. Ano, uznávám, že v porovnání s E6600 je AMD dražší, ale to nic nemění na faktu, že za pár MHz navíc bych si ty horentní sumy nepřiplatil ani u Intelu, a proto je pro mě tahle kategorie nezajímavá. Beztak v téhle kategorii už single-core nejsou a nač bych platil víc za DC, když ho nevyužiju? (= E660 stojí víc jak 3x tolik co A64 3500+, ale o kolik má vyšší výkon? 20 % ?).

Som zvedavy co budes robit, ked sa za nejaky mesiac-dva pomenia ceny, prides potom prepisovat vsetky tieto posty?

Víš, ony se ty ceny změní tak, že single-core ještě zlevní. Teď máš Celeron D 347 za 1500 s DPH. P4 6xx má od ledna stát 69 dolarů (2000 s DPH). C2D zlevňovat nebude, A64 X2 asi taky ne.

preco pit limonadu...

Protože tohle, co tady uvádíš, ti přidá nějakou hodnotu (např. u té limonády chuť). Já vím, že je těžké pochopit, že dual-core nepřidá vůbec nic. Tak se ti to pokusím vysvětlit ještě jinak, polopaticky:

výkon SC: x
výkon DC v ST aplikaci: x
cena SC: y
cena DC: 2y

poměr výkon/cena u SC: x/y
poměr výkon/cena u DC: x/2y

Co má vyšší poměr? Jistě že SC. A nezmění se to do doby, než výkon u DC v ST aplikacích bude 2x nebo cena DC bude y. Ale taková situace teď není.

Ty si mu oponoval, ze DC je na h****.

Já jsem mu napsal, že až na video je na h****. Workstationy a servery pomíjím, to není desktop, aby se to tady probíralo.

tak si mal brat viu pre A64. Mobile A64 (verzia s 1mb cache) ti splna skoro vsetky poziadavky z toho tvojho zoznamu. Resp. ak sa uspokojis iba s CnQ, tak aj obyc. athlon64.

VIA tehdy nenabízela jiný SB než VT8237, který má jen 2x SATA, což mi nestačí (VT8237 mám už teď). A další výdaje spojené s CPU (tj. deska a grafika) mi za to nestály, protože nárůst výkonu by byl velmi malý (jde mi o onu cache a frekvenci, kterou A64 nemá o moc lepší než AXP.
Mobilní A64 má na desktopových deskách problémy s kompatibilitou.

velmi to pomoze pri zapisoch, pretoze tie idu do flashky, kde je velmi rychly pristup a az potom neskor (napr. ked idluje) sa prenesu na samotny disk.

Tam ti pomůže i cache OS a DRAM buffer na disku. Další prostor pro zlepšení je malý.

ked uz mozes znizovat voltaz (a tym akoze prichadzas o tu vyrobcom garantovanu stabilitu), tak mozes aj taktovat...

Pokud mi něco na default přinese jen pár desítek procent výkonu navíc a přitom to stojí majlant, tak to nepovažuju za dobrou koupi.

Mozno im nestal ten vykon za omnoho vyssiu cenu

Cena CPU je dvojnásobná i dneska (viz opět srovnání A64 3500+ vs. C2D E6300), takže zbývá jen cena desky. Ta bývá cca. dvojnásobná, to je pravda. Ale když to moc potřebuješ, tak to dáš, ne?

Prescott v pohode zvladal 1ipc, aj cache mal dost velku a aj freq., ale predsa nemal tak dobry celkovy vykon (uz len v porovnani s northwoodom, ktory mal este aj mensiu cache - a pritom mali oba rovnaky radic pamate)

NetBurst má velkou instrukční latenci, takže je jasné, že ta jeho pipeline nemůže být tak snadno naplněna, čili jeho využití jednotek je ještě horší než u C2D nebo A64. Prostě příliš mnoho stupňů vede k "bublinám".
Northwood má L2 cache o hodně rychlejší než Prescott. A taky neumí 64bit, což jeho návrh dost zjednodušuje.

Latence RAM se nemění, ale zvyšuje se propustnost, takže agresivní prefetch a velká cache můžou hodně zachránit. Kdyby ještě udělali hardwarový speculative-precomputation, podaří se jim tenhle bottleneck z velké části odbourat.

Lenze finta je v tom, ze ku kolizii ti dochadza malokedy, kym sa nejake dve veci zrazia, kolko framov predtym a potom este "letia" nezrazene? V pripade zrazky sa to proste zamkne a thready sa pockaju...

Jenže ty tu srážku musíš odhalit a to se ti bude dělat pěkně blbě, když budeš hýbat dvěma objekty současně a ne po jednom.

V tom texte je napisane, ze sa zamky pouzivaju - a teda nedochadza k nacitaniu zastaralych dat. Ziadna prasarna tam nie je, je to ciste, elegantne riesenie.

V tom textě nic takového napsané není. Je tam cosi o tom, že umožňují číst z jedné lokace více threadům, což ale předpokládá nezávislost operací. V reálu ale ty závislosti jsou a hodně. Zbytek zavání šílenými deathlocky, což sami autoři potvrzují. Jak je překonat, je snad jasné - prostě se na závislosti vykašlat a udělat to se zastaralými daty (= prasárna).

[Keymaster]

celá tahle debata má jednu zásadní vadu: akademický problém dualcore vs. singlcore se podařilo (k radosti zastánců DC) převést na povrchní debatu Athlon64 vs Core 2 Duo, kde už poměrně starý AMDčko výkonnostně nestíhá oproti nové intel technologii, z čehož se zvrácenou logikou usuzuje, že dualcore je lepší než singlecore...

[THX]

Cache nijak s dvoujádrem nesouvisí. Intel klidně mohl udělat single-core se 4 MB L2. Neudělal, protože by na to nemohl nabalit dual-core BS a prodávat to za dvojnásobnou cenu. Lidi nejsou zas tak hloupí, aby nevěděli, že velká cache není něco, za co by se nechali nachytat a za co by byli ochotni zaplatit dvojnásobek.

No, neviem, viz servrove CPU. Su podstatne drahsie - ale iba koli cache. Ak by bola 2x vacsia cache, tak by sa robil marketing o tu cache. V podstate skoro ani nezavisi aky je ten novy procesor, ake ma presne feature, hlavne ze je celkovo vykonnejsi a teda ho mozno draho predavat. Marketing by skratka propagoval inu feature, ale o tom sme sa tu uz bavili...

Víš, jakých procesorů se prodá nejvíc, zejména ve státě typu ČR ? Jsou to levné Semprony a levné A64. Takových čipů se prodává hromada, C2D E6300 je teď v cenové relaci, která je pro hodně lidí příliš vysoká. Modelů jako E6600 se u nás prodá naprosté minimum. A jen pro zajímavost - CPU v ceně nad 20 tisíc se prodá v pár desítkách, maximálně stovkách kusů za rok. Ano, uznávám, že v porovnání s E6600 je AMD dražší, ale to nic nemění na faktu, že za pár MHz navíc bych si ty horentní sumy nepřiplatil ani u Intelu, a proto je pro mě tahle kategorie nezajímavá. Beztak v téhle kategorii už single-core nejsou a nač bych platil víc za DC, když ho nevyužiju? (= E660 stojí víc jak 3x tolik co A64 3500+, ale o kolik má vyšší výkon? 20 % ?).

Sice e6600 stoji 3x viac ako 3500+, ale ja ti viem ukazat fx-62, ktory ma rovnaky vykon ako 6600 a stoji este 2.5x viac...
A ano, najviac procakov sa preda lacnych, no a?
A samozrejme, tiez je jasne ze optori procesoru s najlepsim pomerom cena/vykon, budu mat vsetky ostatne tento pomer horsi. Ved aj SC s o 20% vyssim vykonom nestoji o 20 ale o 50% viac...

Víš, ony se ty ceny změní tak, že single-core ještě zlevní. Teď máš Celeron D 347 za 1500 s DPH. P4 6xx má od ledna stát 69 dolarů (2000 s DPH). C2D zlevňovat nebude, A64 X2 asi taky ne.

a potom zmenis tie tvrdenia ze p4 za danu cenu nema co nabidnout? Ved potom bude lacnejsi ako rovnako vykonny A64...
Budes prepisovat vsetky tie prispevky?

Protože tohle, co tady uvádíš, ti přidá nějakou hodnotu (např. u té limonády chuť). Já vím, že je těžké pochopit, že dual-core nepřidá vůbec nic. Tak se ti to pokusím vysvětlit ještě jinak, polopaticky:

výkon SC: x
výkon DC v ST aplikaci: x
cena SC: y
cena DC: 2y

poměr výkon/cena u SC: x/y
poměr výkon/cena u DC: x/2y

Co má vyšší poměr? Jistě že SC. A nezmění se to do doby, než výkon u DC v ST aplikacích bude 2x nebo cena DC bude y. Ale taková situace teď není.

tak za 1., vykon DC v ST aplikaci 1.1-1.3x v zavislosti co vsetko mi bezi na pozadi (winamp, TS, dc++, driver zvukovky atd.)
za 2., cena DC 1.2y, 1.3y, resp. v istych kategoriach vykonu obdobne SC nie je. Ty si nasiel jeden priklad kedy je cena 2x vyssia, ja som ti nasiel dva protipriklady kedy nie je - ale odmietas to uznat.

Tam ti pomůže i cache OS a DRAM buffer na disku. Další prostor pro zlepšení je malý.

nj, tak ked uz nic, aspon to znizi spotrebu, ale ak tam budu dobre nacacheovane veci, tak to moze dost pomoct (napr. pri bootovani a pod.).
To uz je ale trocha OT.

Pokud mi něco na default přinese jen pár desítek procent výkonu navíc a přitom to stojí majlant, tak to nepovažuju za dobrou koupi.

Poradim ti, pretaktuj...

Latence RAM se nemění, ale zvyšuje se propustnost, takže agresivní prefetch a velká cache můžou hodně zachránit. Kdyby ještě udělali hardwarový speculative-precomputation, podaří se jim tenhle bottleneck z velké části odbourat.

Myslim ze pre-computation by dost zvysila spotrebu.

Jenže ty tu srážku musíš odhalit a to se ti bude dělat pěkně blbě, když budeš hýbat dvěma objekty současně a ne po jednom.

tak mi prosim popis, v com presne spociva rozdiel pri pocitani fyziky seriovo a paralelne, v com sa meni algoritmus ratania kolizii a preco to sposobi tak velky problem, ak sa budu robit vypocty paralelne...

Co sa tyka toho textu - bud dobre nerozumies anglicky, alebo si to fakt necital.

V tom textě nic takového napsané není.

Ale je!

Je tam cosi o tom, že umožňují číst z jedné lokace více threadům, což ale předpokládá nezávislost operací.

spravne

V reálu ale ty závislosti jsou a hodně.

5% nepovazujem za hodne

Zbytek zavání šílenými deathlocky, což sami autoři potvrzují.

ano a hned dalsia veta popisuje riesenie

Jak je překonat, je snad jasné - prostě se na závislosti vykašlat a udělat to se zastaralými daty (= prasárna).

NIEEE, proste sa pouzije r/w lock, ziadne stare data, ziadne prasarny.

Tak este raz ten text:

The new pipeline featured so much multithreading that special efforts were needed to avoid the dreaded deadlocks and other pitfalls mentioned earlier. To accomplish this, programmer Leonard made use of a technique called lock-free algorithms. He implemented a spin lock to replace the more traditional mutexes (mutual-exclusion algorithms) and semaphores that are used to flag threads as being "safe" to multithread. The spin loop utilizes a new interlock instruction that is built into the CPU. However, there were still too many deadlocks. Tom examined the threads' activity with profiling tools, and it turned out that 95 percent of the time the threads were reading memory while only spending 5 percent of their time writing. A read/write lock allowed many threads to read the same bit of memory, but only one thread to write to it.

Takze sa pouziva spin lock a r/w lock. Co je na tom nepochopitelne? Normalne sa zamyka, normalne to funguje.

[Eagle]

2THX: Tvoje myšlenkové pochody mě opravdu fascinují.

No, neviem, viz servrove CPU. Su podstatne drahsie - ale iba koli cache.

Už několik let nejsou podstatně dražší.

ale ja ti viem ukazat fx-62, ktory ma rovnaky vykon ako 6600 a stoji este 2.5x viac...

Právě proto si FX-62 nekupujeme, nemyslíš?

Ved aj SC s o 20% vyssim vykonom nestoji o 20 ale o 50% viac...

Tak znovu, už asi po desáté, polopaticky - stojí víc, ale přináší nějaký výkon navíc a nějakou úsporu času. Je na tobě, zda ta úspora času stojí za dodatečné peníze. Protože mně dual-core oproti single-core prakticky žádný výkon navíc nepřinese, nemůže mi přinést ani úsporu času, proto benefity z něj jsou nulové, a tedy i cenové navýšení musí být nulové. Chápeš to už nebo to budu vysvětlovat ještě 20x ?

a potom zmenis tie tvrdenia ze p4 za danu cenu nema co nabidnout? Ved potom bude lacnejsi ako rovnako vykonny A64...
Budes prepisovat vsetky tie prispevky?

Máš problémy s čísly nebo v čem je problém? P4 za současnou cenu nemá co nabídnout, protože je při stejném výkonu jako A64 podstatně dražší. Ten procesor je za aktuální cenu nevýhodný. Až zlevní, tak třeba výhodný bude. Na mých příspěvcích se tím nic nemění.

tak za 1., vykon DC v ST aplikaci 1.1-1.3x v zavislosti co vsetko mi bezi na pozadi (winamp, TS, dc++, driver zvukovky atd.)

WinAMP = vytížení téměř nula
P2P klient = nevím jak DC++, ale mnohem pokročilejší eMule zatěžuje zcela minimálně
zvukovka = to ti určitě ušetří hodně moc, když aplikace obvykle moc nezvučí a ve hrách je limitem grafická karta

Takže těch tvých 1.3x je leda tak utopie. Ještě bych tak byl ochoten připustit 1.1x, i když i to je velmi nadsazené.

za 2., cena DC 1.2y, 1.3y

A to jsi sebral kde? Víš, co to je etalon?

resp. v istych kategoriach vykonu obdobne SC nie je

Tyhle kategorie mě nezajímají, protože mají ubohý poměr price/performance. Opravdu si nebudu kupovat E6600 za 9 litrů, když má jen o necelých 30 % vyšší frekvenci než E6300, přičemž stojí o 70 % víc (o srovnání s A64 nemluvě).

Ty si nasiel jeden priklad kedy je cena 2x vyssia, ja som ti nasiel dva protipriklady kedy nie je - ale odmietas to uznat.

Protože jsou to nesmysly. Mixuješ do porovnání nevýhodné procesory.

Poradim ti, pretaktuj...

Super. Takže když se mě někdo bude ptát, jestli má upgradovat svůj tři roky starý počítat, tak mu můžu s klidem říct, že bez přetaktování žádné velké zvýšení výkonu čekat nemá? To je teda vývoj! Radši bych mu poradil, aby jel s přítelkyní na dovolenou, protože když výrobci CPU neposkytují efekty navíc, tak taky nemají dostat prachy.

Myslim ze pre-computation by dost zvysila spotrebu.

To jistě... ale přineslo by to víc výkonu než ten slavný dual-core. Takže určitě bych radši bral single-core se speculative precomputation než dual-core bez něj.

tak mi prosim popis, v com presne spociva rozdiel pri pocitani fyziky seriovo a paralelne, v com sa meni algoritmus ratania kolizii a preco to sposobi tak velky problem, ak sa budu robit vypocty paralelne...

Dobrá:
1) sériově - Panák č. 1 se pohybuje, nic tam není, OK, přesunul se na novou pozici. Panák č. 2 se pohybuje, naráží na panáka č.1, vzniká kolize, je nutné jí řešit.
2) paralelně - Panák č. 1 se pohybuje, nic tam není, přesunuje se na novou pozici. Panák č. 2 se pohybuje, nic tam není (panák č. 1 ještě nedorazil), přesunuje se na novou pozici. V dalším kole se zjišťuje, že panák č. 1 se srazil s panákem č. 2, už dávno pronikli do sebe, kolize nebyla vyřešena, došlo k chybě v programu (panáci jsou v sobě, přičemž to tak být nikdy nemá, nemůžou do sebe difúzovat).

5% nepovazujem za hodne

To už jsem tady taky probíral, zase nečteš nebo se nesnažíš pochopit. Tak tedy znovu (už poněkolikáté).

1) To, že mají panáci ve scéně pravděpodobnost srážky s jiným panákem 5 %, neznamená, že 95 panáků je v pohodě a 5 panáků je potřeba řešit.
2) Pokud nepoužiješ sekvenční průchod, vystavuješ se problémům, které jsem popsal výše. Hrál jsi někdy turn-based hru v režimu simultárních pohybů? Víš, jaké problémy tam vznikají? Tak přesně to tě čeká, když to budeš dělat paralelně.

ano a hned dalsia veta popisuje riesenie

Ta věta nepopisuje řešení závislostí, ona jen říká, že závislosti existují jen v omezeném počtu případů, což není pravda.

NIEEE, proste sa pouzije r/w lock, ziadne stare data, ziadne prasarny.

R/W lock ti nevyřeší závislosti.

Tom examined the threads' activity with profiling tools, and it turned out that 95 percent of the time the threads were reading memory while only spending 5 percent of their time writing. A read/write lock allowed many threads to read the same bit of memory, but only one thread to write to it.

Víš, co tahle věta znamená? Že thready 95 % času zpracovávají instrukce a k tomu si čtou data, přičemž jen 5 % času zapisují výsledky do sdílené paměti. To neříká nic o tom, jak jsou vyřešeny závislosti, kdy thread 1 musí zpracovávat data, které mu musí dodat thread 0. Jistě, pokud se to bude dělat paralelně se zastaralými daty, problémy se objeví jen v malém počtu případů. Ale právě kvůli tomu, že se ty problémy projeví (panáci do sebe difúzují), je to prasárna, která by se ti při single-threaded verzi nestala.

[THX]

Už několik let nejsou podstatně dražší.

tak napr.
Xeon MP 7140M 3.4 GHz 2x 1MB+16 MB $1980 vs $200 PD 945 2x2
Xeon MP 7130M 3.2 GHz 2x 1MB+8 MB $1391 vs $190 PD 940 2x2
Xeon MP 7120M 3 GHz 2x 1MB+4 MB $1117 vs $160 za P-D 930 3ghz 2x2MB

Ta cache navyse v servrovej verzii mi pride dost draha.

Tak znovu, už asi po desáté, polopaticky - stojí víc, ale přináší nějaký výkon navíc a nějakou úsporu času. Je na tobě, zda ta úspora času stojí za dodatečné peníze. Protože mně dual-core oproti single-core prakticky žádný výkon navíc nepřinese, nemůže mi přinést ani úsporu času, proto benefity z něj jsou nulové, a tedy i cenové navýšení musí být nulové. Chápeš to už nebo to budu vysvětlovat ještě 20x ?

uznavam, a uz davno som uznal, ze ak ten procesor nevyuzijes, tak nema zmysel ho kupovat, nemusis to opakovat 20x - co ale neznamena, ze ho niekto iny dokaze dost dobre vyuzit - o to tu ide.

Máš problémy s čísly nebo v čem je problém? P4 za současnou cenu nemá co nabídnout, protože je při stejném výkonu jako A64 podstatně dražší. Ten procesor je za aktuální cenu nevýhodný. Až zlevní, tak třeba výhodný bude. Na mých příspěvcích se tím nic nemění.

az zlevni, tak soucasna cena bude v tej dobe uplne ina...
Ja sa ti tu nesnazim vyvratit, ze prave teraz (30.12) je athlon64 lacnejsi, ja len oponujem tvrdeniu "DC je 2x drahsie" tym, ze som ti nasiel dva protipriklady, kedy toto tvoje tvrdenie neplati.

WinAMP = vytížení téměř nula
P2P klient = nevím jak DC++, ale mnohem pokročilejší eMule zatěžuje zcela minimálně
zvukovka = to ti určitě ušetří hodně moc, když aplikace obvykle moc nezvučí a ve hrách je limitem grafická karta

Takže těch tvých 1.3x je leda tak utopie. Ještě bych tak byl ochoten připustit 1.1x, i když i to je velmi nadsazené.

Lenze ta hra celkom vytazi zvukovku (v 3d rezime) a ta procak, este k tomu pridaj 4 kanaly od winampu v 2d rezime a sem tam do toho nejaky ten teamspeak (=dalsi kanal). To sa ti pravdepodobne nebude v task managerovi ukazovat ako cas spotrebovany aplikaciou, ale ako kernel-time (spotrebovany prepoctami drivera v kernel rezime). Rovnako u DCcka akakolvek praca s diskom = kernel time (niektore menej inteligentne DC zapisuju okamzite kazdy jeden kusocek suboru). Este ti toho na pozadi moze kludne bezat viac (mne napr. FTP). A pridaj si k tomu, ze driver grafiky bude tiez vyuzivat to druhe jadro. No a este si zober take veci ako prerusenia, schleduler, dalsie kernelovske veci.

A to jsi sebral kde? Víš, co to je etalon?

to som zobral z pentia-d. Napisal si DC, tak DC - to je aj pentium-D. Ak si chcel, mal si napisat - u athlona64 ktory je podla mna etalonom, je cena DC procesora rovnakej frekvencie a dvojnasobnej celkovej cache 2x vacsia (co uz tiez neplati, napr. 3200+ vs x2 3800+ je uz len o 66% drahsi). Napisal si "DC je 2x drahsie". Ja som zobral ceny DC procesorov.
Odmietam sa dalej bavit o cenach, to tu potom mozeme kazdy mesiac updatnut ceny procakov a viest zase diskusiu ci teraz uz sa to oplati, alebo este nie.

Tyhle kategorie mě nezajímají, protože mají ubohý poměr price/performance. Opravdu si nebudu kupovat E6600 za 9 litrů, když má jen o necelých 30 % vyšší frekvenci než E6300, přičemž stojí o 70 % víc (o srovnání s A64 nemluvě).

a nemyslis, ze tento thread je az prilis o tebe? A mna zase praveze zaujimaju.

Protože jsou to nesmysly. Mixuješ do porovnání nevýhodné procesory.

ja by som skor povedal, ze ty si si nasiel taku kombinaciu SC a DC procesorov, ktore porovnavas, aby to vyslo co najhorsie v neprospech DC. Teda nevyhodne ako pre koho... (ano, pre tvoje porovnania kde chces ukazat ze to stoji 2x viac je to fakt nevyhodne).

Super. Takže když se mě někdo bude ptát, jestli má upgradovat svůj tři roky starý počítat, tak mu můžu s klidem říct, že bez přetaktování žádné velké zvýšení výkonu čekat nemá? To je teda vývoj! Radši bych mu poradil, aby jel s přítelkyní na dovolenou, protože když výrobci CPU neposkytují efekty navíc, tak taky nemají dostat prachy.

To teda je vyvoj. Sam vies ze sc vykon hore velmi nepojde. A tak mu povedz pravdu, ze bez OC to predsa nie je ono - a teda nech ide radsej na tu dovolenku, ak nechce taktovat...

To jistě... ale přineslo by to víc výkonu než ten slavný dual-core.

pre koho ako..., myslim ze s istotou to tvrdit nemozes

Dobrá:
1) sériově - Panák č. 1 se pohybuje, nic tam není, OK, přesunul se na novou pozici. Panák č. 2 se pohybuje, naráží na panáka č.1, vzniká kolize, je nutné jí řešit.
2) paralelně - Panák č. 1 se pohybuje, nic tam není, přesunuje se na novou pozici. Panák č. 2 se pohybuje, nic tam není (panák č. 1 ještě nedorazil), přesunuje se na novou pozici. V dalším kole se zjišťuje, že panák č. 1 se srazil s panákem č. 2, už dávno pronikli do sebe, kolize nebyla vyřešena, došlo k chybě v programu (panáci jsou v sobě, přičemž to tak být nikdy nemá, nemůžou do sebe difúzovat).

Popisal si ako by to fungovalo bez zamkov, ale 2.) panak c1 sa pohybuje, nic tam nie je - zamkne si tu poziciu kam sa ma pohnut, panak c2 ked sa tam chce pohnut zisti, ze uz tam niekto je - kolize a jej riesenie.

To už jsem tady taky probíral, zase nečteš nebo se nesnažíš pochopit. Tak tedy znovu (už poněkolikáté).

1) To, že mají panáci ve scéně pravděpodobnost srážky s jiným panákem 5 %, neznamená, že 95 panáků je v pohodě a 5 panáků je potřeba řešit.
2) Pokud nepoužiješ sekvenční průchod, vystavuješ se problémům, které jsem popsal výše. Hrál jsi někdy turn-based hru v režimu simultárních pohybů? Víš, jaké problémy tam vznikají? Tak přesně to tě čeká, když to budeš dělat paralelně.

1.) Kde tvrdim, ze to tak je? Nikde sa tam navyse nepise, ze pravdepodobnost kolizie je 5%
2.) riesenie som ti popisal vyssie....

Ta věta nepopisuje řešení závislostí, ona jen říká, že závislosti existují jen v omezeném počtu případů, což není pravda.

No tak toto je dobre . Ty proste tvrdis, ze ta veta je nepravdiva. Programatori z valve si to zmerali a vyslo im tolko a tolko a ty si sa proste rozhodol, ze skratka nie a ze to nie je pravda. No tazko sa potom s tebou diskutuje. (btw. ta veta nehovori nic o zavislostiach).

R/W lock ti nevyřeší závislosti.

Víš, co tahle věta znamená? Že thready 95 % času zpracovávají instrukce a k tomu si čtou data, přičemž jen 5 % času zapisují výsledky do sdílené paměti. To neříká nic o tom, jak jsou vyřešeny závislosti, kdy thread 1 musí zpracovávat data, které mu musí dodat thread 0. Jistě, pokud se to bude dělat paralelně se zastaralými daty, problémy se objeví jen v malém počtu případů. Ale právě kvůli tomu, že se ty problémy projeví (panáci do sebe difúzují), je to prasárna, která by se ti při single-threaded verzi nestala.

Lenze - ak su tie data zavisle - tak nemozno paralelizovat. Nikde tam nemas napisane ze to nejak osalili alebo co. Dokonca tam nikde nemas napisane nic o zavislosti dat. Iba, ze zistili ze po rozlozeni do threadov sa tieto blokuju iba v malo pripadoch - a tak je vykonnostny prinos paralelizacie velky.
A btw. panaci ti do seba a stien difuzuju aj teraz, pretoze fyzikalny model panaka je omnoho jednoduchsi ako renrerovany.
Mas este nejake argumenty na podporu svojej "teorie prasenia" ?

Pripada mi to, ze dost casto odchadzas od veci a az na cenu (ktora sa neustale meni) ti dosli takmer vsetky argumenty v neprospech DC.

[Petrik]

Ty si vazne, ale skutecne vazne myslis, ze valve vypusti herni engine, ktery bude v 5% kolizi produkovat chybne vysledky? Tys asi nidky v zivote nevidel nic od valve, ze? Navic si myslim, ze problem s tema zamkama je v tom textu vysvetlen celkem srozumitelne.

Ted k tem kolizim panaku:
1)pri te seriove operaci to vypada tak, ze panak cislo jedna se nekam presune...pak jdes na druheho panaka a zjistis, ze jeho pohyb koliduje s pohybem prvniho a musis uz vypocitany pohyb panaka 1 opravit a tu kolizi nejak vyresit.
2)pri paralelni operaci to je hodne podobne, az na to, ze muzes mnohem drive zjistis, ze nastala kolize. Napriklad neni problem uz behem pocitani pohybu panaka nekam hazet jeho aktualni polohu a porovnavat ji (opet paralelne) s polohou ostatnich panaku. Jakmile zjistis, ze nastava kolize, muzes ji zacit resit okamzite a nemusis zahazovat uz vypocitany pohyb prvniho panaka.

Pripada ti to uz dostatecne fundovane? Ja myslim, ze to je celkem elegantni reseni, nemyslis? Netvrdim, ze to je nejlepsi reseni, vymyslel jsem ho ted behem psani, takze verim, ze kdyz na to ma cely team spoustu casu, ze to dokaze vyresit jeste mnohem lepe...

Víš, co tahle věta znamená? Že thready 95 % času zpracovávají instrukce a k tomu si čtou data, přičemž jen 5 % času zapisují výsledky do sdílené paměti. To neříká nic o tom, jak jsou vyřešeny závislosti, kdy thread 1 musí zpracovávat data, které mu musí dodat thread 0. Jistě, pokud se to bude dělat paralelně se zastaralými daty, problémy se objeví jen v malém počtu případů. Ale právě kvůli tomu, že se ty problémy projeví (panáci do sebe difúzují), je to prasárna, která by se ti při single-threaded verzi nestala.

Eagle, ze ty ses zase nekouknul na nazev tohoto fora... samozrejmne ze nas tu zajima predevsim vykon po pretaktovani.

Dokazovat výhodnost procesoru pomocí přetaktování mi přijde lehce zvrácené. Důležité je porovnání na default, protože podle něj se odvíjí prodejní ceny. A bohužel C2D je předražené a to hodně.

[Eagle]

Ted k tem kolizim panaku:
1)pri te seriove operaci to vypada tak, ze panak cislo jedna se nekam presune...pak jdes na druheho panaka a zjistis, ze jeho pohyb koliduje s pohybem prvniho a musis uz vypocitany pohyb panaka 1 opravit a tu kolizi nejak vyresit.
2)pri paralelni operaci to je hodne podobne, az na to, ze muzes mnohem drive zjistis, ze nastala kolize. Napriklad neni problem uz behem pocitani pohybu panaka nekam hazet jeho aktualni polohu a porovnavat ji (opet paralelne) s polohou ostatnich panaku. Jakmile zjistis, ze nastava kolize, muzes ji zacit resit okamzite a nemusis zahazovat uz vypocitany pohyb prvniho panaka.

Pripada ti to uz dostatecne fundovane? Ja myslim, ze to je celkem elegantni reseni, nemyslis?

Myslím, že to je hloupost, protože ty musíš počítat pohyby snímek od snímku, jinak totiž nebudeš mít žádnou interaktivitu s jednáním uživatele. A nemůžeš někam ukládat aktuální polohu, protože ta je jen jedna. Výpočet neudělá nic jiného, než že vezme aktuální polohu, spočítá pár výpočtů fyziky a vyplivne polohu v dalším snímku. Pokud se v průběhu výpočtu změní vstupní parametry výpočtu, máš problém.

jinak ad1) To by se samozřejmě vyřešilo tak, že panák č. 2 by se zastavil a panák č. 1 by byl na své původní pozici.

[swarm]

1)pri te seriove operaci to vypada tak, ze panak cislo jedna se nekam presune...pak jdes na druheho panaka a zjistis, ze jeho pohyb koliduje s pohybem prvniho a musis uz vypocitany pohyb panaka 1 opravit a tu kolizi nejak vyresit.

Proč bys měl řešit pozici panáka 1? Vždyť tam bylo místo, tak neni důvod tam toho panáka nenechat. Vsériové fyzice to funguje takhle; dejme tomu, ze máme dva panáky a ty jdou proti sobě až se srazí
- U prvního panáka se zjistí, jestli je před ním místo; je tam, takže se tam posune
- U druhého panáka se zjistí, jestli je před ním místo; ne, není - stojí tam první panák, takže druhý panák zůstane stát
- U prvního panáka se zjistí, jestli je před ním místo; ne, není - stojí tam druhý panák.

Co z toho plyne? Vyhrává ten, na kterého došla dřív řada při aktualizaci pozice . Btw teoreticky se to dá ošetřit těma zónama. Pokud je fyzika hodně složitá, tak si před výpočtem jednotlivých panáků udělám kolem nich nějaké pomocné neviditelné boxy (velikostí úměrné rychlosti pohybu) nebo koule (neni nic jednoduššího než počítat vzdálenost dvou bodů) a kontroluju, které boxy se s kterýma prolínaj. Vyjde mi, že třeba scénu s 5ti panáky v jednom bytě můžu rozložit na tři zóny. Můžu si tak paralelně vytvořit 3 klasické sériové výpočty.
Dejme tomu, že pak zabere výpočet teoreticky na dovu jadrech 3/5 času, na tříjádru 2/5 (a na všech vyšších už zase jen 2/5).

Taky jde určitě vymyslet lepší řešení...

[Petrik]

Vsechno, co jsem napsal, jsem myslel v ramci jednoho framu. Aktualni polohou jsem myslel polohu, kterou prave vypocitavam a ktera jeste neni konecna = nebude se renderovat. Prave ze se v prubehu nic nemeni, jelikoz neustale sleduji, zda nenastala kolize, coz pri seriovem vypoctu jaksi nelze. Proto me pripada paralelni pocitani fyziky tak nejak spravnejsi nez seriove...asi proto, ze v realu fyzika je seriova, tedy veci se hybaji soucasne, ne seriove...neni u serioveho pocitani fyziky nahodou mnohem vice problemu s tim, ze neco se hyblo drive nez neco jineho a musi se zpetne zjistovat, zda to je vporadku a pripadne to cele pocitat znovu? Me proste prijde neprirozene nativne paralelni vec pocitat seriove...
Tedy pockat...nemyslel jsi to nahodu tak, ze nepocitas trajektorii, ale pouze vyslednou polohu? To by pak mohli vznikat hrozne chyby, jsi si toho doufam vedom...

Myslím, že to je hloupost, protože ty musíš počítat pohyby snímek od snímku, jinak totiž nebudeš mít žádnou interaktivitu s jednáním uživatele. A nemůžeš někam ukládat aktuální polohu, protože ta je jen jedna. Výpočet neudělá nic jiného, než že vezme aktuální polohu, spočítá pár výpočtů fyziky a vyplivne polohu v dalším snímku. Pokud se v průběhu výpočtu změní vstupní parametry výpočtu, máš problém.

jinak ad1) To by se samozřejmě vyřešilo tak, že panák č. 2 by se zastavil a panák č. 1 by byl na své původní pozici.

Coze? Budto jsem tvuj post vubec nepochopil, nebo jsi to napsal spatne, nebo teda fakt nevim.
Ad prvni dve vety: ano, misto tam BYLO, protoze jsi jeste nespocital pohyb druheho panaka. Po jeho spocitani zjistis, ze tam misto neni, ze doslo ke kolizi, kteoru musis nejak resit. Pri paralelnim reseni, ktere jsem navrhnul ja, zjistis kolizi ihned a muzes ji zacit ihned resit. Ale je mozne, ze se pohyb a fyzika dela ve hrach uplne jinak a ze mnou nastineny zpusob paralelniho reseni pouzit nelze...

Proč bys měl řešit pozici panáka 1? Vždyť tam bylo místo, tak neni důvod tam toho panáka nenechat. Vsériové fyzice to funguje takhle; dejme tomu, ze máme dva panáky a ty jdou proti sobě až se srazí
- U prvního panáka se zjistí, jestli je před ním místo; je tam, takže se tam posune
- U druhého panáka se zjistí, jestli je před ním místo; ne, není - stojí tam první panák, takže druhý panák zůstane stát
- U prvního panáka se zjistí, jestli je před ním místo; ne, není - stojí tam druhý panák.

Co z toho plyne? Vyhrává ten, na kterého došla dřív řada při aktualizaci pozice . Btw teoreticky se to dá ošetřit těma zónama. Pokud je fyzika hodně složitá, tak si před výpočtem jednotlivých panáků udělám kolem nich nějaké pomocné neviditelné boxy (velikostí úměrné rychlosti pohybu) nebo koule (neni nic jednoduššího než počítat vzdálenost dvou bodů) a kontroluju, které boxy se s kterýma prolínaj. Vyjde mi, že třeba scénu s 5ti panáky v jednom bytě můžu rozložit na tři zóny. Můžu si tak paralelně vytvořit 3 klasické sériové výpočty.
Dejme tomu, že pak zabere výpočet teoreticky na dovu jadrech 3/5 času, na tříjádru 2/5 (a na všech vyšších už zase jen 2/5).

Taky jde určitě vymyslet lepší řešení...

[swarm]

No jasne ze to s fyzikou nema nic spolecneho tohle je pouze rendering sceny. To byla reakce na to, jak Eagle tvrdil, ze krome fyziky nema cenu nic jineho paralelizovat. Kdyby to skutecne nemelo cenu, tak by se s tim ve Valve asi nedelali, ze. O tom, jakym zpusobem je delana fyzika jsem nikde nic nenasel, ale predpokladam, ze u ni aplikovali fine grained therading, predevsim asi proto, ze u pokrocilych fyzikalnich enginu jako je treba havok, by to nemel byt problem. A jsem rad, ze tu alespon nekdo z odborniku potvrdil, ze to, co jim uz realne funguje, je skutecne mozne udelat, coz Eagle porad odmita prijmout jako fakt.

Popravdě ohledně toho vykreslování to neni problém ani ohledně implementace. Předpokládám v podstatě, že každý engine, co se začne v tuhle chvíli vyvíjet, to tak nějak bude dělat. Nestojí to nějak moc času navíc a neni v tom riziko větší nestability programu. Otázka je, kolik výkonu navíc to přinese. Já jsem přesvědčen, že v dohledné době to až zas tak moc nebude. Samozřejmě se ale nemůžeme bavít o výkonu této konkrétní "smyčky", kde to samozřejmě bude znát, ale spíš jde o to, jak se to projeví na celkové rychlosti hry, kde jsem přesvědčen, že se to ještě pár let moc neprojeví. Stěžejní tak zůstává fyzika.
V podstatě to rozdělení grafickýho enginu na víc CPU nějak moc nemění tu základní filozofii, takže by se dalo říct, že program děláme jako ST, ale pouze jednotlivé kroky se snažíme urychlit MT. Celkově však program pořád zůstává vyvíjen jako ST na té hlavní vrstvě. Pokud si přidáme další krok na začátek a to spočítat fyziku, tak i ta se dá tímto způsobem celkem jednoduše urychlit bez nějakých komplikací. Dalo by se rozdělit na určité fyzikální zóny a ty by se daly zpracovávat samostatně. Otázka je, kolik by to pak reálně přineslo nějakého urychlení (rozhodně to však nezabere moc času na implementaci). Pokud by ve hře třeba na silnici padala lavina kamenů, tak tam jelikož se navzájem všechny šutry ovlivňují, tak by se to počítalo v jednom threadu a nárust výkonu by nebyl žádný, ale v případě, že by padaly dvě laviny za sebou, tak se obě mohou počítat už samostatně, protože je každá v jiné "zóně" a pak by bylo urychlení samozřejmě velké (v celkové hře by se to ale projevilo jen pokud by byla fyzika výpočtově hodně náročná). Samozřejmě pokud pak budu mít scénu, kde se děje několik na sobě nezávislých fyzikálních výpočtů (listí padající ze stromu do jezírka, vodopád, nějaký kravinky s počasím jako mraky, prohybající se trává pod nohama postavičky,...), tak by se všechny daly rozdělit do samostatných zón.

Netušim, jak se to dělá dneska (do příštích enginů), ale kdybych se já snažil tohle řešit, aby mě to stálo co nejmíň námahy, tak jdu na to asi takhle, protože postupy jsou v podstatě stejné, jako když se dělá single-thread aplikace. Samozřejmě někde ten nárust může být velký, někde malý, to už záleží vážně na konkrétní hře. Btw abych se přiznal, tak kdykoli jsem spolupracoval na nějakém komerčním nebo free (herním) projektu, tak tohle řešili vždycky jiní lidé, ale něco už jsem za ty roky taky pochytil (btw zajímavost je, že v tom free vývoji většinou ti programátoři jsou těm novým postupům víc nakloněni, ale je to dáno asi tim, že to dělají pro své vlastní potěšení a tak nemusí řešit, jestli se ten čas navíc vyplatí).