Re: Vyznam dual core
Rychlé = rychlejší než člověk. Do té doby je to pomalé.Původně odeslal tomase
ano rozdiel to je, ale verim tomu, ze ked to za tych 10sekund zvladne, stale sa najdu taki co sa budu rozculovat nad tym, ze pre nich je to prilis dlho
Priorita operátorů určuje jasný sled operací. Stejně tak řádky v programu určují jasný sled. Dělat v matice víc věcí vedle sebe jde jen někdy, stejně tak v tom programu.
To čistě jen teoreticky. V praxi v žádném případě. Důvod je ten, že out-of-order má latenci mezi jednotlivými paralelními částmi prakticky nula, zatímco latence mezi více jádry je značná a vždycky bude značná (už z důvodu fyzické vzdálenosti transistorů).
Když budu mít příklad
a = 1 + 5
b = 4 - 2
c = a / b
Tak v out-of-order to zabere dva cykly. V multicore bude výpočet trvat taky dva cykly, ale další minimálně desítky bude trvat, než přemístíš data.
1) V PC nelze přizpůsobovat programy procesoru - to je daň za modularitu.
2) To, co říkáš, je možné jen na úrovni fyzicky blízkých zařízení, což multicore v žádném případě není. Je to snesitelné u jednotlivých výpočetních jednotek. Touhle cestou jde např. Itanium a tam to má výsledky. Jenže chce to velkou cache (kód je víc komplexní) a nesmí se měnit architektura CPU - proto už je tolik let Itanium 2 v jádru stejné (ani Intel si nedovolí přeuspořádat mu jednotky, protože by to znamenalo nutnost rekompilace programů, tj. dodatečné náklady).
Nepochopil jsi to - tady je limitem to, jak rychle mícháš. Celá tvorba betonu stojí a padá s touhle operací, kterou nemůžeš dělat paralelně. To, že budeš mít deset rukou a naházíš tam cement, písek, štěrk i vodu najednou, ještě neznamená, že nějak zrychlíš proces míchání. A to je právě ta věc - musel bys mít míchačku, která míchá rychleji (teď předpokládám, že ti stačí jedna míchačka betonu, ne že toho chceš celý mix).
Upřímně v GPU se příliš nevyznám. Pokud se ale chovají jako SIMD procesory (což se všude tvrdí), tak tam může být paralelizace v rámci ILP. SIMD v CPU je taky ILP. Problém multicore je v tom, že kdyby se měl kód paralelizovat na jednotlivých instrukcích, jako se to dělá u SIMD, bude procesor celou dobu jen čekat na synchronizaci dat z threadů.
Hybridní disk ti přece nikdy nemůže nahradit rychlou mechaniku. Může leda tak doplnit spekulaci s DRAM bufferem. Čtení ti ale nijak neurychlí.
Pokud budeš uvažovat uživatele, kteří výkon nepotřebují, tak těm bude stačit i ten nejlevnější procesor (nedávno tuším nějaký Celeron za 1300 Kč s DPH). A BTW, jsem to já, kdo těmhle lidem tvrdí, že si musí nutně pořídit dual-core, aby jim ty jejich nenáročné aplikace běhaly dostatečně rychle? "Dual-core: Do More", že? Stejně jako ta sestava z ATčka, kde bylo C2D a k tomu 512MB RAMky a říkali, jak je to na kancl neuvěřitelně rychlý (pro zajímavost - na kancl využiju 1 GB RAM i já, stačí větší soubor v Excelu a už se to veze).
Pak je to věc názoru. Já si docela všímám, co lidi používají.
Je... a neposkytuje identické výsledky. A taky měl v té paralelizaci bug způsobující poškození dat. Také přináší opravdu výrazné zvýšení rychlosti (za tu dodatečnou cenu za dual-core super, že?).
Pokud máš hash na celý soubor, tak o tom vcelku pochybuju.
Jenže to zdržuje. Když mám šifrovaný celý disk (v podnikové sféře v lepších firmách vcelku standard), tak při přístupu k souboru potřebuju:
1) Načíst soubor (to trvá a nelze zrychlit).
2) Dešifrovat obsah.
3) Scanovat realtime antivirem.
4) Spustit kód.
Operace 2, 3 a 4 je možné zrychlit. Jenže se v případě operací 2 a 3 jedná o čistě sériové operace, na něž je dual-core k ničemu. Jakékoli zrychlení je tady vítáno.
Nejlepší hláška tohoto threadu. Takže mi chceš tvrdit, že když v Civilization III trvá s rozlehlou mapou jeden jediný turn počítače 5 minut, když se přepočítávají trasy pohybů (např. postavíš letiště) kolem třiceti vteřin (tj. klik, čekáš 30 sekund, pak další klik, mezi tím nemůžeš nic dělat), když načtení savu trvá asi tak tři minuty, že výkon nepotřebuju? To si asi děláš srandu.
Stejně tak starší gamesy s renderingem prováděným CPU se v případě vysokého rozlišení moc nehýbou.
Nadhodil jsem tady, proč si myslím, že to paralelně udělat nejde. Nikdo z vás mi tuhle domněnku nebyl schopen vyvrátit. Naopak jste jí dokonce uznali. A rozhodně to není čisté, vliv se ztratí až při vysokém fps. Pokud ale počet fps z nějakého důvodu klesne (např. kvůli grafice), začne být vidět, jak se ovládání zpožďuje.
Tak zrovna Quake 4 jeví na dual-core určité neduhy, které se na single-core nestávají. Jedná se o různé formy zasekávání v místech, kde single-core jede OK.
Bohužel je to tak.
Kdyby tady byl velký hlad po 5.1 zvuku v oblasti hudby, tak se to dávno prosadí. Tuším že právě DVD Audio tohle nabízí (společně s 96 kHz). A prosadilo se? Ani se mi nezdá. Hodně profi zvukových zařízení je taky stále jen stereo (např. věhlasné Nautily).
U nevýkonových záležitostí je majoritní leakage, protože dynamická spotřeba se moc nekoná. To je i případ síťové karty (většinu času tráví v idle). Menší transistory obecně mají vyšší leakage, a proto se u síťovky nemusí vyplatit dělat jí na menším procesu. Pokud vím, tak jsem nikde netvrdil, že dělat síťovku novou technologií je nutně špatně, jen jsem říkal, že leakage se může stát významných faktorem hrajícím proti. Pokud to zvládnou i novějším procesem, může to být. Obvykle se i dělají pro velikost transistorů dva výrobní procesy - jeden na low-power a druhý na performance. Ale jak si vede ten low-power ve srovnání se starší generací, netuším.
Grafická karta je využívána vždy, dynamická spotřeba tam hraje větší roli (obraz se prostě kreslí pořád). Čili když menším transistorem snížíš dynamickou spotřebu, pořád se to může vyplatit. Hlavní záměř AMD ale IMHO je v tom, že jim to umožní lépe sladit power management CPU, GPU a řadiče pamětí. Když všechno bude na jednom kusu křemíku, bude si to schopné předávat informace o zatížení, optimalizovat přístupy do RAM atd. U čipsetů a dodatečných řadičů se bohužel nějaký power management moc neděje a asi se nedá čekat, že se k tomu odhodlají, dokud to nebude vysloveně nutné (power management = další logika = vyšší výrobní cena).
Mě by spíš zajímalo, proč se v diskuzi o dual-core vede anketa o C2D. Spíš by se sem hodila anketa typu
"Majorita mnou používaných programů je:
single-threaded
multi-threaded s nárůstem výkonu do 20 %
multi-threaded s nárůstem výkonu od 21 do 59 %
multi-threaded s nárůstem výkonu nad 60 %"
Popřípadě anketa:
"Máte nebo nemáte zkušenosti s programováním a co si myslíte o dostupnosti dobře paralelizovatelných multithreaded programů s vysokým nárůstem výkonu?
Mám zkušenosti, MT programy budou za dlouho
Mám zkušenosti, MT programy budou brzo
Nemám zkušenosti, MT programy budou za dlouho
Nemám zkušenosti, MT programy budou brzo"
U té ankety, co je tady teď, bych se i vcelku vsadil, že většina uživatelů, kteří ho tak chválí, by ho chválila i v situaci, kdy by byl jednojádrový.
