65nm AMD - vysoká latence

[Eagle]

I v základu je to slušně rychlej CPU.

V základu má ten procesor výkon podobný nejrychlejším K7 (plus cca nula až dvacet procent dle aplikace). A to je hodně slabé na to, kolik stojí a o kolik let je novější.

Nesouhlas, ačkoliv nevim moc o problémech PentiaM a Core duo, protže je to evidentně niak moc nepoznamenalo ve finální funkčnosti,

Já bych si třeba P-M do notebooku nekoupil právě proto, že není kompatibilní s 64bit programy. Na moderní CPU dost závada.

kdežto problémovej přechod Prescotta na 90nm je doslova legendární.

IMHO problém nebyl způsoben Prescottem, ale výrobní technologií. Dothan má taky leakage dvojnásobný proti Baniasu.

A výhoda 64bit. Nuo to je fakt výhoda, jak dlouho tu 64bit je a kdo to využije 0.001% uživatelů. Budoucnost to má až.........

Mno... 64bit má jen výhody, žádná negativa (z pohledu SW). A jelikož předělat program na 64bit je většinou jen otázkou rekompilace (tj. zabere pár minut), tak to považuju za mnohem méně náročný přechod, než ten na dual-core.

Dothan a Core Duo je beztak lepší CPU

To si nemyslím. Jsou lepší na průměrné appz, ale jejich hrubý výpočetní výkon je mnohem slabší než u P4.

Neudělal by tehdy Intel náhodou lépe, kdyby místo drahýho vývoje tohodle krámu udělal jen die-shrink Northwooda a svim skvělym marketingem roznesl 64bit podporu AMD jakožto něco v dohledný době nevyužitelnýho? Asi ano.

Rozhodně ne. A to sice z toho důvodu, že už takhle Intel s 64bit zaspal. Všechny vývojové nástroje používají termín "AMD64", AMDčku se podařilo přemluvit Microsoft a zajistit podporu v Linuxech. Intel musel urychleně s něčím přijít, jinak by AMD získalo na 64bit totální monopol a dost dobrou publicitu. Nehledě na to, že vysoce výkonný Opteron v serverech s víc jak 4 GB RAM byla pro Intel obrovská konkurence, kterou nemohl nechat bez odezvy.

Nevim proč bys ho tam neřadil, i dle kódování Intelu je to P6 family. A ty bugy? Nic kritickýho neni. Možná horší ALU v 64bitech.

Zásadní problém toho CPU je v tom, že má pět měsíců po uvedení oznámeno už 90 bugů. Tolik jich v první P4ce našli až za pět let. Vývoj byl evidentně urychlený.

P-M je na stejné frekvenci rychlejší jak K8 a to znatelně a v hrách nejvíc.

Výkon ve hrách je otázkou cache, ne rychlosti CPU jako takového.

Čili K8 vyhrála jen v syntetickejch testech, jinak na chlup vyrovnaný a naprosto propadla v herních testech, čili Dothan je lepší jak K8 a Core Duo (Yonah) radši vůbec nehodnotim, udělal by sis tim výrokem ostudu.

No a teď ti zase řeknu mojí zkušenost - Distributed.net client, šifra RC5-72bit. Výsledky v porovnání s K7:

K7 na 2200 MHz - 8 443 952 keys/sec
Pentium M na 2400 MHz - 6,100,555 keys/sec

