Vyznam dual core

[Eagle]

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

Rychlé = rychlejší než člověk. Do té doby je to pomalé.

No prave vdaka tej priorite operatorov mozes matematicke vypocty dobre paralelizovat. A dokonca aj jedno samotne nasobenie ide velmi dobre paralelizovat.

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.

Vsetko to, co dokaze reorder instrukcii v out-of-order cpu, dokaze rovnako kompiler.

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.

skratka vo svete, kde robis programy pre procesor (A nie procesor pre uz existujuce programy) resp. ich mozes prekompilovat, si mozes dovolit presunut istu logiku z procesora do kompilatora...

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

beton mozes praveze velmi dobre robit paralelne, to by si neveril, ale do miesacky pocas miesania mozes naraz sypat cement, piesok, strk a aj vodu a este sa to vsetko aj paralelne miesa....

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

ale ved predsa tu stale opakujes ako najpouzivanejsie kodeky nejdu paralelizovat....

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

Pomaly disk - riesenie - hybridne disky.

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

Teraz mi povedz, kolko ludi enkoduje do mp3 v lame? Ved to cd/zvuk ti staci enkodovat len raz. Vacsinou si aj tak stiahnes uz enkodovane mp3, nez aby si to sam komprimoval.

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

to su tebou pouzivane programy a ja tvrdim, ze to nie je to, co pouziva vacsina pouzivatelov a z tohtho pohladu ich nemozno brat ako agrument

Pak je to věc názoru. Já si docela všímám, co lidi používají.

Winrar je paralelny

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?).

sifrovacie algoritmy mozu napr. rozdelit subor na viacero casti

Pokud máš hash na celý soubor, tak o tom vcelku pochybuju.

(kazdopadne aj bez rozdelenia sifruje priemerny procesor omnoho rychlejsie ako dokaze priemerny disk zapisovat, takze naco nejaka paralelizacia...).

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.

Na starsie programy a hry nepotrebujes vyssi vykon.

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.

Tak nam teda dokaz (ak to uz tvrdis), ze to provest nejde. A k tej prasarne si neviem ako prisiel, to si si proste vymyslel. Ukaz mi kde je v q4 so zapnutym SMP nizsia kvalita oproti verzii bez smp.

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.

no a preto si tiez kupuju tie dc pocitace...

Bohužel je to tak.

ja by som povedal, ze k pocitacom ma dost vela ludi 5.1 repraky, ze dost vela filmov (nie, tie stare nie) ma 5.1 zvuk, takze je to celkom vyuzitelne.

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

Ked som v threade o 90core intel cpu pisal, ze itegracia napr. sietovej karty (a dalsich dsp a pod.) na cpu znizi celkovu spotrebu, tak si mi napisal ze NIE, pretoze ze vraj ta sietovka ma na horsom vyrobnom procese aj tak nizsiu spotrebu.

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

EDIT: pozeram ze v ankete ma moznost "Mam core 2 duo a jsem spokojeny, ale za ty penize to nestalo" stale 0 hlasov, Svaca, este si nehlasoval? alebo sa radsej zdrzis?

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

[THX]

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.

neurcuje jasny sled operacii, vravi len o tom, co musi byt dokoncene skor a co neskor, (a+b)*(c+d) - tu nikde nie je povedane, ci mam najprv scitat a+b, alebo ci c+d
Ak by ti riadky programu urcovaly presny sled, potom by nikdy nebolo nic ako out-of-order vykonavanie instr.

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

nespravne si to pochopil, ja som vobec nehovoril o nejakych jadrach atd. ale iba o tom, ze to iste, co robi reorder jednotka moze rovnako dobre, ak nie lepsie, urobit kompilator a preto nemusi byt non out-of order procesor pomalsi ako ten out of order. Predstav si ze uz mas ten kod dobre preusporiadany, potom reorder jednotky v podstate nerobia nic a tym padom ich nepotrebujes.

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

nemyslim, ze limitom je miesanie, to by sa uz robili kadejake rychlomiesacky atd., v praxi ti obyc. miesacka bohate postaci a povedal by som, ze problem budes mat skor s odvozom betonu a dodavkou surovin... Navyse myslim ze v momente ked tam hodis poslednu lopatu piesku uz nebudes musiet vobec cakat na nejake premiesanie a budes moct hned spotrebovavat co si si pripravil.

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

ale zase ti zrychli vo vacsine pripadov pristupovu dobu a to velmi vyrazne... Rychlost lin. citania je obmedzujucia iba vo velmi malo pripadoch.

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?).

to ze neposkytuje identicke vysledky nevadi, a ano mal bug, aj ine programy maju obcas bugy, a este ake, a su to dokonca single threaded programy...
Ja som rad za kazde zvysenie vykonu... (a zase sme pri cene - uz si omrkol tie bazary? obhajil by si vobec cenu akehokolvek procesora, ak by si nejaky procak dostal zadarmo? ved potom by kazdy iny procak, ktory by nebol zadarmo mal horsi pomer cena/vykon).

Pokud máš hash na celý soubor, tak o tom vcelku pochybuju.

