2THX: Tvoje myšlenkové pochody mě opravdu fascinují.
Už několik let nejsou podstatně dražší.
Právě proto si FX-62 nekupujeme, nemyslíš?
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 ?
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í.
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é.
A to jsi sebral kde? Víš, co to je etalon?
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ě).
Protože jsou to nesmysly. Mixuješ do porovnání nevýhodné procesory.
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 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.
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).
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ě.
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.
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.