Vyznam dual core

[Fox!MURDER]

nechte ho. eagle bude jeste za ctyricet let poslouchat mp3 a koukat na mpeg1 ...
Aneb ja se drzim hesla 'Nerikej, ze neco nejde, protoze se najde blbec, kterej nevi, ze to nejde, pujde a udela to.'

[Eagle]

nechte ho. eagle bude jeste za ctyricet let poslouchat mp3 a koukat na mpeg1 ...

Víš, o tomhle nerozhodují firmy, ale lidi. A pokud je dnes MP3 nejoblíbenější kompresní formát na hudbu, tak to tak prostě je a málokdo to dokáže změnit. Většina lidí rozdíl mezi MP3 a lossless neslyší, a proto jim MP3 vyhovuje a s největší pravděpodobností i vyhovovat bude. Proč si myslíš, že se neuchytily formáty Super Audio CD a DVD Audio?

Jinak BTW, MPEG4 AVC multithreadově udělat nelze (už to tady opakuju 100x).

Ale co sem pletes mp3? Je to snad jedina cinnost, kterou zvladnou pocitace? To sem zase pletes pouze to co ty delas na pocitaci. Jsou i lide, kteri nemaji pocitac k poslouchani/ripovani mp3!

Většina činností, které lze paralelizovat, nepatří mezi typické desktopové úlohy (vyjma videa). Typická úloha je sekvenční, stejně jako v matematice. A i v matematice se musíš řídit prioritou operátorů, jinak se nikdy nedobereš správnému výsledku. Jistě že se najdou i úlohy, které využijí masivní paralelismus, ale ty jsou z oblasti supercomputingu. V desktopech bude znamenat více jader jediné - pokles výkonu v drtivé většině aplikací.

Plně souhlasím s tím, co tvrdí AMD - že cesta zvyšování výkonu v desktopu vede přes vysokofrekvenční jednojádra doplněná účelovými akcelerátory.

No covece ja jsem videl par videi z PS3 a nevim nevim zda by to postarsi G4 utahla asi mas na mysli vykon pod linuxem, ktery na nej stale jeste neni dostatecne optimalizovany

Stále ještě... haha. A to si jako myslíš, že nějaká optimalizace cosi spraví? Out-of-order single-core procesor bude ve většině desktopových věcí vždycky rychlejší než zastaralý Cell.

Ty proste stale nechapes jednu dost zasadni vec: Pro naprostou vetsinu realnych aplikaci je vykon stavajicich procesoru v pevne desetine carce dostatecny.

Dostatečný? Takže ty vlastně žádný výkon nepotřebuješ, viď? A když je dostatečný, tak proč tady lidi tak básní o Core 2 Duo, který posiluje právě integer výkon?

Naprosta vetsina techto programu resp. algoritmu, ktere bychom tolik potrebovali zrychlit, je IMHO paralelizovatelna, coz vidime realne ve hrach, kde diky masivni paralelizaci uvnitr GPU je mozne renderovat takovou grafiku, o ktere se dnesnim CPU ani nezda.

Ano, grafika u her paralelizovatelná je, ale to je dáno tím, že daná scéna obsahuje stovky tisíc pixelů, které jsou jeden na druhém nezávislé. Je to jako když máš dvacet pytlů s cementem a má je odnést jeden chlap nebo dvacet chlapů. Jenže většina desktopových aplikací (včetně např. věcí, které dnes ve hrách připadají na CPU) je sekvenční - podobně jako když se dělá beton, tak tam je ti taky 20 pytlů s cementem na prd, když potřebuješ naházet do míchačky cement, písek, štěrk a vodu a počkat, až se to pořádně promixuje.

Proto tvrdím, že u desktopu vede cesta přes paralelizaci v GPU a vysokofrekvenční single-core CPU, které zvládne sekvenční úlohy.

V techto oblastech budou mit CPU typu Cell a GPU obecne velmi vysoky vykon.

