Tak presne ...
Ale to neznamena, ze se na to bude kaslat, nebot stejne az to vydame, tak to na novym HW pojede OK i kdyz se to nam nehybe ....
Printable View
Tak presne ...
Ale to neznamena, ze se na to bude kaslat, nebot stejne az to vydame, tak to na novym HW pojede OK i kdyz se to nam nehybe ....
Mam pocit, ze se kazdy bavite o jine veci. Core 2 duo je i pres vynalozene penize jasne nejrychlejsi cpu, at v single threaded tak i v multithreaded aplikacich. A myslim, ze o tom hlavne to je a proto si ho lidi z 4a i jinde koupili a kupuji. Cena je vyssi, ale je to proste to nejlepsi a tak to funguje u vsech veci. To, ze v tuto dual core nema pro vetsinu lidi smysl je fakt, ale pocitam, ze se to v nejblizsi dobe zmeni a nemyslim si, ze by jsme se nekdy vraceli k single core.
Takze muj zaver je. Chci nejrychlejsi cpu, tak si koupim core 2 duo. Sice zaplatim za druhe jadro, ktere v tuto chvili nevyuziju, ale s casem budu za nej rad, protoze jednak budou pro nej vyvijeny aplikace a za druhe v nejblizsi dobe nevyjde zadne cpu, ktere by jeho pozici mohlo napadnout.
Ja bych skoro navrhl udelat hlasovani a moznosti by byly:
1) Mam core 2 duo a jsem spokojeny, i pres vynalozene penize.
2) Mam core 2 duo a jsem spokojeny, ale za ty penize to nestalo.
3) Nemam core 2 duo, ale koupim si ho.
4) Nemam core 2 duo a nechci ho.
Docela dobrej nápad, ale původně to tu mělo bejt o dvoujádrovejch procesorech všeobecně, ne jenom o C2D, takže bych to neomezoval.
Mám Core Duo a Core2Duo mi za ty peníze navíc nestálo (výkon 10-15% navíc a větší spotřeba) ;-).
Zkouším nový směr...takhle už ta diskuze stejně byla nějak moc o hovně ;-).
AMD zpochybňuje momentální vývoj vícejádrových procesorů [svethardware.cz]
Mam Turion X2 a jsem spokojeny, i pres vynalozene penize:cool:............C2D v době když sem to kupoval eště nebylo dostupný a oproti CD se X2 vyplatilo víc.
neviem ci tu padla taka otazka, ale ma niekto uz INTEL Core 2 Extreme QX6700 ?
Turion sa vyplati este stale viac ako intel, mobilne C2D ma ako uz bolo spomenute si 15% vykonu viac ako CD a TurionX2 je vykonovo povodnemu CoreDuo uplne adekvatny, navyse dostanes 64bit rozirenie, ktore CD este nemalo. C2D v kombinacii s vyvazenou grafikou GF7600go/Ati X1700 dostanes az v notebookoch o 40+% drahsich ako to co mame ty a ja (preto mozno nie som uplne objektivny >:} ).
V soucasny chvili mam SanDiego 10x285 a neuvazuju o prechodu na C2D. To by bylo vyhazovani penez. Spis by se siklo vic ramky, 1GB je malo, GRRRRR. Prestavam chapat, kam vsechno smeruje, ale zahrat si Gothic III s 1GB ramky je spis utrpeni nez zabava :(
ted neco z reality: prave grabuju CDcko v EACu a wokna jsou naproto nepouzitelna. Zkusil jsem snizit prioriotu EACu, ale to nepomohlo. System totiz nezatezuje EAC jako takovy, nybrz digitalani extreakce z CDcka, kterou provani system a ne EAC. Prestoze je vyuziti CPU jen 30% (EAC spotrebovava 0%), je system nepouzitelny, winamp se traha pod. Podobne to je s lame. Eac po nagrabovani kazdeho tracku pusti lame encoder, ktery vytizi CPU na max a komp se opet stava nepouzitelnym. Reseni je dat mu nizsi prioritu, ale to bych musel u kazdeho tracku pokazde znovu, coz neni zrovna pohodlne.
Kdybych mel druhe jadro, byla by to parada, vubec bych o nejakem grabovani nevedel. Porad je tedy druhe jadro na h*?
Pro rypaly: DMA na CD je zapnute....
To se mi zda trosku divne, sam se nagraboval velkou spoustu CDcek na singlecore CPU, nic podobneho sem nepozorovat.
A u lame lze priorita nastavit nejakym parametrem.
Kazdopadne souhlasim, ze tohle sou presne pripady kdyz je dualcore k nezaplaceni - do nedavna sem neveril, ze bych mohl grabovat z TV a u toho normalne pracovat.
Ze vraj na hry netreba procak (dokaz: nastavte detaily tak, aby bola obmedzenim grafika ... ze to pri takych detailoch nebude hratelne je iba detail :) )
http://www.amdzone.com/pics/gaming/r...ledualcore.jpg
Grafika 8800GTS, fx-62 procesor.
Cely clanok tu -> http://www.amdzone.com/modules.php?o...tid=279&page=2
Sorry, ale toto je o nicem ....
Chapu, co chces rict, ale silny procak "zatim" nepotrebujes, protoze mas silnou grafiku ...
Toto dokazuje, ze v teto hre se pozna optimailzace jader, ale ta je ti VZDY na hovno, kdyz nemas poradnou grafiku .....
A k cemu ti je dual core, kdyz NEMAS na grafiku ... :-)
23FPS v 1600x1200, kdy uz na CPU nezalezi, je podle tebe dobry? Sorry, ale tohle je docela silny argument pro DC, jelikoz skore 35 vs. 49 v 1024x768 je sakra rozdil...a mimochodem pro hrani na urovni je i tech 49FPS malo...takze pro tuto hru to chce DC zcela jednoznacne ;)
EDIT: jo aha, to je ironie :D Takze konecne prvni hra, kterou si zastanci SC pohodlne nezahraji? Jednou to prijit muselo, necekal jsem, ze tak brzy. Konecne tento thread zacina davat smysl ;)
Podle me teda lidi spise nez CPU upgraduji grafiku. A taky jde konecne videt, ze DC je vyuzitelny i ve hrach.
hmm, hrat nove hry v 1024*768 .. to je dost bieda .. a v slusnych rozliseniach sa rozdiely stieraju
Kdyz chces hrat ve vyssim rozliseni, tak holt musis zakoupit 2 grafiky do Crossfire nebo SLI.
Že seš lama a neumíš používat počítač, neznamená, že to neumí ostatní.
Příloha 2871
48x nebezpečná extrakce Burst - zátěž na CPU asi 30 %
Příloha 2872
4x bezpečná extrakce Secure - zátěž téměř nulová
Prestoze moje PC ma neco lehce pres 4 roky, tak u grabovani cd jsem nikdy nic podobneho nezazil. Tobe tam vazne neco hnije a to dost, kdyz blbe grabovani cd ti zpomali pocitac, chapal bych to driv, nekdy na 486kach, ale dnes? EAC si u me bere kolem 2-3% a cely zbytek lame ( 97% ). Netusim o jakych 30% to povidas, to by vazne ukazovalo na PIO mod, at uz u CD nebo HDD.... a i kdyby ti to tech 30% zralo, tak winampu nestaci 70% ?? ... podle meho to cele zni az moc neuveritelne, nez aby to byla pravda... to by ti pak nestacil ani quadcore, 1.cpu 100% system, 2.cpu 100% eac, 3. cpu 100% lame, 4.cpu 100% winamp a zase ti nic nezbude.
Dalsi tvuj argument pro DC je ze bud nechces nebo neumis nastavit prioritu cpu. Ja si nastavil prioritu v EAC jednou a od te doby si ji to pamatuje, kazdy encoder ji dedi, at uz lame, flac, ogg, ci cokoli jineho, takze zadnou nepouzitelnost windows nepozoruji a jedine co dava na jevo, ze se na pc neco deje je hucici mechanika.
Takhle to skoro vypada, ze jsem proti DC, nejsem, ale tvoje argumenty jsou uplne mimo, dualcore jiste sve vyuziti ma, ale rozhodne to nebude grabovani cd, kdy encoder ceka na mechaniku.
Achjo, ze ja se vubec zaplet do tohoto nesmyslneho threadu, ktery je uz 10 stran o tom samem a zaroven o nicem, kazdy si povida o svem a druheho neslysi.
Rozdily se stiraji, protoze to brzdi grafika na nehratelnych hodnotach FPS. Nic to ale nemeni na tom, ze na SC se nad rekneme 40FPS nedostanes, leda bys mel treba 3.5GHz, ktere mometalne k dispozici neni. I kdyby byl, je mnohem ekonomictejsi koupit si "levny" DC, leda by ten 3.5GHz SC byl nejak hodne levnej, coz rozhodne nebude :)
Okej, nejak zakerne si mi tam prehodilo PIO, asi mi odchazi mechanika, kontroloval jsem to par dni pred tim a bylo tam jeste DMA...takze my bad, uznavam a hamba mne, sorry. Stejne by to ale na DC jelo vpohode i na PIO, ze?
Mimochodem, co rikas na to Rainbow six: vegas? Porad tvrdis, ze DC je na h*, ze se hra neda udelat MT (nebo ze to je prasarna) nebo konecne uznas, ze jsi se mylil (jako ted ja napr.) a zacneme se bavit o tom, zda je DC zrovna ted ekonomicke a od kdy a komu se vyplati?
Stejne tak pro Swarma: porad tvrdis, ze nove hry, ktere brzy vyjdou, budou hratelne na SC, jak jsi tu tvrdil? Pochybuju ze ten vegas bude vyjimka...
Aha, tak to chce silnejsi bryle, nebo delsi dobu na prohlidnuti / premysleni. Prelozim ti to: v nejnizsim rozliseni, tj v 1024x768 jsou vysledky SC:35fps, DC:49fps. Co to znamena? Na DC to bezi o 40% rychleji nez na SC. Navic lze ocekavat, ze i v takto nizkem rozliseni to stale limituje graficka karta, takze na lepsi karte / s nizsimi detaily bude rozdil mezi DC a SC jeste vetsi. Zasadni ovsem je skutecnost, ze k tomumo obrovskemu rozdilu dochazi uz pri velmi nizkych hodotach fps. Ve vetsich rozlisenich se vice prijevuje omezeni graficke karty, takze vliv CPU prestava byt znatelny. Troufam si tvrdit, ze ani se sebelepsi grafikou to na podobnem (pozor, je to 2.8GHz!) SC vice nez 40-45FPS nepojede, a jelikoz se urcite jedna o prumernou hodnotu, tak to na pohodle hrani rozhodne nestaci. Zaver? Na skutecne hrani teto hry to chce dve veci: hodne dobrou grafiku a DC...
Tvrdim, ze je to nesmysl ...
Testnete nekdo treba Venice 2.6G a nejakou nadupanou kartu, pojede to jak z praku ......
Vykonny CPU je pro vetsinu lidi k nicemu, presne jak porad tvrdi Eagle ..
ted jsem presel z Venice 2.7G na Conroe 3.6G, rozdil ???
Krome BRUTALNIHo narustu vykonu v enkodovani a compilovani, skoro zadny za ty penize ....
Pre 90% uzivatelov Pc je 2xcore uplne zbytocna vec, vyhodene peniaze. Najrozumnejsie je si kupit nejaky Low-end Celeron resp. Athlon64, trochu zainvestovat do lepsieho chladenia, a pretocit ho co to da. A vybavene.
To jsou teda argumenty. Asi jako vyhánět mouchu plamenometem.
Ještě tady nikdo z obhájců DC nepřednesl návrh, jak udělat výpočet fyziky tak, aby mohl běžet paralelně se zbytkem hry. Čili ano, pořád si myslím, že to je udělané nějakou formou prasárny. Teoreticky je možné paralelizovat všechno, otázkou je jak a za jakou cneu.
A co říkám na tu hru? Že tady byly uvedeny chybně parametry počítače. Takže to shrňme správně, jak je to v článku:
A64 3200+ s 7900 GT: 35fps
A64 X2 3800+ s 7900 GT: 49fps
To mi právě 2x extrémní nepřijde, když je to procesor za 2 tisíce s DPH. A prý se měřilo FRAPSem, což single-core proti reálu znevýhodní.
BTW, všechny tyhle měření jsou sice hezké, ale z mých praktických zkušeností z testování vyplývá, že rozhodujícím měřítkem je minimální fps, které ale bohužel prakticky vždy visí na výkonu grafické karty. Průměr není reprezentativní. Uvažujme následující situace:
1) 50 % času 20 fps, 50 % času 40 fsp. Průměr je 30 fps.
1) 50 % času 20 fps, 50 % času 100 fsp. Průměr je 60 fps.
Jaká bude hratelnost obou situací? Asi nic moc, že? A když mi oněch 20 fps způsobí omezení grafikou...
OK, tak sorry, zle info o zostave - na 1. stranke clanku maju inu zostavu, fx-62, 8800gts, tak som nejak predpokladal ze to islo na tom istom. V case ked som sem daval link, ten clanok mal iba 2 strany a ta druha zostava tam nebola uvedena.
No ale pekne vidno ako UE3, na ktorom bude postavenych vela hier dokaze vyuzit DC (a aj QC).
7900gt je dnes povedal by som vyssia stredna trieda, teda grafika celkom bezne dostupna a pouzivana na hranie, x2 3800+ tiez nie je ziadne delo, ale o 2tis. drahsi procak (3800 vs 3200) dal lepsi vysledok ako o 2 tis. drahsia grafika...
Ako vidno, UE3 je dost procesorovo narocny, takze by som povedal ze min fps. bude zavisiet aj od procaka. A predsa je dost rozdiel mat priemer 35 a 49fps. To prve je na hranici hratelnosti, druhe uz celkom v pohode...
A namiesto toho frapsu si predstav driver od realteku zvukovky (pripadne creative), ktory zatazi procesor urcite viac ako ten fraps...
Zaujimavejsi je graf pre QC (teda, 2x2 - FX74 3ghz dual cpu system a 8800gtx).
http://www.amdzone.com/pics/gaming/r...adcoretest.jpg
Skratka UE3 vie vyuzit dalsie dostupne jadra.
Co sa tyka paralelneho vypoctu fyziky: pred vykreslenim nacitat vstup od usera pre dalsi frame, jedno jadro pocita fyziku pre nasledujuci frame, druhe jadro a grafika robi vsetko ostatne suvisiace s vykreslenim stareho frame. Skratka taka jednoducha "dvojstupnova pipeline". Lenze - uz aj driver grafiky vie vyuzit to druhe jadro, aj ked nie 100%tne.
Co sa tyka priemeru:
Priemer je tiez dolezity. Ak mam situaciu kde mi to 2x za hru spadne na 15 fps a potom ide okolo 30, a druhu situaciu kde to tiez 2x spadne na 15 a potom ide 60, tak jednoznacne beriem tu druhu sitaciu. Min fps vobec nehovori nic o tom, kolko krat to spadne napr. na 16, 17 atd. fps. Kludne to moze ist v oboch pripadoch takto: v prvom v kuse 16fps, 2x 15, a potom niekde na nejakej jednoduchej scene 150fps. V druhom pripade: v kuse 30fps, 2x15 a potom znova niekde 150fps...
http://images.anandtech.com/graphs/a...1205/13805.png
rozdiel medzi non sli a sli - maxfps sa zmeni iba malo, priemer dost vyrazne
IMHO z těch grafů vyplývá, že QC už nevyužije. Ani ten nárůst výkonu není téměř znát, to je tak možná ovladači, ale hrou sotva.
To mi z článku rozhodně nevyplývá.
Opět jen spekulace.
Ano, ale to vede k lagování, tedy není to čisté.
Tomu grafu moc nerozumím, ale pokud se budu držet tvého vysvětlení, pak tedy přesně odpovídá tomu, co říkám, ne? Že silnější grafika hodně hne s minimálním fps a už moc ne s maximálním fps (protože to je limitováno CPU).
ja by som povedal, ze ak by nemalo QC vyuzit, tak ze tam narast nebude, ale bude tam prepad o 2-5%, ako to casto byvalo v pripade tohto 2x2 "quad" fx-ka
ako to podla teba vedie k lagovaniu? Ved rendering jedneho obrazku bude trvat rovnako dlho ako s pouzitim iba jedneho jadra, akurat sa vyrenderuje 2x viac obrazkov... (a precita 2x viac vstupov od usera)Citace:
Ano, ale to vede k lagování, tedy není to čisté.
Na tom grafe som len chcel ukazat, ze max fps tiez nic neznamena, ako nemozno za jediny ukazatel brat min fps. Najlepsie je brat min fps a potom priemer, idealom je cely priebeh fps z frapsu...Citace:
Tomu grafu moc nerozumím, ale pokud se budu držet tvého vysvětlení, pak tedy přesně odpovídá tomu, co říkám, ne? Že silnější grafika hodně hne s minimálním fps a už moc ne s maximálním fps (protože to je limitováno CPU).
Tvrdim, ze se pletes ;)
Jestlize to na 2GHz procaku udela 36fps, na 2.6GHz to vic jak 47fps neudela, coz porad neni dost na pohodlne hrani, protoze to je prumer. Lepsi grafika tomu IMHO moc nepomuze, protoze ta pouzita s lepsim procakem (DC) dokazala udelat o 40% vic, takze limit bude CPU. Takze kdybych to chtel hrat nejak hodne poradne, napr. jako progamer, coz znamena prumer kolem 80-100fps, bez poradnyho DC se proste neobejdu, tecka.
Naprosto souhlasim. Ja to delam presne tak, protoze na DC nemam v soucasne dobre prachy. Jsou ovsem gamesky, ktere si proste nezahraji pohodlne uz ted (GRAW) a na ty nove, ktere se chystaji, muzu se SC zapomenout uplne.
Trochu jsem o tom premyslel a zatim me tedy skutecne nenapadlo, jak udelat fyziku bezici paralelne se zbytkem tak, aby to nebylo o jeden snimek pozadu. Fyzika je ale jen cast herniho engine. Minimalne to lze udelat tak, ze fyzika bezi ST a po jejim vypocitani uz bezi jednotlive komponenty paralelne. Jak tu ale nekdo veci znaly potvrdil, nemel by byt problem nektere pokrocile fyzikalni enginy napsat paralelne. Jestli jsi celt to povidani s vyvojarem z Valve, tak oni to tak delaji. Nejenom, ze jim bezi paralelne jednotlive soucasti engine, ale zaroven tyto jednotlive soucasti jsou rovnou psany MT, pokud to jde.
Nevim, kde jsi prisel na to, ze min fps VZDY limituje grafika. V hodne hrach (FEAR) to je presne obracene.
Ja myslim, ze se tu budete hadat tak dlouho nez dual core zevsedni a hry a programy uz z toho budou realne tezit :-)
Anebo taky do te doby, nez se budou hadat stylem dual-core vs. quad-core
eagle, inak respekt, ale v tomto nesuhlas a to veliky! ja osobne by som s kludom nalozil aj quad, pretoze robim s muzikou (logic, cubase) a tam je rozdiel single/dual proste neporovnatelny! :)
jasne ze mozes oponovat tym, ze to nie je pre bezneho uzivatela, ale ja mam beznych uzivatelov na haku, ja naozaj potrebujem vykon (inak pochybujem ze na OC taki vobec chodia) :)
jednoducho tym chcem povedat ze nie je na ho*** pre mna osobne je to skvely narast vykonu, ktory mi v danych aplikaciach ziaden singlac jednoducho nemoze ponuknut
:)
Dalsi zalezitost, ktera dokaze tezit z DC je vyvoj software. A ze je na svete programatoru hodne:-)....jen kdyby si to uvedomovali nasi zamestnavatele:-)
To je stále o tom samém dokola! Aplikací, které těží z multiprocesoru jsou mraky (sorry mraky ;) ), sám si dobře pamatuji, jaký přínos v editaci fotek a předně v processingu RAWů (a nejlépe jejich většího objemu) pro mě znamenal přechod na DC a k SC už bych se skutečně nerad kdy vracel.
Tady je hezká ukázka výkonu v jedné z mých primárních aplikací: http://www.firingsquad.com/hardware/...eron/page9.asp .
Tak to tě zklamu, FEAR je závislý na rychlosti práce s daty.
Stačí mít procesor s velkou rychlou L2 cache a rychlým přístupem do RAM (ideálně tedy něco jako A64 s více MB nízkolatenční L2 cache) a máš vysoký minimální počet fps zaručen. S výkonem procesoru jako takového to má pramálo společného. Takováhle situace je ve většině 3D stříleček, ostatně podívej se pár let zpátky na výsledky Pentií M ve hrách.
Přirozeně je možné ti ukázat, že když si nastavíš dobré grafické detaily (tj. nebudeš se honit za 80+ fps, ale naopak za kvalitní vizuální stránkou s přiměřeným fps, které je lidské oko schopné zaznamenat), bude limitem opět grafická karta - viz např. výsledek (nejen) z Quake 4 http://zive.cz/files/obrazky/2006/09...ake4_hires.gif
Které komponenty? Rendering? Tam je to otázkou hlavně grafické karty. Zvuku? Ten příliš zátěžový není. A co zbývá?
Ve hrách si dokážu bez prasárny představit využití více jader např. ve strategiích pro výpočet AI. Otázkou ovšem zůstává, kdo to bude programovat, protože co jsem zatím viděl, tak jsem až na pár výjimek (např. hra Arsenal, která ale běží v pohodě i na Pentiu 100 MHz) moc inteligentního protivníka neviděl. Samé naskriptované záležitosti, popř. jednoduchá inteligence na úrovni jednotky nebo pár jednotek. Nikdy ale ne koncentrované globální strategie (snad až na ten Arsenal). Silnější AI je především otázkou toho, jak zvládnout algoritmus - to stojí moře času a moře debugování. V porovnání s tím je převod na multithreading jednoduchý. Opět tedy otázka - kdo to zaplatí? Ty? Vždyť sám píšeš, že na dual-core nemáš, tak to asi nekupuješ nové hry za 1000+ Kč, že?
A cena? Kdo bude všechny ty hry platit? Pokud budou hráči požadovat stále vyšší kvalitu, tak to bude znamenat buďto zdražení her nebo omezení konkurence (aby se jedné hry prodalo víc kusů). Už teďka směřuje hratelnost her do kytek právě kvůli tomu, že všechny peníze se dávají do komerčních slátanin bez nápadu. Hlavně když se toho prodá několik vlaků.
Tak a teď se podívej, kolik lidí fotí do RAWu - z kompaktů jich to umí minimum. A Photoshop moc multithreaded friendly není, takže pokud nemáš RAW, dodatečný výkon z dual-core ti určitě žádný převratný výkon navíc nepřinese (určitě ne tolik, aby to stálo za tu vyšší cenu). Jistě, pokud sem budeme tahat záležitosti pro profíky, pro dual-core to vyzní dobře. Jenže realita je trochu jiná a BFU nemá moc důvod, proč platit vyšší cenu, když v jím dělané kompresi souborů to nic nepřinese, v jím vytvářených MP3kách to nic nepřinese, v jím hraných hrách to nic nepřinese... Pro BFU to má význam tak možná ve videu, jenže jak už tu zaznělo, XviD stále není multithreaded a budoucnost v podání algoritmu H.264 moc růžová taky není, protože multithreading na něm není možný bez ztráty kvality.
A kancelařina? Když už tam potřebuješ výkon, tak čistě single-threaded, protože Office až do verze 2003 včetně dual-core není schopen využít. Antivirus? To je sériová operace (např. scanování, pak teprve přístup k souboru). A ostatní věci v pohodě s nízkou prioritou na pozadí.
Eagle, tobe uz ta obhajoba leze tak na mozek, ze napadas i profesionalni aplikace, ktere DC dokazi alespon z casti vyuzit. (samozrejme nemluvim o fearu ;-) )
To neuznas vyhodu dual-core dokud druhe jadro neprinese presne 100% vykonu navic? I kdyz s tebou ve spouste veci souhlasim, tak myslim, ze svuj nazor dovadis az bych rekl do fanatismu.
O profi aplikacích přece všude tvrdím, že tam multithreading přítomen je... ale to už dlouho a ne kvůli dual-core, nýbrž kvůli víceprocesorovým strojů. Čili tam se s příchodem dual-core v podstatě nic moc nemění. Tyhle aplikace zákazník náležitě zaplatil. Osobně jsem ale docela zvědavý, jak moc rychle se budou vpřed posouvat aplikace jako Photoshop.
Pokud mi nějaká věc nepřinese vůbec žádný výkon navíc, pak za ní nehodlám dávat vůbec žádné peníze navíc. To je ten rozdíl - větší cache, vyšší frekvence mi vždycky něco přinesou. Další jádro mi ve spoustě situací nepřinese nic. Pokud nebudu mít skladbu aplikací takovou, že z toho budu mít užitek odpovídající vyšší ceně, pak si to jednoduše nekoupím. Nemusí to být 100 %, ale zohledňuju, že třeba v 90 % případů to nedá nic. Na Živě jsem v článku dělal porovnání z A64 3200+ na A64 3800+ vs A64 X2 3800+. Výsledek byl ten, že průměrný nárůst výkonu byl u 3800+ i X2 3800+ zhruba podobný (u 3800+ v téměř každé aplikaci o trochu, u X2 3800+ ve většině aplikací nic a v pár téměř 90 %), nicméně 3800+ bylo podstatně levnější, tedy pokud bych všechny ty aplikace používal zhruba stejně intenzivně, tak se X2 3800+ nevyplatí.
BTW, vcelku uvažuju o C2D, ale ne kvůli druhému jádru, ale kvůli velké rychlé cache a nízké spotřebě. To mi aktuálně jiný CPU nenabídne a se zrušením single-core Core 2 to ani nevypadá, že by mi v budoucnu nějaký CPU nabídnul. Tak až bude za ty tři tisíce a v nové revizi, asi do něj půjdu. A bohužel se asi neobejdu bez OC, protože jinak by mi to v porovnání se současným stavem nedalo prakticky žádný výkon navíc (vyjma přínosu velké cache).
Vsetci chapeme tvoje pohnutky, ze rozmyslas ekonomicky, ale nesnaz sa "zmenit svet" pretoze to nejde. Aj keby si dokazal prinutit celu CR a SR aby si nekupili dual-core. Myslis, ze vyrobcovia by ich prestali vyrabat a zacali by vyvijat tebou pozadovany vykon na jedno jadro? :roll: Raz to tak uz je, vyvoj urcuju vyrobcovia, tak sa s tym zmier, a ak sa s tym TY nechces zmierit, tak aspon nerozhadzuj rucickami naokolo. Myslienka, ze vyvoj urcuju odberatelia je velmi skreslena a utopisticka.
fox: v CS3 to tak nebude takze minimalne 1,5-2,0 rokov sa nic take nestane ... vyvojari tvrdia ze grafiky su pomale :) asi v nejakom ohlade alebo maju GMA900 vsetci ;)
A to si vážně myslíš, že víc jader bude mít využití? Myslíš si, že cesta nevede přes vyšší frekvenci a větší ILP ? Tak uvidíme, jak moc budou lidi kupovat osmijádra a podobné věci.
Já takový vývoj očekávám u videa. Grafická karta je několikanásobně rychlejší než CPU a pro kompresi / dekompresi videa se vysloveně hodí (SSE v procesoru nemůže konkurovat). Ale bude to trvat a musí být standard v programování, žádné ladění pro jednotlivý typ karty.
muj hodne laicky odhad je takovy, ze i kdyby ta akcelerace u statickyho obsahu byla jen ctvrtinova proti videu, je to porad slusnej boost proti CPU.
standard v programovani (nebo alespon jeho zaklad) doufam prinese nastupujici generace gpu.
mimochodem akcelerace adobe readeru pres gpu je docela znat ... problem je, ze je to desne buggy :-/
Nebo taky staci pouzivat vyladenejsi/lepsi aplikaci nez je Acrobat Reader ....
To je taky dost znat ....
Ja bych nerekl ze jen jistou davku, ja bych rekl ze to bude potrebovat masivni paralelizaci, protoze treba takova x1900 ma 36 resp. 48 shaderu a 8800 jich ma dokonce 96 ;)
A jak si myslis, Eagle, ze ty GPU dosahuji tak neporovnatelne vysokeho vykonu? Vysokou frekvenci? Nejlepsi GPU sucastnosti bezi na 500-600MHz, coz jiste vis...figl je v tom, ze ma 96 shaderu, takze se to tvari dost podobne jako 96 jader :) To je tedy odpoved na tvou otazku, zda bude mit vice jader vyuziti ;) Ja vim, ze to je urcene na neco jineho, nez bezne CPU, ale ta 8800 se CPUckam uz dost blizi, ze. To uz si patrne uvedomili lide v intelu a myslim ze se moc nespletu kdyz reknu ze ten jejich ultra moderni 90-ti jadrovy chip je dost opsany z GPU.
ad. 90tijadro ... v nasledujicich par letech to vazne bude umet vyuzit jen maloco/malokdo ... ja bych spis zkusil vratit k idee hyperthreadingu ... udelat jadro, ktery by obsahovalo dvojnasobek toho, co soucasny jedno jadro a mechanismus, kterej umi ty jednotky dynamicky pridelovat vice vlaknum ... pak by se mohly spojit vyhody obou pojeti ... ILP i TLP ... navic by se mohlo usetrit na tom, ze nekery jednotky nejsou tak moc vyuzivany, tak jich na obe jadra staci min, jiny by se naopak mohly na ukor toho znasobit ...
ale zase jen jeden ztrestenej napad ...
128 ;)Citace:
Původně odeslal Petrik
Imho sou tve predstavy trosku zkreslene - nemuzes porovnavat jednu shaderovaci jednotku s komplexnim CPU - shaderova jednotka umi par zakladnich operaci, srovnal bych ji spise s SSE jednoutkou CPU. Na CPU ti bezi proces nebo vlakno, CPU ma registry, zasobnik, program counter ......Citace:
Původně odeslal Petrik
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.'
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!
Znamena to snad, ze kdyz Lojza Z Nemanic hraje jen Accolade motorky, tak ze my ostatni nemuzeme vyuzit multithreading?
Kdysi se take rikalo, ze clovek nemuze letat....a dnes muze ;-)
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...navic bych se nedivil, kdyby ta aplikace, ve ktere dostal na frak, jela emulovane...
Ty proste stale nechapes jednu dost zasadni vec: Pro naprostou vetsinu realnych aplikaci je vykon stavajicich procesoru v pevne desetine carce dostatecny. Vyjimku tvori treba huffmanovy kompresni algoritmy, pak nejake hodne specialni aplikace a samozrejmne kompilace zdrojaku.... Naprosta vetsina aplikaci, ve kterych je zoufaly nedostatek vypocetniho vykonu, operuji s plovouci carkou a vetsinou vyuzivaji streaming vektorove instrukce typu SSE a pod. To je ruzna grafika, video, zvuky, fyzika a podobne veci. 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. V techto oblastech budou mit CPU typu Cell a GPU obecne velmi vysoky vykon. Ze je huffmanova komprese taktez paralelizovatelna ukazuje nejnovejsi winRAR (ja vim, ma o 0.001% horsi vysledek) a ze pri kompilaci lze vyuzit vice jader vi kazdy linuxar uz davno.
Predpokladam tedy, ze budouci procesory budou neco mezi dnesnimi CPU a GPU, tedy hybridni chip s nekolika beznymi procesorovymi jadry pro pevnou desetinou carku a k nim na spinavou praci v plovouci carce mnoho vysoce vykonnych SIMD mikrojader ala SPE v cellu ci unifikovany shader v GPU. Ze to neni jen nejaka moje halucinace ukazuje nejnovejsi projekt AMD v podobe APU jednotek ktere se chysta integrovat do svych novych CPU. Pravdepodobne take bude potreba aplikovat nejakou formu NUMA architektury, aby se zvetsila pametova propustnost pro jednotliva jadra. Zda to bude klasicka NUMA ci neco podobneho Cellu se uvidi. 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...
Jinak ti durazne doporucuji precist si toto: http://arstechnica.com/articles/paed...-multicore.ars
Decela me tam pobavila jedna vec. Vis jak porad tvrdis, ze si nedokazes predstavit MT kompilovani nebo ze to snad ani nejde?
For certain specialized tasks, such as compiling, fine-grained threading works really well. Valve has already implemented a system whereby every computer in their offices automatically acts as a compiler node. ;)
No vida, dokonce 128 :)
Myslim ze unifikovane shadery v 8800 toho uz umi ponekud vice nez SSE jednotka v CPU, ale ja jsem zduraznil, ze to neni totez jako CPU...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 :)
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.
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 formatuCitace:
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?
A protoze mpeg4 multithreadove nejde udelat uz nikdy nikdy nikdy nikdy nebude mozne multithreadove komprimovat video ... ale notak eagle ... ted uz ses fakt mimo ...
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?Citace:
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
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!
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...
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.
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 :D
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
A jaj, a jaj .... Nesmysl o linuxu nebudu komentovat. Vykon CPU je dostatecny, ale pouze na normalni operace, Chci-li komprimovat (zvuk/video) jsou soucasne procesory ZALOSTNE pomale ....
Az budu prevadet divx video o 100 minutach do 5 minut, MUZEME se bavit o tom, ze procesor je vykonny ... Do te doby to jsou pomale kramy ..
Aspon pro me
U prevodu do MP3 ten vykon jakz takz ujde ....
Ale mas pravdu, ze jestli mam Mplayer pod Duron 1G, nebo Conroe 5G tak je to jedno, hraje porad stejne ... (joke), ale treba v kancelari, taky neni velky rozdil mezi PC 2G Athlon a 4G Pentium, pricemz cena je jinde ...
Opakuji znovu, jedu Linux optimalizovany pro Intel (PC jede 24 hodin) a poridil jsem si procak o 50 procent lepsi nez ten minuly a zadny rozdil nepozoruju, tedy do doby, nez zadnu grabovat do MPEG2, MPEG4 a jeste pri tom, muzu psat do fora a aktualizovat system, ale to nedela kazdy a rozdil v cene je propastny ...
A jaj, asi jsi si vubec necetl, co jsem napsal. To je pak tezka debata. Ja psal, ze jejich vykon je dostatecny v PEVNE desetine carce, coz multimedia rozhodne nejsou...naopak jsem tvrdil, ze v plovouci jsou hodne pomale, cili o tom se bavit nemusime :)
Ohledne toho linuxu: linux JE na Cellu zatim opravdu zalostne pomaly, najdi si to na netu.
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.
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 ...
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 ....
Fakt? Ty jsi asi nikdy v LAME na vysokou kvalitu nekomprimoval, viď ?
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.
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.
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.
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.
Když chceš výkon ve float, tak proč C2D ? A64 má výrazně rychlejší FPU než C2D.
Na hry nepotřebuješ ani integer, ani float výkon, tam potřebuješ velkou rychlou cache a rychlý přístup do RAM.
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.
Ano. A já zas vím, že ve Visual Studiu 2005 to nefunguje.
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é".
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.
A víš proč? Protože je to pro úlohy jako OS a desktopové aplikace pomalý šunt.
Dyť je to jednoduchý. Nemáš MT aplikace => nekupuj si DC. Máš MT aplikace a potřebuješ výkon => kup si dvousocket. Takhle to fungovalo 10 let a bylo to logické. Cena za dvousocket není zas o tolik vyšší než u jednosocketu a výkon to ve specializovaných úlohách přinese. Tahle nebude nutné snižovat frekvence, a tudíž běžnému uživateli to přinese hodně, a i ten, který potřebuje MT výkon, si přijde na své.
Jistě budeš argumentovat cenou, ale můžu tě ubezpečit, že ono to vyrobení DC není zas o tolik levnější než vyrobení dvou SC. Deska o něco dražší je, ale výrobně to taky není přehnané. To je holt politika výrobců CPU, že za to kdysi účtovali těžké peníze a teď, když jim teče do bot, byli schopni tuhle dojnou krávu potopit, aby vůbec měli typickým zákazníkům co nakecat.
http://www.svethardware.cz/art_doc-8...30074F8B8.html
Sice jenom koncept, ale asi se té zrůdnosti dožiju ;).
No prave vdaka tej priorite operatorov mozes matematicke vypocty dobre paralelizovat. A dokonca aj jedno samotne nasobenie ide velmi dobre paralelizovat.
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...Citace:
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.
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....Citace:
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.
Navyse, ak robis beton, tak tam ti tych 20 pytlu s cementem prijde celkem vhod :wink:
ale ved predsa tu stale opakujes ako najpouzivanejsie kodeky nejdu paralelizovat....Citace:
GPU ho doplňovat při paralelizaci těch několika málo úloh, které se paralelně dají napsat (např. video).
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.
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.
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 agrumentCitace:
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).
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.
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.Citace:
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.
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...)
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.Citace:
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.
no a preto si tiez kupuju tie dc pocitace...
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.Citace:
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?
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?Citace:
Integrace CPU a grafické karty se u AMD plánuje pro notebooky, kde to uspoří elektřinu.
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?
Rychlé = rychlejší než člověk. Do té doby je to pomalé.
Priorita operátorů určuje jasný sled operací. Stejně tak řádky v programu určují jasný sled. Dělat v matice víc věcí vedle sebe jde jen někdy, stejně tak v tom programu.
To čistě jen teoreticky. V praxi v žádném případě. Důvod je ten, že out-of-order má latenci mezi jednotlivými paralelními částmi prakticky nula, zatímco latence mezi více jádry je značná a vždycky bude značná (už z důvodu fyzické vzdálenosti transistorů).
Když budu mít příklad
a = 1 + 5
b = 4 - 2
c = a / b
Tak v out-of-order to zabere dva cykly. V multicore bude výpočet trvat taky dva cykly, ale další minimálně desítky bude trvat, než přemístíš data.
1) V PC nelze přizpůsobovat programy procesoru - to je daň za modularitu.
2) To, co říkáš, je možné jen na úrovni fyzicky blízkých zařízení, což multicore v žádném případě není. Je to snesitelné u jednotlivých výpočetních jednotek. Touhle cestou jde např. Itanium a tam to má výsledky. Jenže chce to velkou cache (kód je víc komplexní) a nesmí se měnit architektura CPU - proto už je tolik let Itanium 2 v jádru stejné (ani Intel si nedovolí přeuspořádat mu jednotky, protože by to znamenalo nutnost rekompilace programů, tj. dodatečné náklady).
Nepochopil jsi to - tady je limitem to, jak rychle mícháš. Celá tvorba betonu stojí a padá s touhle operací, kterou nemůžeš dělat paralelně. To, že budeš mít deset rukou a naházíš tam cement, písek, štěrk i vodu najednou, ještě neznamená, že nějak zrychlíš proces míchání. A to je právě ta věc - musel bys mít míchačku, která míchá rychleji (teď předpokládám, že ti stačí jedna míchačka betonu, ne že toho chceš celý mix).
Upřímně v GPU se příliš nevyznám. Pokud se ale chovají jako SIMD procesory (což se všude tvrdí), tak tam může být paralelizace v rámci ILP. SIMD v CPU je taky ILP. Problém multicore je v tom, že kdyby se měl kód paralelizovat na jednotlivých instrukcích, jako se to dělá u SIMD, bude procesor celou dobu jen čekat na synchronizaci dat z threadů.
Hybridní disk ti přece nikdy nemůže nahradit rychlou mechaniku. Může leda tak doplnit spekulaci s DRAM bufferem. Čtení ti ale nijak neurychlí.
Pokud budeš uvažovat uživatele, kteří výkon nepotřebují, tak těm bude stačit i ten nejlevnější procesor (nedávno tuším nějaký Celeron za 1300 Kč s DPH). A BTW, jsem to já, kdo těmhle lidem tvrdí, že si musí nutně pořídit dual-core, aby jim ty jejich nenáročné aplikace běhaly dostatečně rychle? "Dual-core: Do More", že? Stejně jako ta sestava z ATčka, kde bylo C2D a k tomu 512MB RAMky a říkali, jak je to na kancl neuvěřitelně rychlý (pro zajímavost - na kancl využiju 1 GB RAM i já, stačí větší soubor v Excelu a už se to veze).
Pak je to věc názoru. Já si docela všímám, co lidi používají.
Je... a neposkytuje identické výsledky. A taky měl v té paralelizaci bug způsobující poškození dat. Také přináší opravdu výrazné zvýšení rychlosti (za tu dodatečnou cenu za dual-core super, že?).
Pokud máš hash na celý soubor, tak o tom vcelku pochybuju.
Jenže to zdržuje. Když mám šifrovaný celý disk (v podnikové sféře v lepších firmách vcelku standard), tak při přístupu k souboru potřebuju:
1) Načíst soubor (to trvá a nelze zrychlit).
2) Dešifrovat obsah.
3) Scanovat realtime antivirem.
4) Spustit kód.
Operace 2, 3 a 4 je možné zrychlit. Jenže se v případě operací 2 a 3 jedná o čistě sériové operace, na něž je dual-core k ničemu. Jakékoli zrychlení je tady vítáno.
Nejlepší hláška tohoto threadu. Takže mi chceš tvrdit, že když v Civilization III trvá s rozlehlou mapou jeden jediný turn počítače 5 minut, když se přepočítávají trasy pohybů (např. postavíš letiště) kolem třiceti vteřin (tj. klik, čekáš 30 sekund, pak další klik, mezi tím nemůžeš nic dělat), když načtení savu trvá asi tak tři minuty, že výkon nepotřebuju? To si asi děláš srandu.
Stejně tak starší gamesy s renderingem prováděným CPU se v případě vysokého rozlišení moc nehýbou.
Nadhodil jsem tady, proč si myslím, že to paralelně udělat nejde. Nikdo z vás mi tuhle domněnku nebyl schopen vyvrátit. Naopak jste jí dokonce uznali. A rozhodně to není čisté, vliv se ztratí až při vysokém fps. Pokud ale počet fps z nějakého důvodu klesne (např. kvůli grafice), začne být vidět, jak se ovládání zpožďuje.
Tak zrovna Quake 4 jeví na dual-core určité neduhy, které se na single-core nestávají. Jedná se o různé formy zasekávání v místech, kde single-core jede OK.
Bohužel je to tak.
Kdyby tady byl velký hlad po 5.1 zvuku v oblasti hudby, tak se to dávno prosadí. Tuším že právě DVD Audio tohle nabízí (společně s 96 kHz). A prosadilo se? Ani se mi nezdá. Hodně profi zvukových zařízení je taky stále jen stereo (např. věhlasné Nautily).
U nevýkonových záležitostí je majoritní leakage, protože dynamická spotřeba se moc nekoná. To je i případ síťové karty (většinu času tráví v idle). Menší transistory obecně mají vyšší leakage, a proto se u síťovky nemusí vyplatit dělat jí na menším procesu. Pokud vím, tak jsem nikde netvrdil, že dělat síťovku novou technologií je nutně špatně, jen jsem říkal, že leakage se může stát významných faktorem hrajícím proti. Pokud to zvládnou i novějším procesem, může to být. Obvykle se i dělají pro velikost transistorů dva výrobní procesy - jeden na low-power a druhý na performance. Ale jak si vede ten low-power ve srovnání se starší generací, netuším.
Grafická karta je využívána vždy, dynamická spotřeba tam hraje větší roli (obraz se prostě kreslí pořád). Čili když menším transistorem snížíš dynamickou spotřebu, pořád se to může vyplatit. Hlavní záměř AMD ale IMHO je v tom, že jim to umožní lépe sladit power management CPU, GPU a řadiče pamětí. Když všechno bude na jednom kusu křemíku, bude si to schopné předávat informace o zatížení, optimalizovat přístupy do RAM atd. U čipsetů a dodatečných řadičů se bohužel nějaký power management moc neděje a asi se nedá čekat, že se k tomu odhodlají, dokud to nebude vysloveně nutné (power management = další logika = vyšší výrobní cena).
Mě by spíš zajímalo, proč se v diskuzi o dual-core vede anketa o C2D. Spíš by se sem hodila anketa typu
"Majorita mnou používaných programů je:
single-threaded
multi-threaded s nárůstem výkonu do 20 %
multi-threaded s nárůstem výkonu od 21 do 59 %
multi-threaded s nárůstem výkonu nad 60 %"
Popřípadě anketa:
"Máte nebo nemáte zkušenosti s programováním a co si myslíte o dostupnosti dobře paralelizovatelných multithreaded programů s vysokým nárůstem výkonu?
Mám zkušenosti, MT programy budou za dlouho
Mám zkušenosti, MT programy budou brzo
Nemám zkušenosti, MT programy budou za dlouho
Nemám zkušenosti, MT programy budou brzo"
U té ankety, co je tady teď, bych se i vcelku vsadil, že většina uživatelů, kteří ho tak chválí, by ho chválila i v situaci, kdy by byl jednojádrový.
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.
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.Citace:
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).
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.Citace:
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 zase ti zrychli vo vacsine pripadov pristupovu dobu a to velmi vyrazne... Rychlost lin. citania je obmedzujucia iba vo velmi malo pripadoch.Citace:
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í.
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...Citace:
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?).
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).
tu ta aj tak brzdi disk, takze ti to je jedno a nemusis urychlovat vypocet toho hashuCitace:
Pokud máš hash na celý soubor, tak o tom vcelku pochybuju.
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...Citace:
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.
no neviem si potom predstavit, ako to mohlo ist na doporucanom p2 500mhz, ked na 2ghz athlone ti to ide tak pomaly...Citace:
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.
Skratka, stare hry si zahras minimalne tak dobre, ako by si mohol v dobe ich vydania.
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)Citace:
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.
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...).Citace:
Grafická karta je využívána vždy, dynamická spotřeba tam hraje větší roli (obraz se prostě kreslí pořád). Čili když menším transistorem snížíš dynamickou spotřebu, pořád se to může vyplatit. Hlavní záměř AMD ale IMHO je v tom, že jim to umožní lépe sladit power management CPU, GPU a řadiče pamětí. Když všechno bude na jednom kusu křemíku, bude si to schopné předávat informace o zatížení, optimalizovat přístupy do RAM atd. U čipsetů a dodatečných řadičů se bohužel nějaký power management moc neděje a asi se nedá čekat, že se k tomu odhodlají, dokud to nebude vysloveně nutné (power management = další logika = vyšší výrobní cena).
Mě by spíš zajímalo, proč se v diskuzi o dual-core vede debata o cenach procesorov.Citace:
Mě by spíš zajímalo, proč se v diskuzi o dual-core vede anketa o C2D.
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.
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.
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.
Jak jí může zrychlit? Když mám random access, co mi zaručí, že mnou požadovaná data budou ve flashce ?
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.
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ě).
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.
Viz níže - pokud chceš, aby to bylo realtime, tak musíš.
To nejde minimálně z toho důvodu, že antivirus bere soubory jako celek.
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á.
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.
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.
O vykreslení se dneska stará grafická karta, takže kde je ten efekt?
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.
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č?
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...
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.Citace:
Jak jí může zrychlit? Když mám random access, co mi zaručí, že mnou požadovaná data budou ve flashce ?
problem je v tom, ze tu stale opakujes, aky je E6300 absolutne zly a blby procesor, iba koli tomu, ze je drahsi ako AMDCitace:
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?
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".Citace:
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.
To si nemyslim, preco by ich mal brat ako celok? Co brani antiviru spracovavat subor hned po otvoreni?Citace:
To nejde minimálně z toho důvodu, že antivirus bere soubory jako celek.
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.Citace:
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á.
no ak chces nacitat dalsi subor, tak sa deje presne to iste znova - nacitanie, dekryptovanie a AV kontrola, nevidim v tom ziaden rozdiel.Citace:
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.
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.Citace:
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.
ten efekt by mal byt v tom vsetkom, co predchadza vykresleniu kazdeho framuCitace:
O vykreslení se dneska stará grafická karta, takže kde je ten efekt?
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 konstrukciiCitace:
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č?
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)
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 ...
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í.
Takže souhlasíš s tím, že nezrychlí (resp. že zrychlí jen tehdy, když se povede spekulace).
Ano, je nevýhodný.
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í.
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.
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.
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.
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.
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.
Takže např. v sériové fyzice?
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á?
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 ...
Podle Eagla si zasifrovany 2GB soubor na kompu s 1GB RAM nejenom neotevru, ale ani neoscanuju antivirem. ;) S tim odposlouchanim 1/10 sifrovane komunikace a nasledneho dekodovani jsem to tedy nejak nepochopil, ale to bude asi tim, ze mam tu snizenou inteligenci. Ja myslim ze sifrovancimu algoritmu je uplne sumak, zda sifruje telnet komunikaci, komunikaci po nejakem portu, stremovanou hudbu ci nejaky soubor...
Ocividne stale odmitas precist si ten clanek o valve engine, tak alespon uryvek, abys tu porad nepsal, ze to nejde:
http://arstechnica.com/articles/paed...ulticore.ars/1
Almost all game programming, from the simplest BASIC game all the way up to Half Life 2, uses a main game loop from which all events are calculated. The drawing portion of the main loop used in Valve's games broke down roughly as follows:
1. Build world lists (background, scenery, etc.)
2. Build object lists (players, nonplayer characters, items)
3. Graphical simulation (particles, ropes, sprites)
4. Update animations (such as skeletal animation used for character movement)
5. Compute shadows
6. Draw (send display commands to the graphics card)
This list had to be executed once for every "view" currently visible in the game: once for the player's own point of view, and again for every water reflection or displays on in-game TV monitors.
The new pipeline was rearranged as follows:
1. Construct scene rendering lists for multiple scenes in parallel (world, water reflections, and TV monitors)
2. Overlap graphics simulations
3. Compute character skeletal transformations for all characters in all scenes in parallel
4. Compute shadows for all characters in parallel
5. Allow multiple threads to draw in parallel (this required a rewrite of the graphics libraries that live directly above Direct3D)
The new pipeline featured so much multithreading that special efforts were needed to avoid the dreaded deadlocks and other pitfalls mentioned earlier. To accomplish this, programmer Leonard made use of a technique called lock-free algorithms. He implemented a spin lock to replace the more traditional mutexes (mutual-exclusion algorithms) and semaphores that are used to flag threads as being "safe" to multithread. The spin loop utilizes a new interlock instruction that is built into the CPU. However, there were still too many deadlocks. Tom examined the threads' activity with profiling tools, and it turned out that 95 percent of the time the threads were reading memory while only spending 5 percent of their time writing. A read/write lock allowed many threads to read the same bit of memory, but only one thread to write to it.
Zaver:
The end results of Valve's efforts were even better than they had initially hoped. Not only was the speedup on the four-core Kentsfield chips nearly linear in most cases (an average of 3.2 times over a single core) but having four CPUs instead of two made it possible to do things that simply couldn't be done with fewer cores.
Porad si myslis, Svaco, ze AMD neudela QC do destopu? Jinak treba tebou vzpominany virtualdub JE MT.
mas pravdu. nevyznas. tak prosim nevynasej soudy.
konkretne AES ma specifikovanej blok jako 128 bitu.
ostatne kdyby to tak nebylo, tak mi prosimte vysvetli, jak to, ze mam 4TB device, kterej je celej na nejnizsi urovni (tj. na disku neni nic jinyho, nez ty sifrovany data - zadny hlavicky, zadnej filesystem, nic - filesystem je vytvorenej az nad tou sifrovanou vrstvou) sifrovanej prave tim AESem a muzu z toho cist nahodny casti. na zacatku, na konci, uprostred se access time lisi max v radech ms.
a jeste bych rad upozornil, ze ten stroj ma 512MB (mozna kecam a je to 768MB) RAM ...
OK, to se dá pak chápat. Existuje už na to optimalizovaný software? Neměl by to asi být problém.
BTW, jak se bude tohle řešit u takových těch softů, které šifrují disk ještě před OS ? V práci to máme tak, že ihned po spuštění počítače naběhne šifrovací software, vyžádá si heslo a až pak začne bootovat.
Program se natahuje až po BIOSu (napřed se objeví klasický POST screen logo) a jeho rozhraní je typicky wokňousí (okénko s text boxem a lá Win2K). A než zadám login, nezačne to ani bootovat. Přitom to hodně dlouho hrabe na disk. Že by byl integrovaný do BIOSu, tak to si nemyslím - před loginem se snaží tahat aktualizaci přístupových práv ze sítě. To už by i s tou grafikou bylo vcelku komplexní. Zřejmě to bude pracovat na nižší úrovni než OS.
dobra. mas software, kterej bezi v realnym modu, zpristupni ti disk (treba onen BIOS, nebo co si matne vzpominam, tak byly utility, ktery se strkaly do bootsectoru a zpristupnovaly >8GB resp >32GB disky u biosu, ktery to neumely). OS si nacte ovladace, (mozna mezitim switchne do protected modu), pusti ovladac a pristupuje na disk uz primo, bez onoho software ...
rozhodne k tomu nepouziva ani bios, ani ten soft z bootsectoru.