tu ta aj tak brzdi disk, takze ti to je jedno a nemusis urychlovat vypocet toho hashu

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.

aby si mohol desifrovat obsah a scanovat realtime, nemusis cakat na nacitanie celeho suboru, mozes naraz citat, to precitane hned desifrovat a poslat antiviru. Takze limitovat ta bude zase iba rychlost disku. Dokonca ti pobezi antivir paralelne s desifrovanim, pretoze kym antivir spracuvava data, tak ty uz mozes desifrovat dalsie...

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.

no neviem si potom predstavit, ako to mohlo ist na doporucanom p2 500mhz, ked na 2ghz athlone ti to ide tak pomaly...
Skratka, stare hry si zahras minimalne tak dobre, ako by si mohol v dobe ich vydania.

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.

Ty si tiez nebol schopny vyvratit, ze to paralelne udelat jde... Nemusis nevyhnutne pouzit "pipelining", mozes pocitat kazdu jednu cast vykreslenia frame paralelne na viac cpu (viz id soft, epic, valve)

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

integraciou grafiky na procesor dosiahnes vsetky neduhy sposobene koncentraciou vacsieho mnozstva kremika na jednom mieste (teda to, co si vycital DC) - nutnost lepsieho chladenia, pri rovnakej spotrebe nizsie frekvencie atd. Na grafike v 2d rezime nevyuzivas 3d cast, navyse aj ak zoberies do uvahy vistu, tak to zatazenie 3d casti nebude velke (a tiez sa potom vlasne nebude vyuzivat 2d cast...).

Mě by spíš zajímalo, proč se v diskuzi o dual-core vede anketa o C2D.

Mě by spíš zajímalo, proč se v diskuzi o dual-core vede debata o cenach procesorov.

[Eagle]

neurcuje jasny sled operacii, vravi len o tom, co musi byt dokoncene skor a co neskor, (a+b)*(c+d) - tu nikde nie je povedane, ci mam najprv scitat a+b, alebo ci c+d
Ak by ti riadky programu urcovaly presny sled, potom by nikdy nebolo nic ako out-of-order vykonavanie instr.

Tohle je spíš slovíčkaření. Řádky ti určují přesný sled, ale to neznamená, že některé věci se nedají dělat paralelně. Nicméně souvislosti musí být zachovány. To jsem tím chtěl říct.

nespravne si to pochopil, ja som vobec nehovoril o nejakych jadrach atd. ale iba o tom, ze to iste, co robi reorder jednotka moze rovnako dobre, ak nie lepsie, urobit kompilator a preto nemusi byt non out-of order procesor pomalsi ako ten out of order. Predstav si ze uz mas ten kod dobre preusporiadany, potom reorder jednotky v podstate nerobia nic a tym padom ich nepotrebujes.

S tím se dá souhlasit jen částečně. Out-of-order procesor totiž dokáže pozdržet vykonávání instrukcí do doby, než sežene potřebná data. Mezi tím může cpát do jednotek instrukce ze zásobníku. Tyhle datové závislosti na úrovni kódu ošetříš jen těžko.

nemyslim, ze limitom je miesanie, to by sa uz robili kadejake rychlomiesacky atd.

OK, dobře, jiný příklad. Představ si, že položíš novou podlahu z betonu. Za jak dlouho se po ní můžeš projít? No přece až uschne. A je úplně fuk, jestli jí položíš 1 m2 nebo hangár pro 747ku. Ta operace je sériová a nemůžeš dělat nic dalšího, dokud není dokončena.

ale zase ti zrychli vo vacsine pripadov pristupovu dobu a to velmi vyrazne... Rychlost lin. citania je obmedzujucia iba vo velmi malo pripadoch.

Jak jí může zrychlit? Když mám random access, co mi zaručí, že mnou požadovaná data budou ve flashce ?

to ze neposkytuje identicke vysledky nevadi

Mě ano. U WinRARu to možná není kritická vada, ale třeba u videa, když by mělo dojít ke snížení kvality, tak to radši budu enkódovat delší dobu.

a ano mal bug, aj ine programy maju obcas bugy, a este ake, a su to dokonca single threaded programy...

Tohle je jednoduchá statistika - jaká je pravděpodobnost, že multithreaded program bude mít chybu? A jaká je pravděpodobnost, že single-threaded program bude mít chybu. U MT je mnohem vyšší (i několikanásobně).

obhajil by si vobec cenu akehokolvek procesora, ak by si nejaky procak dostal zadarmo? ved potom by kazdy iny procak, ktory by nebol zadarmo mal horsi pomer cena/vykon).

To je pořád dokola. Už jsem tady kolikrát vysvětloval, že čas má taky nějakou cenu. To nechápeš nebo to vysvětluju blbě nebo v čem je problém?

Dual-core mi v mnou používaných aplikacích nepřinese vůbec žádný výkon navíc (aplikace ho prostě nevyužije). Opakuji: Žádný výkon navíc. Proč tedy platit vyšší cenu, když výkon není vyšší a ani mi to neušetří čas? Rychlejší single-core by mi čas ušetřil.