Jasně, takže když už mám v počítače vysoce výkonným SIMD procesor v podobě GPU, tak si tam ještě budu cpát stejně koncipovaný CPU. Víš, jaký bude výsledek? Pokles výkonu ve většině aplikací! Proto říkám, že CPU má jít cestou vysokého sekvenčního výkonu a GPU ho doplňovat při paralelizaci těch několika málo úloh, které se paralelně dají napsat (např. video).

Jeslti si stale myslis, ze budouci CPU budou jednojadrove topici bestie o frekvenci 10GHz, prosim, ale myslim ze uz sam zacinas chapat, ze takto to nebude...

Jestli si stále myslíš, že budu investovat peníze do něčeho, co mi nezvýší výkon v současných aplikacích (nové si pořizovat nebudu, protože to stojí peníze a ty současné plní úlohu dobře), prosím, ale myslím, že už sám začínáš chápat, že takto to nebude...

Decela me tam pobavila jedna vec. Vis jak porad tvrdis, ze si nedokazes predstavit MT kompilovani nebo ze to snad ani nejde?

Kompilovat multithreadově jde skutečně velmi špatně a pokud si myslíš něco jiného, tak nám nastiň, jak si to představuješ. Něco jiného je kompilace více zdrojáků paralelně (to ale nemá s multithreadingem vůbec nic společného, je to stejné jako u těch pixelů). A jen pro zajímavost - Visual Studio 2005, nejdůležitější vývojový nástroj pro nejrozšířenější počítačovou platformu, neumí spouštět víc instancí kompilátoru najednou.

...jen jsem Eaglovy vysvetloval, proc dosahuji GPU tak uzasnych vysledku a ze na to nejdou podle jeho rady o zvetsovani frekvence....a ze GPU nemusi umet jenom renderovat hry tu nekolikrat zduraznil on sam

Pořád nedokážeš pochopit elementární věci? Je sakra rozdíl mezi tím, jestli máš ujet 10 km co nejrychleji nebo přepravit na vzdálenost 1 km 10 tun písku. Na to první bych asi Tatru 815 nepoužíval. Pokud ty ano, tak se pak nediv, že to jede tak pomalu.

[Fox!MURDER]

Víš, o tomhle nerozhodují firmy, ale lidi. A pokud je dnes MP3 nejoblíbenější kompresní formát na hudbu, tak to tak prostě je a málokdo to dokáže změnit. Většina lidí rozdíl mezi MP3 a lossless neslyší, a proto jim MP3 vyhovuje a s největší pravděpodobností i vyhovovat bude. Proč si myslíš, že se neuchytily formáty Super Audio CD a DVD Audio?

jasne. hlavne do mp3 vpohode dostanes vic jak dva kanaly a pripadne dalsi features. ano lidi rozhodnou a pokud jim jinej format nabidne vic (a nemusi to bejt jen lepsi kvalita, ale trebas mensi vyslednej soubor, bo prave vic kanalu, bo neco jinyho ... ano ocekavam, ze prohlasis, ze presne vis ze v pristich dvoustech letech bude mp3 jedinej nejlepsi a nejpouzivanejsi format, protoze vis, ze lidi nebudou chtit nic jinyho, nez mp3 ted nabizi, ale tvuj zpusob smysleni nesdilim), pujdou cestou toho formatu

Jinak BTW, MPEG4 AVC multithreadově udělat nelze (už to tady opakuju 100x).

A protoze mpeg4 multithreadove nejde udelat uz nikdy nikdy nikdy nikdy nebude mozne multithreadove komprimovat video ... ale notak eagle ... ted uz ses fakt mimo ...

Plně souhlasím s tím, co tvrdí AMD - že cesta zvyšování výkonu v desktopu vede přes vysokofrekvenční jednojádra doplněná účelovými akcelerátory

ale notak. ted si sam protirecis. jeste nedavno jsi tu prohlasoval ze DSP, nebo crypto-akcelerator v procesoru je uplne k ho*** ... coto coto, najednou je jednoucelovej akcelerator ta spravna cesta?