Čili i s o 200 MHz nižší frekvencí má K7 (v postatě stejné jádro jako K8 o 38 % vyšší výkon. Tahle aplikace je intenzivní celočíselná, s velkým paralelismem, vejde se do L1 cache a je optimalizovaná. A porovnání výkonu P-M vs. K8 v FPU je snad jasné předem - K8 má mnohem silnější jednotky. Tady vidíš, jak je P-M pro intenzivní výpočty využívající vysokého paralelismu beznadějné.

V tom tvém testu to máš ostatně potvrzeno - http://www.tomshardware.com/2005/05/...st/page14.html
Výkon P-M je vyjma paměťově (= na cache) náročných aplikací nanejvýš stejně dobrý jako K8 na stejné frekvenci. V optimalizovaných aplikacích nemá šanci. A K8 má navíc vyšší frekvenci než P-M a to o dost.

Je mi líto, ale optymalizace aplikací pro CPU je kor v dnešní době utopie... Vítězí ten CPU, který předvede nejlepší výkon v neoptymalizovaném kódu. Kdyby se optimalizovalo,

Utopie to je jak kde. Stále existují určité typy programů, kde je výkonu nedostatek, a tyto se optimalizují. Týká se to zejména workstation oblasti. A tam si P-M příliš neškrtá.

Netburst by nepropadl (tam kde to ještě jde, jako komprese, kódování atd. také nepropadl).

Netburst propadl kvůli vysoké instrukční latenci a nedotažené paralelizaci. Některé úlohy mohl dohnat vyšší frekvencí, ale zdaleka ne všechny. V principu ale systém vysoké frekvence není špatný a pokud se ho podaří aplikovat s přijatelnou spotřebou (i za cenu zjednodušení paralelizace), vede k vysokým výkonům ve všech aplikacích.

Jestli se bude na něco optymalizovat, tak to bude za účelem využití multicore CPU a rozdělení výkonu do více threadů, ne do toho co si ty představuješ.

Optimalizovat na multicore je podstatně dražší než optimalizovat na ILP. A to sice proto, že na ILP ti obvykle stačí jen použít dobrý kompilátor, zapnout v něm optimalizace a pak si chvíli hrát s profilovačem. Nárůsty výkonu bývají v některých případech neskutečné (skoky obecně zaberou moc času).

Hmm, a právě proto, že se to projeví jen ve specifických úlohách, tak právě proto byl Gallatin vždy znatelně rychlejší, jak NW. Takže to řekneme lépe - tohle konkrétně pomohlo vždy a v těch specifických aplikacích opravdu hodně.

Tak se podívej na mnou provedené testy, kde porovnávám Semprony se 128 a 256 kB, A64 s 512 kB a Opteron s 1024 kB L2 cache - http://www.svethardware.cz/art_doc-6...9003E9F57.html. Rozdíly výkonu až na některé aplikace nijak převratné nejsou.

Jo a prosimtě, nerozváděj tady takovou diskuzi jako v threadu "Vyznam dual Core" já tu s tvojí věčnou pravdou soupeřit nebudu. (Ano v něčem máš pravdu, ale ženeš to do extrémů).

Tady sis IMHO hodně naběhl, nemám problém ti dokázat, že P-M není tak rychlý jako K8. Takže pokud "si chceš udělat ostudu", není problém.

Porad tady mluvis jen o cache, ale vysvetli mi jednu vec: pokud program (rikejme mu proces) pracuje s daty typicky o velikosti max. 512kB, jedna se o jediny proces. V modernim OS ale bezi velka kopa procesu...

To máš pravdu, v multitaskingu větší cache často pomáhá hodně. Záleží přirozeně na tom, jaký konkrétní mix aplikací používáš. Pokud budeš mít dvě takové, které se vejdou (obě) do L2 nebo z nichž jedna (nebo obě) jsou streamového charakteru, tak je ti další cache na nic. Ale typická aplikace z toho profituje poměrně dost. Ukázkový příklad je třeba HDTV dekódování ve WMV9 a ještě něco k tomu. Mohli bychom se samozřejmě bavit, kolik uživatelů provádí intenzivní multitasking a kolik je jich spíš závislých na výkonu jedné konkrétní aplikace (IMHO víc toho druhého), ale to už by zase byla diskuze a lá ta o dual-core.

Nebo je to snad uloha memory prefetch, aby vzdy pri prepinani aktivniho procesu nacetl pozadovany blok dat z RAM (proces swapovani mezi cache a RAM)?

Fetch dat probíhá on-demand, ne spekulativně podle aktivního procesu (ten dokonce CPU ani nezná).

pri typickem desktopovem vyuziti pak souhlasim s narustem vykonu u C2D pri rozdilu 2MB vs. 4MB cache.

IMHO už takový rozdíl při těchto velikostech cache není, protože tam už se ti vejde víc aplikací vcelku v pohodě. 2MB verze trpí tím, že má poloviční asociativitu - Intel prostě půlku cache vypnul, aniž by tu druhou jakkoli upravil. Proto má obecně nižší výkon.

Pokud cache je jeden z bottlenecku, bude to pri nekterych aplikacich citit u 65nm AMD celkem znatelne (at uz je to problem rychlosti, latenci nebo velikosti).

To je pravda. Viz http://www.zive.cz/h/Testcentrum/Ar....D=4&EXPS=&EXPA= a testy X2 3600+. V některých programech cache cítit je a pokud jí budeš mít sdílenou mezi víc procesů, pochopitelně to může dopadnout podobně jako mezi X2 3600+ a X2 3800+.