tu ta aj tak brzdi disk, takze ti to je jedno a nemusis urychlovat vypocet toho hashu

Viz níže - pokud chceš, aby to bylo realtime, tak musíš.

aby si mohol desifrovat obsah a scanovat realtime, nemusis cakat na nacitanie celeho suboru

To nejde minimálně z toho důvodu, že antivirus bere soubory jako celek.

Takze limitovat ta bude zase iba rychlost disku.

Nikdy jsem netvrdil, že nebude. Ale výsledná rychlost je součtem (limitované) rychlosti disku a rychlosti dešifrování a antiviru. Kdybych měl dešifrovat rychlostí, kterou disk čte, tak to celé bude trvat dvojnásobek času proti tomu, když bych dešifroval instantně. Proto je ta rychlost důležitá.

Dokonca ti pobezi antivir paralelne s desifrovanim, pretoze kym antivir spracuvava data, tak ty uz mozes desifrovat dalsie...

To je sice krásná představa, tak to ale není. To, jaké další soubory se mají spouštět, vyplývá až z funkčních volání EXE/DLL, které ale už musí právě procesor zpracovávat, a tedy už musí být dešifrované a zkontrolované proti virům.

no neviem si potom predstavit, ako to mohlo ist na doporucanom p2 500mhz, ked na 2ghz athlone ti to ide tak pomaly...
Skratka, stare hry si zahras minimalne tak dobre, ako by si mohol v dobe ich vydania.

Tyhle doporučení byly pro základní funkce. V případě Civ III tedy malá mapa, v případě leteckého simulátoru rozlišení 320x200 atp. Pamatuješ ještě éru 486tek a Pentií? Běžně hry nabízely rozlišení, které ani v době vydání žádný počítač nezvládnul. Např. v manuálu k Descentu se vysloveně píše, že to tam mají pro budoucnost, až budou rychlejší CPU.

mozes pocitat kazdu jednu cast vykreslenia frame paralelne na viac cpu (viz id soft, epic, valve)

O vykreslení se dneska stará grafická karta, takže kde je ten efekt?

integraciou grafiky na procesor dosiahnes vsetky neduhy sposobene koncentraciou vacsieho mnozstva kremika na jednom mieste (teda to, co si vycital DC) - nutnost lepsieho chladenia, pri rovnakej spotrebe nizsie frekvencie

S tou nižší frekvencí je to bohužel pravda a je to ostatně vidět i na Turionu 64 X2, který oproti Turionu 64 šel s frekvencí dolů dost znatelně. Nicméně... spotřeba celého notebooku nestoupne, protože nepřidáváš další transistory (v případě DC ano), pouze je přesouváš z jednoho místa na druhé. A pokud to povede k lepšímu power managementu, tak proč ne, že to bude stát trochu výkonu? Já bych na notebooku stejně ocenil spíš delší výdrž než vyšší výkon.

Pokud se tohle nebude dít na desktopu, kde jde o výkon především (a spotřeba je až druhořadá), tak v tom nevidím problém.

Mě by spíš zajímalo, proč se v diskuzi o dual-core vede debata o cenach procesorov.

Jezdíš v Rols-Royce Phantom? Pokud ne, tak myslíš si, že je adekvátní se v souvislosti s ním bavit o ceně nebo je to jen prkotina, která nestojí za řeč?

[THX]

S tím se dá souhlasit jen částečně. Out-of-order procesor totiž dokáže pozdržet vykonávání instrukcí do doby, než sežene potřebná data. Mezi tím může cpát do jednotek instrukce ze zásobníku. Tyhle datové závislosti na úrovni kódu ošetříš jen těžko.

u takych procesorov ako napr. cell, ktore namiesto cache maju lokalnu RAM a teda kompiler vie presne ako dlho bude trvat nacitanie instrukcii, dat atd. nemusi procesor robit ziadne pozdrziavanie instr., pretoze kompiler presunie danu instrukciu na take miesto v kode, kedy uz bude mat pripravene data...

Jak jí může zrychlit? Když mám random access, co mi zaručí, že mnou požadovaná data budou ve flashce ?

No, pokial sa bavime o spustani suborov, tak ten prefetch co si win pripravuje, by mal byt tam. Tym navyse odstranis rozne pristupy k dll a pod, pretoze v tom prefetchi su prave vsetky tieto kusky programov a suborov, ktore program otvara hned po spusteni. Navyse, programy sa casto vracaju k tomu co naposledy modifikovali/potrebovali, a to by v tej flash cache malo ostavat tiez.

To je pořád dokola. Už jsem tady kolikrát vysvětloval, že čas má taky nějakou cenu. To nechápeš nebo to vysvětluju blbě nebo v čem je problém?

problem je v tom, ze tu stale opakujes, aky je E6300 absolutne zly a blby procesor, iba koli tomu, ze je drahsi ako AMD