[Eagle]

jasne. hlavne do mp3 vpohode dostanes vic jak dva kanaly a pripadne dalsi features. ano lidi rozhodnou a pokud jim jinej format nabidne vic (a nemusi to bejt jen lepsi kvalita, ale trebas mensi vyslednej soubor, bo prave vic kanalu, bo neco jinyho

Smůla, tak to v reálu nechodí. Už dlouho existují lepší formáty než MP3 (např. lossless). Ale lidi tohle nezajímá. Lidi nejdou za kvalitou, jdou za tím, co je moderní a o čem se mluví. Myslíš, že někdo v roce 1997, když jsem s MP3 začínal, věděl, co to MP3 je? Nebo znal WinAmp? Jen hrstka. Myslíš, že když se dneska někoho zeptám, co to je FLAC nebo Monkey's Audio, že bude vědět? Myslíš, že lidi ví, co je Super Audio CD nebo DVD Audio? Ani omylem. Jim ty dva kanály v 44,1 kHz stačí (i komprimovaně v MP3), protože stejně nemají aparaturu, která by zvládla víc (protože do ní nechtějí dávat prachy, neboť všechny ty sestavy vypadají v Datartu stejně, a tak si vyberou tu, která má brand nebo je nejlevnější). A i kdyby měli, tak jich to většina neuslyší, takže jakápak motivace pořizovat si jí vyjma toho dělat ze sebe kinga?

Exact Audio Copy je taky nejlepší extrakční program. Proč ho tedy většina lidí nepoužívá? Proč si dodnes lidi myslí, že A64 3000+ má frekvenci 3 GHz? Proč má většina lidí peníze na termínovaných účtech v bankách, když jim fond nabídne několikanásobně vyšší zhodnocení?

Jo a mimochodem, CDčka byly uvedeny už v roce 1982 a proti kazetám znamenaly výrazný skok vpřed v kvalitě zvuku. Víš, když se začaly používat masově? Až v okamžiku, kdy je bylo možné snadno okopírovat a kdy cena přehrávačů a vypalovaček poklesla v důsledku masové dostupnosti natolik, že si to mohl dovolit téměř každý. VHS vs. betamax - kdopak to tehdy vyhrál a kdopak to měl lepší kvalitu? DVD-Audio - první disky v obchodech už v roce 2000. Doteď jsem u nikoho neviděl jediný kus!

A protoze mpeg4 multithreadove nejde udelat uz nikdy nikdy nikdy nikdy nebude mozne multithreadove komprimovat video ... ale notak eagle ... ted uz ses fakt mimo ...

MPEG4 AVC je jeden z výpočetně nejnáročnějších kodeků dneška a žádný dnešní procesor ho není schopen zvládnout v realtime. Ona ta intenzivní komprese zjevně způsobuje závislosti mezi snímky...

ale notak. ted si sam protirecis. jeste nedavno jsi tu prohlasoval ze DSP, nebo crypto-akcelerator v procesoru je uplne k ho*** ... coto coto, najednou je jednoucelovej akcelerator ta spravna cesta?

AMD na něj má HTX slot, takže integrovat ho do CPU momentálně nebude (tudíž nezvýší spotřebu CPU a nesníží mu frekvenci). Integrace CPU a grafické karty se u AMD plánuje pro notebooky, kde to uspoří elektřinu.

[Fox!MURDER]

blablabla, kecy, ktery nejsou k veci...

uz si zase protirecis a protoze nemas co na to rict, tak se snazis tu diskuzi zase zatahnout jinam, tak, jak to tu delas uz asi 17 z 18ti stranek. na tohle uz nemam naladu ani nervy.

[Petrik]

1) Ja nevim jak tobe, ale me rychlost dnesnich CPU v MP3 kompresi pripada docela slusna, kdyz zrovna nekomprimujes stovky skladeb naraz, tak MT MP3 proste nepotrebujes