Dual-core mi v mnou používaných aplikacích nepřinese vůbec žádný výkon navíc (aplikace ho prostě nevyužije). Opakuji: Žádný výkon navíc. Proč tedy platit vyšší cenu, když výkon není vyšší a ani mi to neušetří čas? Rychlejší single-core by mi čas ušetřil.

Nikto ti nenuti kupovat DC. Dokonca ani nikto netvrdi, ze ti to pomoze v situacii, ked ten procesor nevies vyuzit. Tak nechapem preco to tu stale a znova a znova opakujes, ze tebe to nepomoze, a naopak, mas problemy uznat, ze niekto iny to moze celkom dobre vyuzit. A ked dostanes aj konkretny priklad od cloveka tuna z fora, tak len proste povies, no a co, aj tak to nie su "bezne pouzivane programy". Vsetci ti verime, ze ty to proste nedokazes vyuzit, OK, ale uz to tu pises asi 10-ty krat ako agrument nie k "DC je pre mna nevyuzitelne", ale ako agrument k "DC je nevyuzitelne".

To nejde minimálně z toho důvodu, že antivirus bere soubory jako celek.

To si nemyslim, preco by ich mal brat ako celok? Co brani antiviru spracovavat subor hned po otvoreni?

Ale výsledná rychlost je součtem (limitované) rychlosti disku a rychlosti dešifrování a antiviru. Kdybych měl dešifrovat rychlostí, kterou disk čte, tak to celé bude trvat dvojnásobek času proti tomu, když bych dešifroval instantně. Proto je ta rychlost důležitá.

lenze desifrovat mozes uz pocas citania, akonahle precitas nejaky blok z disku, desifrujes ho. Pocas desifrovania citas dalsi blok z disku. To by si musel mat fakt pomaly procesor a velmi rychly disk, aby ti to desifrovalo pomalsie ako citanie z disku. Dokonca ak ti to desifruje rovnako rychlo ako citanie z disku, tak to mozes robit paralelne bez spomalenia sposobeneho desifrovanim.

To je sice krásná představa, tak to ale není. To, jaké další soubory se mají spouštět, vyplývá až z funkčních volání EXE/DLL, které ale už musí právě procesor zpracovávat, a tedy už musí být dešifrované a zkontrolované proti virům.

no ak chces nacitat dalsi subor, tak sa deje presne to iste znova - nacitanie, dekryptovanie a AV kontrola, nevidim v tom ziaden rozdiel.

Tyhle doporučení byly pro základní funkce. V případě Civ III tedy malá mapa, v případě leteckého simulátoru rozlišení 320x200 atp. Pamatuješ ještě éru 486tek a Pentií? Běžně hry nabízely rozlišení, které ani v době vydání žádný počítač nezvládnul. Např. v manuálu k Descentu se vysloveně píše, že to tam mají pro budoucnost, až budou rychlejší CPU.

pozri, ja by som povedal, ze ta civka pouziva skor nevhodne algoritmy (a preco? sam si to povedal - preco dat viac penazi za vyvoj lepsieho programu, ak staci povedat kupte si lepsi pocitac). A ked mas raz blby algoritmus, tak proste ti to pojde tak ci tak pomaly. Na 4ghz procaku by si necakal 30s, ale iba 15s, co mi aj tak pride vela a pomale na to, aby to bolo prijatelne interaktivne.

O vykreslení se dneska stará grafická karta, takže kde je ten efekt?

ten efekt by mal byt v tom vsetkom, co predchadza vykresleniu kazdeho framu

Jezdíš v Rols-Royce Phantom? Pokud ne, tak myslíš si, že je adekvátní se v souvislosti s ním bavit o ceně nebo je to jen prkotina, která nestojí za řeč?

ak by sme sa bavili, napr. o konstrukcii prevodoviek v roznych autach, a porovnavali by sme aj RR, tak by som sa fakt nebavil o cene, ale o tej konstrukcii
Navyse si myslim, ze kupcov RR cena az tak nezaujima, takze pri RR je neadekvatne sa bavit o cene vobec (jo a tiez to ma velku spotrebu, ale to ta jaksi tiez velmi nezaujima, koli spotrebe a nizkej cene sa to auto nekupuje)

[Fox!MURDER]

ja vam nechci kazit iluzi co se sifer tyce, ale napr. AES256 dava na p4-3G cca 20MB/s ... takze disky jsou mnohem rychlejsi, nez cpu (i v pripade E6600) a pokud by ty data mely bejt jeste navic komprimovany ... zatizis dve jadra jako nic ...

[Eagle]

u takych procesorov ako napr. cell, ktore namiesto cache maju lokalnu RAM a teda kompiler vie presne ako dlho bude trvat nacitanie instrukcii, dat atd.

A náhodné faktory typu DMA transfery do RAM, přístup grafické karty do RAM atp.? Moderní řadiče pamětí určují, jaké bude pořadí vyřízení. Na čas vyřízení se nelze spolehnout. Ostatně kdyby ano, tak jsou benchmarky propustnosti pamětí perfektně stabilní.

No, pokial sa bavime o spustani suborov, tak ten prefetch co si win pripravuje, by mal byt tam. Tym navyse odstranis rozne pristupy k dll a pod, pretoze v tom prefetchi su prave vsetky tieto kusky programov a suborov, ktore program otvara hned po spusteni. Navyse, programy sa casto vracaju k tomu co naposledy modifikovali/potrebovali, a to by v tej flash cache malo ostavat tiez.

Takže souhlasíš s tím, že nezrychlí (resp. že zrychlí jen tehdy, když se povede spekulace).

problem je v tom, ze tu stale opakujes, aky je E6300 absolutne zly a blby procesor, iba koli tomu, ze je drahsi ako AMD

Ano, je nevýhodný.

Nikto ti nenuti kupovat DC. Dokonca ani nikto netvrdi, ze ti to pomoze v situacii, ked ten procesor nevies vyuzit.

Výrobce mě nutí, neboť nabízí procesor s velkou rychlou cache (můj požadavek - mnou používané aplikace (např. Civ III) jsou na tom závislé) jen jako drahý dual-core. Podsouvá lidem blafy, a nutí je tak kupovat něco, co nevyužijí, načež to, co by využili, jim nenabízí.

mas problemy uznat, ze niekto iny to moze celkom dobre vyuzit.

Já s tím problém nemám, to naopak vy máte problém uznat, že věc, která stojí dvojnásobek, nepřináší pro většinu vůbec nic navíc. Je to jako když si někdo koupí drahé auto a druhý mu řekne, že ho to vůbec nedojalo, protože auto by nevyužil.

ale ako agrument k "DC je nevyuzitelne".

DC je využitelné jen u optimalizovaných aplikací, což jsou v současnosti ty určené pro workstationy (tj. primárně pro počítače s více sockety) a sem tam video. Taky se hodí, když musíš mít nutně spuštěných víc zátěžových aplikací současně (což evidentně většina lidí nemusí, neboť by si dávno koupili dvousocket - nekoupili, takže je jasné, že to pro ně němělo takovou cenu, aby do toho investovali pár korun navíc). V ostatních případech je totálně k ničemu.

To si nemyslim, preco by ich mal brat ako celok? Co brani antiviru spracovavat subor hned po otvoreni?

Velká část virů pracuje tak, že se napíchne na funkci Winmain (... která je někde neznámo kde v EXE) a odkážou se na svojí funkci, kterou připíšou na konec souboru. Tedy musíš mít celý soubor, abys našel Winmain a abys mohl analyzovat souvislosti heuristikou.

lenze desifrovat mozes uz pocas citania

Jestli dešifrátor obdrží celý soubor najednou nebo postupně jeho části, je vcelku otázka. A asi to tady nezodpovíme, protože to nevíme. I kdyby to ale byl celek, narazíš na tom, že antivirus to potřebuje jako celek.

pozri, ja by som povedal, ze ta civka pouziva skor nevhodne algoritmy (a preco? sam si to povedal - preco dat viac penazi za vyvoj lepsieho programu, ak staci povedat kupte si lepsi pocitac). A ked mas raz blby algoritmus, tak proste ti to pojde tak ci tak pomaly. Na 4ghz procaku by si necakal 30s, ale iba 15s, co mi aj tak pride vela a pomale na to, aby to bolo prijatelne interaktivne.

To je sice pravda, ale nic to nemění na faktu, že program už je hotový a nikdo ten algoritmus už předělávat nebude. Optimalizace zapnuté jsou (Intel C++ Compiler), ale to moc nepomohlo. Čili zvýšení výkonu je možné jen pomocí rychlejšího CPU.

ten efekt by mal byt v tom vsetkom, co predchadza vykresleniu kazdeho framu

Takže např. v sériové fyzice?

ak by sme sa bavili, napr. o konstrukcii prevodoviek v roznych autach, a porovnavali by sme aj RR, tak by som sa fakt nebavil o cene, ale o tej konstrukcii

Takže třeba převodovka pro F1 má cenu, která tě taky nezajímá? No to je docela zvláštní přístup. A co třeba jídlo? Taky si dáváš pravý maďarský Uherák, když je přece tak dobrý a cena je nezajímavá?

ja vam nechci kazit iluzi co se sifer tyce, ale napr. AES256 dava na p4-3G cca 20MB/s ... takze disky jsou mnohem rychlejsi, nez cpu (i v pripade E6600) a pokud by ty data mely bejt jeste navic komprimovany ... zatizis dve jadra jako nic ...

Pokud máš takovouhle náročnou šifru, tak tím spíš potřebuješ co nejvyšší single-threaded výkon, protože antivirus se souboru může ujmout až v situaci, kdy je dešifrovaný (= čistě sériová operace).

[Fox!MURDER]

Pokud máš takovouhle náročnou šifru, tak tím spíš potřebuješ co nejvyšší single-threaded výkon, protože antivirus se souboru může ujmout až v situaci, kdy je dešifrovaný (= čistě sériová operace).