2) http://www.videohelp.com/tools?tool=HandBrake tak nejde, jo? Ze von to ten autor nevedel a sel a udelal to...

3) Uved mi prosim nekolik bezne pouzivanych desktopovych uloh, ktere trpi tragickym nedostatkem vykonu a ktere nelze paralelizovat?

4) A proto AMD uvadi QC, to bude ono. Jestli neco planujou, tak tozhodne ne jednojadra

5) takze souhlasis s tim, ze psat SW na Cell asi lze, kdyz se ty hry na nem hybaji hodne dobre, jo? To jsi se dostal do slepe ulicky, co Na jednu strany tvrdis, ze hry psat MT nelze a take jsi tvrdil, ze psat SW pro Cell je skoro nemozne. Ted jsi k tomu jeste dodal, ze i stara G4ka je rychljesi nez Cell (ktery obsahuje jakoby G5). Nejak tedy nechapu, jak je mozne, ze se ty hry na tom tak uzasne hybaji

6) Ano, Eagle, pro me je v integer operacich vykon meho CPU vice nez dostatecny. Jestli potrebuji vetsi vykon napr. v podobe C2D, rozhodne ne kvuli interger vykonu, ale hlavne kvuli float. Typickou ulohou, ve ktere me CPU brzdi je ripovani videa nebo ve hrach. Ani v jednom mi integer moc nepomuze.

7) Evidentne jsi ci neprecetl ten clanek o Valve source enginu. Precti si ho. Tam mas vysvetleno, jak je ten jejich MT engine udelany a stejne tak tam jasne rikaji, ze do budoucna nebude problem zamestnat mnoho jader.

8 )Ad kompilovani. Ja nemusim vedet, jak to udelat, me na argumentaci staci, ze to nekomu funguje a ze to realne pouzivaji. A oni maji na mysli vylozene MT kompilovani, coz myslim dostatecne vypliva z toho uryvku, co jsem sem postnul.

V tom clanku, na ktery sem jeste jednou dam link, je myslim dost jasne nastinen budouci vyvoj hernich enginu. Dale z nej vypliva, ze Valve vyviji celou sadu nastroju, ktere umozni vcelku pohodlne psani MT her, coz je taky patrne duvod, proc je vyvoj toho jejich engine tak drahy...protoze zaroven museli vytvorit tyto nastroje, jejichz uvedeni na trh jsem predpovidal nakde na zacatku tohoto threadu a za coz se mi Eagle nalezite vysmal.

http://arstechnica.com/articles/paed...-multicore.ars

Víš, o tomhle nerozhodují firmy, ale lidi. A pokud je dnes MP3 nejoblíbenější kompresní formát na hudbu, tak to tak prostě je a málokdo to dokáže změnit. Většina lidí rozdíl mezi MP3 a lossless neslyší, a proto jim MP3 vyhovuje a s největší pravděpodobností i vyhovovat bude. Proč si myslíš, že se neuchytily formáty Super Audio CD a DVD Audio?

Jinak BTW, MPEG4 AVC multithreadově udělat nelze (už to tady opakuju 100x).


Většina činností, které lze paralelizovat, nepatří mezi typické desktopové úlohy (vyjma videa). Typická úloha je sekvenční, stejně jako v matematice. A i v matematice se musíš řídit prioritou operátorů, jinak se nikdy nedobereš správnému výsledku. Jistě že se najdou i úlohy, které využijí masivní paralelismus, ale ty jsou z oblasti supercomputingu. V desktopech bude znamenat více jader jediné - pokles výkonu v drtivé většině aplikací.

Plně souhlasím s tím, co tvrdí AMD - že cesta zvyšování výkonu v desktopu vede přes vysokofrekvenční jednojádra doplněná účelovými akcelerátory.


Stále ještě... haha. A to si jako myslíš, že nějaká optimalizace cosi spraví? Out-of-order single-core procesor bude ve většině desktopových věcí vždycky rychlejší než zastaralý Cell.