ale notak, tomu sam neveris ...
enkrypce je jen dalsi vrstva, nezavisla na tom co je nad nebo pod ni a nepracuje se souborem jako celkem ale s datama uvnitr ... takze ano je to seriova operace, ale ne na urovni souboru, ale na urovni jednotlivejch bloku ...
a ano, je sice mozny to udelat bez jakejchkoliv bufferu a plne to serializovat ... ale to by delal jen blazen ... a eagle ...

[Eagle]

ale notak, tomu sam neveris ...
enkrypce je jen dalsi vrstva, nezavisla na tom co je nad nebo pod ni a nepracuje se souborem jako celkem ale s datama uvnitr ... takze ano je to seriova operace, ale ne na urovni souboru, ale na urovni jednotlivejch bloku ...
a ano, je sice mozny to udelat bez jakejchkoliv bufferu a plne to serializovat ... ale to by delal jen blazen ... a eagle ...

Takže když někdo získá jen desetinu kódovaného souboru, může jí dešifrovat? Např. někdo by někoho odposlouchával přes TCP/IP, zachytil desetinu packetů žádaného souboru a mohl je dešifrovat? To by asi nebylo moc bezpečné, nemyslíš?

[THX]

A náhodné faktory typu DMA transfery do RAM, přístup grafické karty do RAM atp.? Moderní řadiče pamětí určují, jaké bude pořadí vyřízení. Na čas vyřízení se nelze spolehnout. Ostatně kdyby ano, tak jsou benchmarky propustnosti pamětí perfektně stabilní.

to je pravda, ale v praxi a beznom pouziti (resp. to vidno na odchylkach tych benchov) sa to lisi iba o par percent. Pripadne tam ten kompiler moze dat dostatocne rezervy a pripravit tie data uz dlho dopredu. A dalej - zober si ze taky reorder buffer ma nejakych dajme tomu 256 poloziek, kompiler moze preusporaduvat skoro nekonecno, resp. vsetky instrukcie programu - nieco take procak nedokaze. Takto vlastne funguje aj ten intel MT kompiler. Hlada v kode casti, kde by mohol kod spustat paralelne, toto procesor nedokaze, lebo nema na to dostatocne prostriedky.

Takže souhlasíš s tím, že nezrychlí (resp. že zrychlí jen tehdy, když se povede spekulace).

ano, pridam este k tomu, ze ta spekulace sa vo vacsine pripadov fakt povede a ze ten prefetch sa samozrejme casom podla toho ako sa pri spustani aplikacia sprava tomu prisposobuje

Výrobce mě nutí, neboť nabízí procesor s velkou rychlou cache (můj požadavek - mnou používané aplikace (např. Civ III) jsou na tom závislé) jen jako drahý dual-core. Podsouvá lidem blafy, a nutí je tak kupovat něco, co nevyužijí, načež to, co by využili, jim nenabízí.

nie, vyrobce te nenuti. Nic si nemusis kupovat, neboj, nic sa ti nestane. Fakt ta nikto nenuti. Ak by si si aj myslel, ze ano, tak si to asi zle vysvetlujes. Skratka, ak ten procesor nechces, nemusis ho kupit, nic sa nestane.

Já s tím problém nemám, to naopak vy máte problém uznat, že věc, která stojí dvojnásobek, nepřináší pro většinu vůbec nic navíc.

no praveze mas problem uznat uz len to, ze ta vec nestoji vzdy 2x viac.

DC je využitelné jen u optimalizovaných aplikací, což jsou v současnosti ty určené pro workstationy (tj. primárně pro počítače s více sockety) a sem tam video. Taky se hodí, když musíš mít nutně spuštěných víc zátěžových aplikací současně (což evidentně většina lidí nemusí, neboť by si dávno koupili dvousocket - nekoupili, takže je jasné, že to pro ně němělo takovou cenu, aby do toho investovali pár korun navíc). V ostatních případech je totálně k ničemu.

Vdaka DC sa znizila cena dvojjadroveho riesenia tak, ze si ho mozu dovolit aj ludia, ktori by si dual socket dosku za beznych okolnosti nekupili.

Velká část virů pracuje tak, že se napíchne na funkci Winmain (... která je někde neznámo kde v EXE) a odkážou se na svojí funkci, kterou připíšou na konec souboru. Tedy musíš mít celý soubor, abys našel Winmain a abys mohl analyzovat souvislosti heuristikou.

Velka cast antivirov pracuje tak ze scanuje dokonca vsetky subory (aj obrazky atd.) a nielen cely subor exe programu. Ver mi, antiviry scanuju cely exe subor, mozes si to vyskusat sam. Winmain nehladas, ale vies kde je. Tiez si virus nemusi dat svoj kod len na koniec, a tiez nemusi iba namiesto winmain, preto sa musi scanovat cely subor.

Jestli dešifrátor obdrží celý soubor najednou nebo postupně jeho části, je vcelku otázka. A asi to tady nezodpovíme, protože to nevíme. I kdyby to ale byl celek, narazíš na tom, že antivirus to potřebuje jako celek.

vyriesime, je to celkom jednoduche - desifrator obdrzi subor po blokoch, presne tak ako by ho obdrzal program, a program tiez obdrzi subor rovnako, ako keby tam ziadne desifrovanie nebolo. Desifrovanie a sifrovanie je totizto pre programy transparentne.