Dostatečný? Takže ty vlastně žádný výkon nepotřebuješ, viď? A když je dostatečný, tak proč tady lidi tak básní o Core 2 Duo, který posiluje právě integer výkon?


Ano, grafika u her paralelizovatelná je, ale to je dáno tím, že daná scéna obsahuje stovky tisíc pixelů, které jsou jeden na druhém nezávislé. Je to jako když máš dvacet pytlů s cementem a má je odnést jeden chlap nebo dvacet chlapů. Jenže většina desktopových aplikací (včetně např. věcí, které dnes ve hrách připadají na CPU) je sekvenční - podobně jako když se dělá beton, tak tam je ti taky 20 pytlů s cementem na prd, když potřebuješ naházet do míchačky cement, písek, štěrk a vodu a počkat, až se to pořádně promixuje.

Proto tvrdím, že u desktopu vede cesta přes paralelizaci v GPU a vysokofrekvenční single-core CPU, které zvládne sekvenční úlohy.


Jasně, takže když už mám v počítače vysoce výkonným SIMD procesor v podobě GPU, tak si tam ještě budu cpát stejně koncipovaný CPU. Víš, jaký bude výsledek? Pokles výkonu ve většině aplikací! Proto říkám, že CPU má jít cestou vysokého sekvenčního výkonu a GPU ho doplňovat při paralelizaci těch několika málo úloh, které se paralelně dají napsat (např. video).


Jestli si stále myslíš, že budu investovat peníze do něčeho, co mi nezvýší výkon v současných aplikacích (nové si pořizovat nebudu, protože to stojí peníze a ty současné plní úlohu dobře), prosím, ale myslím, že už sám začínáš chápat, že takto to nebude...


Kompilovat multithreadově jde skutečně velmi špatně a pokud si myslíš něco jiného, tak nám nastiň, jak si to představuješ. Něco jiného je kompilace více zdrojáků paralelně (to ale nemá s multithreadingem vůbec nic společného, je to stejné jako u těch pixelů). A jen pro zajímavost - Visual Studio 2005, nejdůležitější vývojový nástroj pro nejrozšířenější počítačovou platformu, neumí spouštět víc instancí kompilátoru najednou.


Pořád nedokážeš pochopit elementární věci? Je sakra rozdíl mezi tím, jestli máš ujet 10 km co nejrychleji nebo přepravit na vzdálenost 1 km 10 tun písku. Na to první bych asi Tatru 815 nepoužíval. Pokud ty ano, tak se pak nediv, že to jede tak pomalu.

[svaca]

3) Uved mi prosim nekolik bezne pouzivanych desktopovych uloh, ktere trpi tragickym nedostatkem vykonu a ktere nelze paralelizovat?

mencoder, avidemux, virtualdub, xvid, x264, lame, transcode = kvuli temto aplikacim si kupuju porad dokola moderni CPU a stale to CPU je pomale na muj vkus, nesnasim cekani.

4) A proto AMD uvadi QC, to bude ono. Jestli neco planujou, tak tozhodne ne jednojadra

To nemyslis vazne Jak muzou "riskovat" vyvoj jedno-jadra, kdyz tomu lidi nerozumej a dnes je zajimaji dual core, protoze je to v reklame a leti to, je pak tezke se pres takovy marketing prenest ...
Presne duvod proc kdysi AMD muselo zavest rating, protoze proste procesory AMD mele na mensi frekvenci, VYSSI vykon nez "dokonaly" intel ... proste lidi nerozumi, ze ten procak je lepsi, vidi jen oznaceni ... a reklamu. To same DDR1 a DDR2 a porad dokola ...

5) takze souhlasis s tim, ze psat SW na Cell asi lze, kdyz se ty hry na nem hybaji hodne dobre, jo? To jsi se dostal do slepe ulicky, co Na jednu strany tvrdis, ze hry psat MT nelze a take jsi tvrdil, ze psat SW pro Cell je skoro nemozne. Ted jsi k tomu jeste dodal, ze i stara G4ka je rychljesi nez Cell (ktery obsahuje jakoby G5). Nejak tedy nechapu, jak je mozne, ze se ty hry na tom tak uzasne hybaji

V tomhle mas pravdu. To je ta spravna cesta.Myslim si taky, ze Cell je super a ze v dane konzoli je to silna zbran + sladeny HW a SW = pecka ... tak by to melo fungovat ....

[tomase]

mencoder, avidemux, virtualdub, xvid, x264, lame, transcode = kvuli temto aplikacim si kupuju porad dokola moderni CPU a stale to CPU je pomale na muj vkus, nesnasim cekani.

Pre niekoho bude dlho aj ked sa mu to skomprimuje za 10sekund. Vsetko je totiz relativne.

[svaca]

Pre niekoho bude dlho aj ked sa mu to skomprimuje za 10sekund. Vsetko je totiz relativne.

ale je to trochu rozdil, zda to porva sekundy nebo hodiny, ne ?

[tomase]

ale je to trochu rozdil, zda to porva sekundy nebo hodiny, ne ?

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

[Eagle]

1) Ja nevim jak tobe, ale me rychlost dnesnich CPU v MP3 kompresi pripada docela slusna, kdyz zrovna nekomprimujes stovky skladeb naraz, tak MT MP3 proste nepotrebujes

Fakt? Ty jsi asi nikdy v LAME na vysokou kvalitu nekomprimoval, viď ?

2) http://www.videohelp.com/tools?tool=HandBrake tak nejde, jo? Ze von to ten autor nevedel a sel a udelal to...

Kdyby sis o tom něco pozjišťoval, věděl bys, že multithreading v H.264 je řešen s viditelnou ztrátou kvality. Jenže ty se opět spokojíš s povrchním pohledem. Pak nemá smysl ti nic vysvětlovat.

3) Uved mi prosim nekolik bezne pouzivanych desktopovych uloh, ktere trpi tragickym nedostatkem vykonu a ktere nelze paralelizovat?

MP3, Monkey's Audio (možná jde, možná nejde, ale teď není paralelizováno), DOSbox (s největší pravděpodobností jde, ale není paralelizováno), realtime antivirus (nejde), XviD (je jen beta, která padá), MPEG4 AVC (nejde), hry (např. Civ III paralelní není a výkonu by potřebovala kvantum; nové střílečky jen obtížně a za cenu prasáren), Excel (není, možná by šlo omezeně pro některé úlohy, ale např. pro řešitele nejde), programovací nástroje (nejsou), šifrovací algoritmy (z principu nejdou), WinRAR (nejde), Photoshop (je jen z části a výkon navíc nic moc), šifrování disku (nejde), deassembler (nejde), spousta starších programů a her (např. Bryce 5, ACDSee 3.1, hry se SW renderingem - ty už nikdo nikdy předělávat nebude, existují novější alternativy, které ale nemusí jedincům sednout a navíc si je musí lidi koupit).

Výsledek? Většina aplikací momentálně NENÍ paralelní. V budoucnu tu určitý potenciál je, ale závisí jen na tom, jak se programátoři budou snažit. Já tvrdím, že se nepřetrhnou, stejně jako se nepřetrhnuli u SIMD a HyperThreadingu.

4) A proto AMD uvadi QC, to bude ono. Jestli neco planujou, tak tozhodne ne jednojadra

AMD uvádí QC do serverů. Do desktopů jen jako konkurenci Intelu (= pro vejtahy). Sami ale už několikrát dávali najevo, že QC do desktopů ani neplánovali.

5) takze souhlasis s tim, ze psat SW na Cell asi lze, kdyz se ty hry na nem hybaji hodne dobre, jo?