To je sice pravda, ale nic to nemění na faktu, že program už je hotový a nikdo ten algoritmus už předělávat nebude. Optimalizace zapnuté jsou (Intel C++ Compiler), ale to moc nepomohlo. Čili zvýšení výkonu je možné jen pomocí rychlejšího CPU.

no ale kedze sa single core vykon zvysovat nebude, na dajme tomu 3x rychlejsi procesor sa este fakt nacakas a ani ti to velmi nepomoze, lebo ta hra bude aj tak strasne pomala a neinteraktivna

Takže např. v sériové fyzice?

dal si mi K- za "nectes poradne", ale myslim ze tentokrat si tu nieco prehliadol ty, precitaj si tento prispevok
Jednoznacne sa tam pise, ze ta fyzika je bez problemov paralelizovatelna.

Takže třeba převodovka pro F1 má cenu, která tě taky nezajímá? No to je docela zvláštní přístup. A co třeba jídlo? Taky si dáváš pravý maďarský Uherák, když je přece tak dobrý a cena je nezajímavá?

V diskusii o roznych konstrukciach prevodoviek, by som sa bavil aj o konstrukcii prevodovky pre f1, aj pre traktor, aj ked maju oba uplne inu cenu a urcenie, co je ale trocha mimo diskusiu o ich samotnej konstrukcii.

Pokud máš takovouhle náročnou šifru, tak tím spíš potřebuješ co nejvyšší single-threaded výkon, protože antivirus se souboru může ujmout až v situaci, kdy je dešifrovaný (= čistě sériová operace).

ani jedno, ani druhe, jednak vyuzijes viacero jadier (napr. tak ako popisoval fox) a tiez sa ujme antivir suboru akonahle je otvoreny a ihned po precitani a dekodovani prvych blokov.

[jan555]

Nechápu, jak může někdo přijít s tím, že ten procesor je dvakrát dražší? Nové generace procesorů stojí zhruba stejně jako staré a v tomhle případě tomu není jinak, mimoto cenu určuje prakticky výhradně marketing, pokud bude o 2 generace později procesor v téhle třídě obsahovat 8 jader, bude stát stále zhruba stejně (vyjádřeno v prosté číselné hodnotě, díky dalším faktorům bude reálně zřejmě levnější), rozhodně ne 4x víc. A že je dražší než výběhové modely jiného výrobce na jiné platformě? Fakt "zajímavé" srovnání, zkuste ho aplikovat na jiný tržní segment. Spousta lidí nakupuje v second-handech a věřím, že dostávají za své peníze velmi dobrý výkon.

A že někdo řekne, že je lepší auto s tříválcovým motorem než se šestiválcem jen proto, že nemůže/nechce jezdit rychleji, nebo ještě lépe, že nevěří, že ten šestiválec rychleji vůbec pojede? Nu což, nechť spokojeně jezdí tříválcem, jen mu budu kazit dobrý pocit ... To mě jen přivádí k tomu, že je velká sranda, že tohle začal někdo řešit v kontextu C2D a nikoliv AMD X2, u Intelu přišel DC společně s "novou" architekturou a celek znamená významně lepší výkony i provozní vlastnosti než předchůdce, což u AMD neplatí, přitom na X2 v krátké době přešli všichni, kdo mohli ... (a v podobně krátké době by si za ten přechod většina z nich nejradši nafackovala)

Ve volné chvíli se mohou vybraní jedinci zamyslet, proč je po boomu AMD tolik lidí z Intelských DC nadšených, není těžké na to přijít - po dlouhá léta věrní AMDčkáři dostali spolu se změnou procesoru (za funkčně lepší) do ruky jaksi mimochodem i jinou platformu. A je možná tak veřejným tajemstvím (o čemž vřele pochybuji), že funkčně je platforma Intelu kvalitnější a celkově znamená pro uživatele posun. Je to fakt tak složité?

A jen tak mimochodem - on existuje nějaký desktopový SC procesor, který je v single-threadu výkonný jako C2D a je přitom 2x levnější? Nebo ještě lépe - existuje nějaký desktopový SC procesor, který je v single-threadu výkonnější než C2D?

A proč se vlastně na světě nejvíc ze všeho řeší kraviny?

[Eagle]

reorder buffer ma nejakych dajme tomu 256 poloziek, kompiler moze preusporaduvat skoro nekonecno, resp. vsetky instrukcie programu - nieco take procak nedokaze.

Proto se taky říká, že využití jednotek v dnešním CPU je v průměru asi 30%. A můžu to potvrdit, většina aplikací má IPC kolem 1, tedy na úrovni 486ky. Z aplikací, které mají IPC 3 (tj. maximum u mého CPU) znám jen BurnK7 a Prime95 (Burn má víc).

Takto vlastne funguje aj ten intel MT kompiler. Hlada v kode casti, kde by mohol kod spustat paralelne, toto procesor nedokaze, lebo nema na to dostatocne prostriedky.

Auto-paralelizátor je vcelku na prd. Spouští thready pro loopy, což je moc krátké na nějaký speed-gain. Složitost něčeho takového je extrémní.

BTW, ten kompilátor měl obsahovat speculative-precomputation, což by výkonu mohlo pomoct extrémně. Výsledek? Obsahuje prdlajs. Přepínač tam je, ale evidentně to nefunguje.

ano, pridam este k tomu, ze ta spekulace sa vo vacsine pripadov fakt povede a ze ten prefetch sa samozrejme casom podla toho ako sa pri spustani aplikacia sprava tomu prisposobuje

To vysloveně závisí na typu vytížení. Mně by to určitě nepomohlo, mám hodně random access.

nie, vyrobce te nenuti. Nic si nemusis kupovat, neboj, nic sa ti nestane. Fakt ta nikto nenuti. Ak by si si aj myslel, ze ano, tak si to asi zle vysvetlujes. Skratka, ak ten procesor nechces, nemusis ho kupit, nic sa nestane.

Jakou jinou alternativu mám, která splní následující požadavky:
- přijatelná spotřeba (včetně změny PStates)
- cache min. 1 MB, lépe 2+ MB s nízkou latencí
- 64bit
- stabilní platforma

Myslím, že tyhle požadavky nejsou tak extrémní. Bohužel jim vyhoví jen C2D. Všimni si, že ani netrvám na nějakém nárůstu výkonu, protože je mi jasné, že se žádný převratný s novým CPU nekoná. Když za novou platformu vypláznu 20 tisíc (tj. víc, než kolik jsem kdysi dal za tu současnou a to i po zohlednění inflace), kolik procent výkonu navíc dostanu? 20 %? C2D má nízkou frekvenci, v některých aplikacích mi poskytne stejný výkon jako moje XP-M. Jediné, z čeho získám hodně výkonu navíc, bude ta velká rychlá cache. Abych získal i něco na první pohled viditelného, budu muset taktovat.

no praveze mas problem uznat uz len to, ze ta vec nestoji vzdy 2x viac.

Ano, to opravdu mám. Mám to totiž podepřeno testy. A jelikož se jedná o objektivní, nikoli subjektivní věc...

Vdaka DC sa znizila cena dvojjadroveho riesenia tak, ze si ho mozu dovolit aj ludia, ktori by si dual socket dosku za beznych okolnosti nekupili.

... což jinými slovy znamená, že to zas tak moc nepotřebovali. Spousta lidí tady tvrdí, jak si život bez DC už nedokážou představit a že v multitaskingu je to něco úžasného. Pak se tedy ptám - proč si to nekoupili už tehdy, když je to tak úžasné?

no ale kedze sa single core vykon zvysovat nebude, na dajme tomu 3x rychlejsi procesor sa este fakt nacakas a ani ti to velmi nepomoze, lebo ta hra bude aj tak strasne pomala a neinteraktivna

Bohužel se nebude zvyšovat výkon obecně. Ať se ti to líbí nebo ne, velká část dnešních aplikací nejde převést na multithreaded nebo by to stálo moc peněz nebo jsou omezeny jinými faktory (velikost RAM, rychlost RAM, rychlost disku). Multicore pomůže jen ve zlomku aplikací.

Např. tohle napsal vývojář Photoshopu k tomu, proč Photoshop stále nevyužívá multicore tak intenzivně:
"Photoshop has taken advantage of multiple processors since the very early days, but yes, memory bandwidth prevents us (and any memory bandwidth bound application) from taking full advantage of multiple processors / multiple cores except for limited cases (e.g., Radial Blur is still compute bound). Unfortunately, it's not something you or I can do much about. The performance topic would be a good one for after the break. - Scott"

Dodám, že já změřil nárůst výkonu jen +8 %. A víš co? On má pravdu. Když ve Photoshopu pracuješ s velkými obrázky (u malých tě čas většinou moc nepálí, protože to běhá rychle dost), tak na pozadí probíhá rapidní komunikace s RAMkou a cache hit rate je nízký. Přesně ten samý problém mám i u Civ III (hit rate je jen 40 %). U multitaskingu, antivirů a podobných věcí jsi zase omezen kapacitou RAM a rychlostí disku. Proč měl A64 ve hrách oproti AXP takový nárůst výkonu, přestože jádro CPU je prakticky stejné? Díky integrovanému paměťovému řadiči. Proč má nyní C2D ještě větší rychlost? Protože má velkou rychlou cache. Výkon dneska nestojí na paralelizaci, protože už i na instrukční úrovni je to u majority programů hodně slabé (IPC 1, někdy dokonce i menší), ale naopak na frekvenci a rychlosti komunikace s RAM.

dal si mi K- za "nectes poradne", ale myslim ze tentokrat si tu nieco prehliadol ty, precitaj si tento prispevok
Jednoznacne sa tam pise, ze ta fyzika je bez problemov paralelizovatelna.

Už se to tady řešilo a dospěli jsme k závěru, že udělat kolizní proces paralelně je dost obtížné.