Souhlasím s tím, že pro určitý typ software je Cell zajímavé řešení. A že se na něm hry hýbají? Neviděl jsem žádné statistiky o tom, kolik z toho udělá GPU a jak moc jsou ty hry náročné na CPU. Jenom jsem z dobrého zdroje slyšel, že od Sony utíkali programátoři, protože byli otráveni programováním pro Cell. Dále jsem taky slyšel, že cena jedné hry pro PS3 je tak vysoká, že se musí prodat vysoce nadstandardní počet kusů. A konečně taky se říká, že hry pro PS3 jsou kvalitou velmi podobné těm, které jsou na XBox 360, který má jen tříjádrový in-order pomalý procesor.

Jinak v těch testech stará out-of-order G4ka tuším že na 1.6 GHz až na výjimky dosahovala podstatně vyššího výkonu než 3GHz Cell.

6) Ano, Eagle, pro me je v integer operacich vykon meho CPU vice nez dostatecny. Jestli potrebuji vetsi vykon napr. v podobe C2D, rozhodne ne kvuli interger vykonu, ale hlavne kvuli float.

Když chceš výkon ve float, tak proč C2D ? A64 má výrazně rychlejší FPU než C2D.

Typickou ulohou, ve ktere me CPU brzdi je ripovani videa nebo ve hrach.

Na hry nepotřebuješ ani integer, ani float výkon, tam potřebuješ velkou rychlou cache a rychlý přístup do RAM.

jasne rikaji, ze do budoucna nebude problem zamestnat mnoho jader.

A proč nám tedy nevysvětlíš, jak tu paralelizaci hodlají provést, když se tím pořád oháníš? Stále jsi nebyl schopen vyvrátit to, že je to s největší pravděpodobností prasárna.

8 )Ad kompilovani. Ja nemusim vedet, jak to udelat, me na argumentaci staci, ze to nekomu funguje a ze to realne pouzivaji.

Ano. A já zas vím, že ve Visual Studiu 2005 to nefunguje.

vyviji celou sadu nastroju, ktere umozni vcelku pohodlne psani MT her

Stejně jako je vyvíjel Intel? Haha, tomu to taky nějak nevyšlo. Autoparalelizátor přidá nula nula nic výkonu navíc a OpenMP rozhodně není "pohodlné".

[mraky]

Většina činností, které lze paralelizovat, nepatří mezi typické desktopové úlohy (vyjma videa). Typická úloha je sekvenční, stejně jako v matematice. A i v matematice se musíš řídit prioritou operátorů, jinak se nikdy nedobereš správnému výsledku. Jistě že se najdou i úlohy, které využijí masivní paralelismus, ale ty jsou z oblasti supercomputingu. V desktopech bude znamenat více jader jediné - pokles výkonu v drtivé většině aplikací.

Vis, ty by jsi mel delat politiku. Ja se te na neco zeptam a ty odpovis necim jinym. Stale tu oponujes mp3kama a kdyz ti nekdo rekne, ze by se dualcore pro jeho praci hodilo, tak ty zase zacnes mp3 a vetsinou aplikaci. Nikdo ti to nebere, ale ty proste neuznavas nic jineho nez vetsinu aplikaci a podle ni by se mel ridit cely svet.

[THX]

Typická úloha je sekvenční, stejně jako v matematice. A i v matematice se musíš řídit prioritou operátorů, jinak se nikdy nedobereš správnému výsledku.

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

Stále ještě... haha. A to si jako myslíš, že nějaká optimalizace cosi spraví? Out-of-order single-core procesor bude ve většině desktopových věcí vždycky rychlejší než zastaralý Cell.

Vsetko to, co dokaze reorder instrukcii v out-of-order cpu, dokaze rovnako kompiler. Dokonca ten ma na to viac casu a prostriedkov, takze ak je program dobre skompilovany, instrukcie su uz preuspriadane, uz su out of order... 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...

je sekvenční - podobně jako když se dělá beton, tak tam je ti taky 20 pytlů s cementem na prd, když potřebuješ naházet do míchačky cement, písek, štěrk a vodu a počkat, až se to pořádně promixuje.

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....
Navyse, ak robis beton, tak tam ti tych 20 pytlu s cementem prijde celkem vhod

GPU ho doplňovat při paralelizaci těch několika málo úloh, které se paralelně dají napsat (např. video).

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

Na notebooku přece stejně žádné náročné úlohy dělat nemůžeš. Jsi tam omezen extrémně pomalým diskem, malou RAM (nelze mít velkou kvůli malému počtu slotů a požadavku na SO-DIMM), nízkým TDP (=> limituje napětí a frekvenci).

Pomaly disk - riesenie - hybridne disky. Ramky sa tam da dat tiez celkom dost. Apple robi notebooky urcene pre pracu s videom a su aj celkom vykonne a pouzitelne. Takze ano, aj na notebooku mozes robit narocne ulohy.

Fakt? Ty jsi asi nikdy v LAME na vysokou kvalitu nekomprimoval, viď ?

Stale sa tu ohanas s tym, ze vo vacsine aplikacii a vacsina uzivatelov. 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.

MP3, Monkey's Audio (možná jde, možná nejde, ale teď není paralelizováno), DOSbox (s největší pravděpodobností jde, ale není paralelizováno), realtime antivirus (nejde), XviD (je jen beta, která padá), MPEG4 AVC (nejde), hry (např. Civ III paralelní není a výkonu by potřebovala kvantum; nové střílečky jen obtížně a za cenu prasáren), Excel (není, možná by šlo omezeně pro některé úlohy, ale např. pro řešitele nejde), programovací nástroje (nejsou), šifrovací algoritmy (z principu nejdou), WinRAR (nejde), Photoshop (je jen z části a výkon navíc nic moc), šifrování disku (nejde), deassembler (nejde), spousta starších programů a her (např. Bryce 5, ACDSee 3.1, hry se SW renderingem - ty už nikdo nikdy předělávat nebude, existují novější alternativy, které ale nemusí jedincům sednout a navíc si je musí lidi koupit).

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
Winrar je paralelny, sifrovacie algoritmy mozu napr. rozdelit subor na viacero casti (kazdopadne aj bez rozdelenia sifruje priemerny procesor omnoho rychlejsie ako dokaze priemerny disk zapisovat, takze naco nejaka paralelizacia...). Na starsie programy a hry nepotrebujes vyssi vykon.

Dále jsem taky slyšel, že cena jedné hry pro PS3 je tak vysoká, že se musí prodat vysoce nadstandardní počet kusů. A konečně taky se říká, že hry pro PS3 jsou kvalitou velmi podobné těm, které jsou na XBox 360, který má jen tříjádrový in-order pomalý procesor.

Hry na ps3, xbox a pc su velmi podobne, pretoze su to vacsinou aj tak tie iste hry... Vyssia cena hry je casto sposobena nutnostov vytvorit vacsi a detailnejsi obsah.
Do buducna budu hry robene aj tak na najrozsirenejsich enginoch (valve, id soft a epic) - ktore su/budu vsetky multithreadovane (tiez aj koli tomu ze ako pc, tak xbox aj ps3 ma viacjadrove procesory...)

A proč nám tedy nevysvětlíš, jak tu paralelizaci hodlají provést, když se tím pořád oháníš? Stále jsi nebyl schopen vyvrátit to, že je to s největší pravděpodobností prasárna.

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.

Ale lidi tohle nezajímá. Lidi nejdou za kvalitou, jdou za tím, co je moderní a o čem se mluví.

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

Jim ty dva kanály v 44,1 kHz stačí (i komprimovaně v MP3), protože stejně nemají aparaturu, která by zvládla víc (protože do ní nechtějí dávat prachy, neboť všechny ty sestavy vypadají v Datartu stejně, a tak si vyberou tu, která má brand nebo je nejlevnější). A i kdyby měli, tak jich to většina neuslyší, takže jakápak motivace pořizovat si jí vyjma toho dělat ze sebe kinga?

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.

Integrace CPU a grafické karty se u AMD plánuje pro notebooky, kde to uspoří elektřinu.

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. Takze teraz si trocha protirecis - znizi to teda tu spotrebu, alebo nie?

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?

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