neharagudj, de szerintem az nem túl nagy elvárás egy 4magos procitól, hogy nagyobb legyen a számítási kapacitása egy 2magosnál. No mind1, asszem inkább iszok napi egy pohár jodi ásványvizet...

Esetleg AMD fan.

neharagudj, de szerintem az nem túl nagy elvárás egy 4magos procitól, hogy nagyobb legyen a számítási kapacitása egy 2magosnál.

Nem haragszom. De nekem még mindig úgy tűnik hogy nagyobb is...

Az overclockers szállíttat külföldre. Ráadásul van raktáron 9500-as.

szerk.: A 64-bites tesztre érdemes lenne kipróbálni a 7-zip tömörítőt.
Az x64-es változata valóban 64 bites kódot használ. [link]

[ Szerkesztve ]

Nem tervezünk 64 bites tesztelést.

"I press keys on a keyboard all day and click a mouse in front of a glowing rectangle. Somehow that turns into food and shelter."

Megkérdezhetem hogy miért nem tervezitek?
Vagy esetleg meglehet győzni benneteket?

Nem magam miatt szeretném hogy legyen 64 bites teszt. Ha meglesz a Phenom-om, akkor úgyis letesztelem a saját kódjaimmal...

Viszont a 64 bites Vista terjedőben van. A programfejlesztők is már kijöttek a natív 64 bites támogatással ( játékok: HL2, FarCry, WoW, UT2004, Colin McRae 2005, ... ) ami azt jelenti hogy kezdik kiismerni. Szinte biztos hogy rövidesen berobbanak a 64 bites programok. Ha pl. valaki mostanában fektet 2-3 évre egy processzorba akkor nem árt tudni hogy az AMD megoldása milyen erőt képvisel az Intellel szemben...

mert a 32 bites tesztrendszerek kialakítása is qrvasok idő és pénz, nincs 2szer annyi időnk és pénzünk, ilyen egyszerű.
másrészt a juzerek szempontjából a 64 bit még irreleváns, sztem átlagfelhasználóknál nem is nagyon fog elterjedni,

[ Szerkesztve ]

"I press keys on a keyboard all day and click a mouse in front of a glowing rectangle. Somehow that turns into food and shelter."

"Azon meg hogy az AMD most nem tudja tartani a lépést az Intellel, nincs mit csodálkozni. Az Intel jóval több erőforrással rendelkezik..."

Szerintem nem csak erről van szó. Maga az Intel sem volt képes tartani a lépést önmagával. A netburst vonal mehetett volna még tovább is, 4 magon 45 nanométeren, de akkor bukták volna a versenyt a K10-el szemben. Tehát egyszerűen belátták, hogy még az ő erőforrásaik mellett, sem lehet egy alapvetően elhibázott, illetve csak relatíve gyenge processzorból ütős cuccot csinálni, ezért kidobták az egészet. A szerencséjük a mobil pentium vonal volt, ami véletlenül enyhén jobban sikerült, a netburst-nél. Gyakorlatilag házon belül kaptak ki önmaguktól. Persze ez is erőforrás kérdés, mert megengedhetnek maguknak, a több párhuzamos projektet egyszerre, pl. az Itanium is, de a lényeg az, hogy egy futó proci vonal áttervezés valószínüleg nem erőforrás függő, hanem irdatlan idő kell hozzá, amit "mi" (ill. a piac) nem szeretünk kivárni. Az AMD gyak a netburst vonallal szembeni cuccát túrbozta fel a Phenommal, sok jó ficsőr, de benne vannak a legelső XP fogyatékosságai is, pl. ha jól látom integer vonalon elsősorban. Ezzel együtt nagyon szép teljesítményt hoz, sőt tulajdonképpen már az X2 is elég jó, más kérdés, hogy a C2 meg hatalmas ugrás előre, de aligha hiszem, hogy a következő években az Intel tudna újra ekkorát újjítani. Ahhoz megint át kéne tervezzék a régi architektúrát, az pedig idő. A megahertz növekedéssel én szkeptikus volnék, már a P4-eknél is az voltam a 10Ghz-es marketing szövegekkel szemben. Nem tudom miért, de nehezen hiszem el, hogy ez olyan egyszerű lenne.

Ha a másik felét nézem, vagyis nem a megahertz növekedés irányát, akkor marad a multiprocesszoros útvonal. 8-16-24-32 stb. Ez sem egyszerű, de ezen az úton mintha az AMD járna elöbbre.

Érthető. Erre nem gondoltam...

"640kB mindenre elég..."

"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." (Albert Einstein)

"- Az Intel 45nm-es gyártástechnológiára képes waffert, SRAM chipekkel 2006 januárjában mutatta be, ugyanezt az AMD 2007 májusában demonstrálta vagyis 16 hónappal később."
Az Intel akkor még csak egy teszt-wafert mutatott be, nem demonstrálta, hogy működik is.

"- A 45 nm-es Penryn tape-outja 2007 januárjában van, vagy 1 évvel az első működőképes waffer bemutatása után"
Ez nem jelenti azt, hogy minimum egy évnek kell eltellnie a kettő között. Egyszerűen akkor készült el a Penryn.

"AMD-nél is nagy valószínűséggel inkább csak ez várható 2008Q1-ben, nem pedig a tömeggyártás."
Szerintem senki sem mondta, hogy ekkor már a tömeggyártás indul.

"- A 45 nm-es Penryn tömeggyártásban 2007 novemberében és 2008 januárjában kerül a polcokra vagyis 2 évvel az első 45 nm-es waffer, és 1 évvel a tape out után."
1. A tape-out lehetett volna előbb is.
2. Az Intel bőven hagyott időt magának a rampingra (nem hajtotta a tatár), lásd 3 GHz-es launch órajel, stb.

"45 nm-es K10-es tape outról még nem voltak hírek, csak az általad is említett linken utalás arról hogy folyik a procik próbagyártása."
Ha valóban folyik a procik próbagyártása, az azt jelenti, már volt tape-out, hiszen éppen azt próbálják meg működőképesen legyártani.

"de feltételezzük hogy még úgy van, akkor is a tömeggyártásig még legalább lenne 1 év"
~1 év a kihozatal és minőség viszonylag magas szintre fejlesztéséhez kell. Ha sietni kell, már előbb elkezdhetik gyártani kisebb mennyiségben.

"- 2006 november tömeggyártásban elérhetővé válik az Intel első 4 magos procija"
2x2 magos.

"- 2006 december K10 tape-out, konkrét órajelről nincs hír, de fórumokban lehetett olvasgatni 800 Mhz-en ketyegő példányokról."
Tudtommal 2006 novemberében már zárt ajtók mögött néhány partnerüknek élőben demonstrálták.

"- 2007 május az AMD ominózus prezentációja kikerül amiben a elméleti 2.6 Ghz-es Barcelonát összeveti a 2.66 Ghz-es C2Q-dal. Viszont trükköznek mert a C2Q-hoz olyan eredmény választanak amiből a publikálás idején már van frissebb, de ők szándékosan egy régebbi mérést választank és így papíron a Barcelona 2.66 Ghz jobb"
Tévedés!!! Ezek a grafikonok még a 2006 novemberi prezentációról származtak.

"-2007 július, az AMD újra publikálja a korábbi prezentációját, ráadásul most már széles körben a weboldalán. Továbbra is az ezer éves Intel adatokkal, holott közben már kijött hivatalosan is a 3 Ghz-es C2Q. Az Intel most már beszól hogy használja a jó adatokat. Persze azok mellett már nem lenne gyorsabb az elméleti 2.6 Ghz-es Barcelona ami illuzió romboló lenne, ezért inkább eltávolítja az egész prezentáció az oldaláról az AMD."
Ez sem pont így volt. Ekkor újabb grafikonokat prezentáltak, amikben a 2-magos Opteronokkal hasonlították össze. Az Inteles grafikonokat csak nem frissítették az oldalukon. (Az Intel site-ja is tele van out-dated grafikonokkal, talán naponta frissítenk kellene az összeset?) Az egészből egy Chen nevű seggfej csinált botrányt, aki mindezt nem tudta (mert nem tud semmit), és azt hitte, azok is újak. Mellesleg csalt is a saját kis összehasonlításában, mert az egy jóval korábbi compilerrel kapott Barcelona számokat egy vadi új, jelentős fejlesztésen átesett compilerrel kapott Xeon számokkal hasonlítgatta. SIMD FP teljesítményben igenis veri a K10 a Core-t.

"-2007 augusztus, mindenféle rejtélyes 3 Ghz-es K10 demonstrációkról érkezik hír, felcsillan a remény hogy jön majd a kóró gyilkos"
Nincs itt semmi rejtélyes, több újságíró megnézhette közelebbről, CPU-Z-t is futtattak.

Végülis leírtad hogy az Intel azért tudott előrukkolni a Core2-vel mert voltak hozzá erőforrásai.

"a lényeg az, hogy egy futó proci vonal áttervezés valószínüleg nem erőforrás függő, hanem irdatlan idő kell hozzá, amit "mi" (ill. a piac) nem szeretünk kivárni"

Ez a mondat így elég ellentétes. Ugyanis az időt csak úgy tudod csökkenteni ha hatalmas erőforrásokat fektetsz a projektbe. Gyakorlatilag több, jobb munkaerőt alkalmazol. Akár hiszed, akár nem, ezeknek az embereknek a bére az ami az egyik legnagyobb kiadás.

Tudom, jól. Pl. jómagam ipari célgépek fejlesztéssel foglalkozom. Általában a munkabér teszi ki az összköltség 40-50%-át. Sokszor (mindig) belefutunk a tarthatalan határidőkbe és az sem ritka hogy anyagilag jelentős buktával zárul a dolog. Persze ha az ember jól kalkulált és szerencsés akkor többször jár ugyanennyire jól...

"A megahertz növekedéssel én szkeptikus volnék, már a P4-eknél is az voltam a 10Ghz-es marketing szövegekkel szemben. Nem tudom miért, de nehezen hiszem el, hogy ez olyan egyszerű lenne."

Ezzel kapcsolatosan én is szkeptikus vagyok. Természetesen ahogy fejlődik a technológia úgy nő az elérhető legnagyobb frekvencia is. Azért érdemes belegondolni hogy a mostani 1V-os processzorokhoz képest ha még lejjebb viszik a működési feszültséget akkor mennyivel csökken a disszipált energia. Ha sikerül lemenni 0,5V-ig, akkor épp négyszer annyi tranzisztort illetve négyszer akkora frekvenciát lehetne elérni mint a mostani csúcs. Különben szuper extrém hűtésekre lesz szükség. Ami meg mechanikát igényel, és annak az árát csökkenteni nem nagyon lehet egy technológiai váltással. Ráadásul a THz feletti tartományban már csak fénnyel működő dolgok jöhetnek szóba.

"Ha a másik felét nézem, vagyis nem a megahertz növekedés irányát, akkor marad a multiprocesszoros útvonal. 8-16-24-32 stb. Ez sem egyszerű, de ezen az úton mintha az AMD járna elöbbre."

Ez a valószínűbb jövő. A párhuzamosítás. Sok egyszerű végrehajtó egységgel, viszont ezeket el kell látni adatokkal. Ami nagy frekvencián üzemelő, széles (fizikailag is jelentős helyet foglaló) memóriacellával lehetséges. Az AMD valóban előbbre jár, de szerintem csak azért mert felvásárolta az ATI-t. A GPU-iban rengeteg stream processzor van. Amúgy szinte biztosra vehető hogy az Intel befogja, majd leelőzi.

Szvsz. az AMD úgy tud előbbre jutni hogy felvásárolja a technikákat. Pl. annak idején a NexGen felvásárlása nagy ötlet volt ( K5, K6 processzorok lettek belőle ). Különben ugyanúgy eltűnt volna az x86-os süllyesztőben mint mondjuk a Rise vagy a Transmeta...

[ Szerkesztve ]

Hogy a játékosok nem nagyon használják ma még a 64 bites OS-eket és egyéb cuccokat, az egy dolog. De ha a 3D rendererek, médiafeldolgozók gyorsabban futnak 64 biten, mint 32-n, akkor nyilván nem az utóbbin futtatják őket, akik ezeket használják. Ergo nem sokat mond nekik egy 32 bites teszt, ami ezeket a programokat illeti. Mindenesetre, ha nincs kapacitás 64 bites tesztekre, azért talán majd megemlíthetnétek, hogy 64 biten jobban szerepel a Phenom, sőt eleve arra van optimalizálva.

[ Szerkesztve ]

Egyedül lebegőpontos osztásban, gyökvonásban és duplapontos szorzásban gyorsabb az AMD. De a Penryn megjelenésével már csak a duplapontos szorzásban...

Lásd SPEC_FP és főleg SPEC_FP_RATE teszteredmények.

akosf: Nem skalár kódról beszélsz véletlenül?

[ Szerkesztve ]

Nem. Utasítás végrehajtásról beszélek.

Amúgy ha gondolod kereshetek olyan FP kódot ahol a Core2 legalább kétszeresen ver rá a K8-ra ( és egyben a K10-re is ), de persze fordítva is.

[ Szerkesztve ]

Ne csak az egyes utasításokra megadott elméleti latency/throughput értékeket nézd... A K10 nem csak az FPU szélességét duplázta meg, hanem szépen rágyúrt arra is, hogy az egész végrehajtási láncon jóval több adat és utasítás haladhasson át. L1I 256 bit K10/128 bit Core(2), stb.

Nyilván átlagos esetre gondoltam.

[ Szerkesztve ]

Nem tesztelünk 64 biten, de említsük meg, hogy jobb a Phenom 64 biten?
Érdekes elképzelés, ez nem így müxik. Egy tesztben nem lehet felelőtlen, számokkal nem alátámasztott kijelentéseket tenni, ott az eredményeket lehet értékelni, és ennyi.
Egyébként a Penryn gyökvonásban akár 3-szor, osztásban akár 2x gyorsabb, mint a merom (fast radix-16 divider).

"I press keys on a keyboard all day and click a mouse in front of a glowing rectangle. Somehow that turns into food and shelter."

Ezt a 128-bitet a core-nál a realworldtech cikkből vetted? Mint írtam abban elég sok hiba van, nemtom honnan veszik a 128-bitet, mert az Intel doksikban nincs benne. Tippelgetni én is tudok.

[ Szerkesztve ]

"I press keys on a keyboard all day and click a mouse in front of a glowing rectangle. Somehow that turns into food and shelter."

Igazad van. Valóban kell nézni a kiszolgálást is.

Ezért célszerű lenne az összehasonlításokban általánosan használt programok eredményeire támaszkodni. Pl. játékok, böngészők, dokumentum nézegetők, konverterek, tömörítők vagy gyakran használt CAD programok...

Sajna én egy kicsit másképp gondolkodom, mert minden kódban rögtön az optimalizációt keresem. Nálam ritka hogy az adat nincs előkészítve.

Amúgy érdekes módon a Core2 prefetcherei tényleg, szinte hihetetlenül hatékonyak. Az AMD-féle IMC nyújtotta sávszélesség alig (szvsz: nem) képes tartani vele a lépést. A K10-féle L3-as lassítótár meg csak ront a helyzeten. De ez is csak szvsz...

"SIMD FP teljesítményben igenis veri a K10 a Core-t."

Nem veri. Az egyik legkirivobb peldaja a SIMD teszteknek a Sandra Mandelbrot. Az elert teszt eredmenyek egy az egyben a feldolgozo egysegek. Az eredmeny nem fugg a memoria savszelessegtol vagy a rendszerbusztol. Es a Core2 picit gyorsabb ugyanazon az orajelen.

"Lásd SPEC_FP és főleg SPEC_FP_RATE teszteredmények."

Ezt a multkor mar megbeszeltuk. A *rate* eredmenyeket felejtsd el. System throughput nem a mag+feldolgozo egyszegek teljesitmenyet mutatja. Ha a SIMD FP allitasodat akarod alatamatsztani akkor a SPEC_rate nem jo pelda.

Privat velemeny - keretik nem megkovezni...

AMD-s prezentaciokban is benne volt. Valahol itt a topicban van linkelve parszor. Majd megkeresem.

Privat velemeny - keretik nem megkovezni...

Akkor viszont tényleg nem ártana 1-2-3 64 bites teszt.

"Egyébként a Penryn gyökvonásban akár 3-szor, osztásban akár 2x gyorsabb, mint a merom (fast radix-16 divider)."
Tudom, de a gyökvonás viszonylag ritka, és az osztást is igyekeznek szorzással helyettesíteni. Legalábbis a mai kódokban.

(#3230): Máshol is olvastam, megpróbálom előásni.

[ Szerkesztve ]

vááááá....

"I press keys on a keyboard all day and click a mouse in front of a glowing rectangle. Somehow that turns into food and shelter."

"Végülis leírtad hogy az Intel azért tudott előrukkolni a Core2-vel mert voltak hozzá erőforrásai." Végül is igen. De arra is céloztam, hogyha a mobil vonal éppen lassabb lett volna, akkor erőforrástól függetlenül, nem bírtak volna ekkorát újjítani ők se. Ebben persze tévedhetek.

"Akár hiszed, akár nem, ezeknek az embereknek a bére az ami az egyik legnagyobb kiadás." Én is erre tippelek. Amit viszont nehezen tudok felbecsülni, mekkora meló lehet áttervezni a központi architektúrát. Pár millió tranzisztort, a logikát stb. Mondjuk az egyes részegységek kiadhatók kisebb teameknek, de egy idő után nehezen tudom elképzelni a munka további aprózását. Úgy mégsem lehet dolgozni, hogy 1000 ember ül egy csarnokban, aztán mindenki bekiabál, hogy mit hová is kell kötni stb. Ha meg mindenki csak pár kapcsolást dolgoz ki, az meg nehezen áll össze egységgé. Praktikusan ezért inkább 4-8 fős kis teamekre gondolok, akik az egyes részfeladatokat megoldják, ez meg nehezen gyorsítható tovább. Persze találgatok, érdekes lenne tudni, hogyan dolgoznak valójában.

"Ha sikerül lemenni 0,5V-ig, akkor épp négyszer annyi tranzisztort illetve négyszer akkora frekvenciát lehetne elérni mint a mostani csúcs." Szerintem (bár nem vagyok villamosmérnmök) a fesz csökknetése simán a frekvencia emelés ellen dolgozik. Nemcsak a hőtermelés van mint tényező, hanem az áramköri zaj, a digitális jitter pl, jeltorzulások stb. Magasabb frekvencián mindez fokozottabban jelentkezik, amit ma csak fesz emeléssel lehet leküzdeni.

Megbeszéltük, de mindha nem értetted volna: a RATE tesztek annyit csinálnak, hogy nem egyetlen szálon futtatják az adott tesztet, hanem az összes magon egyet. Vagy szerinted nem számít, hogy egy többmagos CPU hogy szerepel többszálú környezetben?

fLeSs: Na ezt nézd meg: [link]

[ Szerkesztve ]

[link]

"I press keys on a keyboard all day and click a mouse in front of a glowing rectangle. Somehow that turns into food and shelter."

"I press keys on a keyboard all day and click a mouse in front of a glowing rectangle. Somehow that turns into food and shelter."

System throughput. Annyi szalon fut a program amennyi mag van a rendszerben. Ezert jon ki a HT miatt gyorsabb az Opteron. Egy egyszeru pelda miert nem hozhatod fel a SPECFP_RATE tesztet bizonyiteknak arra hogy SIMD FP-ben jobb lenne a Barcelona mint a C2Q:

Nyisd ki a result browsert es nezd meg egy 2Ghz K8 alapu 4mag/2socket rendszer eredmenyet, egy 2Ghz C2 Xeon szinten 4mag/2socket es egy 2Ghz 8mag/2socket C2Q eredmenyet. Van tobb is, vegyuk a legjobbakat.

Opteron K8 = 40
2mag Xeon = 40
4mag Xeon = 56

Ha a SPECFP_RATE a tiszta SIMD FP teljesitmenyt mutatna, akkor egy C2Q ketszer annyi maggal es a mar kozismerten job SSE egysegeivel csak 40%-al lenne gyorsabb egy ugyanolyan orajelen jaro K8 alapu Opteronnal.

Remelem most mar vilagosabb. Egyebkent egy szinten 2Ghz-n jaro Opteron 2350 eredmenye 77 ebben a tesztben.

Privat velemeny - keretik nem megkovezni...

Köszi nézem. Közben ment egy mail is.

Ilyen alapon a K10 SPECint_RATE eredményének is jobbnak kellene lennie (ez sem feltétlenül mozgat kevesebb adatot), mégsem az.

Meg úgy emlékszem, a K10 1-szálas SPECfp értékei is jobbak... (Törölték az eredmények közül, mert publikálás után 1 hónappal nincs a piacon a termék, mármint a publikáló IBM szerverei).

Egyébként meg kit érdekel a "tiszta" SIMD FP teljesítmény? Az számít, valós alkalmazásoknál milyen teljesítményt nyújt a rendszer.

"Ilyen alapon a K10 SPECint_RATE eredményének is jobbnak kellene lennie (ez sem feltétlenül mozgat kevesebb adatot), mégsem az."

Nezd, nem ugy ismerlek mint aki nem tud utana jarni a dolgoknak. Miert nem olvasod el a tesztekrol szolo informaciokat, azt hogy milyen tesztek vannak melyik suite-ban benne es hogy futtassak oket? Akkor nem irnal ilyen marhasagokat es elejet vennenk egy felesleges ping-pong vitanak. Egyebkent az Int tesztek messze nem annyira savszeligenyesek mint az FP tesztek. A SPEC-ben sem meg ugy altalaban sem. Ezert hasznalnak FP kodot a maximalis memoria savszelesseg meresere minden letezo tesztprogramban (mindegy hogy Everest, Sciencemark, Sandra vagy epp a Linpack). Ezen kivul meg az is kozre jatszik az eredmenyeknel hogy Int-ben az AMD-nek eselye nincs az Intel ellen.

"Meg úgy emlékszem, a K10 1-szálas SPECfp értékei is jobbak..."

Valoszinutlen. Ha gondolod megkeresheted, valaki csak idezte a neten az eredmenyeket mielott leszedtek volna.

"Egyébként meg kit érdekel a "tiszta" SIMD FP teljesítmény?"

Ehh...teged?:

#3219-ben azt irod "SIMD FP teljesítményben igenis veri a K10 a Core-t." es #3226-ban pedig azzel tamasztod ala hogy "Lásd SPEC_FP és főleg SPEC_FP_RATE teszteredmények."

Azt probalom megertetni hogy a SPEC_rate teszt nem egy processzor teljesitmenyet mutaatja tisztan igy nem lehet egy olyan allitas alatamasztasara hasznalni az eredmenyeit ami arrol szol hogy xy CPU milyen jo FP vagy INT szamolasokban.

"Az számít, valós alkalmazásoknál milyen teljesítményt nyújt a rendszer."

Pontosan. Egyebkent a SPEC is valos alkalmazasok gyujtemenye (ezert mondtam hogy nezd meg a spec.org oldalt mi es hogyan van futtatva), de egyebkent mas, a SPEC-be nem tartozo alkalmazasokban sem ugy nez ki hogy "SIMD FP teljesítményben igenis veri a K10 a Core-t."

[ Szerkesztve ]

Privat velemeny - keretik nem megkovezni...

Természetesen nézegettem. Javaslom, nézd meg te is. Csupa memória-intenzív program van az int csomagban is. Ott mégis lemarad a K10. Pedig azért nem annyival lassabb raw integer teljesítményben, hogy ne tudná hasonlóan kompenzálni a DC arch., mint szerinted fp-nél. Nos akkor ezt mivel magyázod?

"Ezert hasznalnak FP kodot a maximalis memoria savszelesseg meresere minden letezo tesztprogramban"
Csak tudod, nem egészen mindegy, hogy valós számítási algoritmusokról van szó, vagy 128 bites MOV-ok ciklusáról. (Egyébként az SSE korában miért használnának még 64/80 bites scalar fp MOV utasításokat, mint régen, amikor ott vannak a 128 bitesek - amiknek mindegy, hogy int v. fp az adat.)

Próbláltam kicsit keresni, de egyelőre nem találtam őket.

Persze, hogy érdekel - valamennyire.

A SPEC tesztek, int és fp is, valós alkalmazásokból állnak. Éppen ezért tartom őket reprezentatívnak. Az egy másik dolog, hogy nem vektorizált (SIMD-esített) kódban már nem szerepel ilyen jól a proci.

[ Szerkesztve ]

"Csupa memória-intenzív program van az int csomagban is."

Akkor te mast nezhetsz mint en mert nekem ugy tunik inkabb szamitas igenyes programok vannak ott.

"Pedig azért nem annyival lassabb raw integer teljesítményben, hogy ne tudná hasonlóan kompenzálni a DC arch., mint szerinted fp-nél. Nos akkor ezt mivel magyázod?"

Azzal hogy pedig ja, annyival lasabb.Mas hasonlo funkcioju programnal ugynaz latszik.

"A SPEC tesztek, int és fp is, valós alkalmazásokból állnak. Éppen ezért tartom őket reprezentatívnak."

Nem azt mondtam hogy a SPEC nem reprezentativ. Sokadszorra - azt mondom a SPECfp_rate teszt nem reprezentativ egy CPU SIMD FP teljesitmenyenek. Ugyanugy ahogy a SPECInt_rate nem reprezentativ az Int teljesitmenynek.

Privat velemeny - keretik nem megkovezni...

Ne viccelj már. 1/3-a inkább memória(-hozzáférés) intenzív (Programming Language, C Compiler, Search Gene Sequence, Path-finding Algorithms, XML Processing), további 1/3 ez is-az is, és csak a maradék 1/3 a számítás-igényesebb.

Tehát nagyon is ki kellett volna jönnie itt is a sávszélesség-többlet csodás hatásának.

Az SPECfp tesztprogramok - természetesen - a sokkal inkább számítás-igényesek!
Teljes tévedés azt hinni, hogy azok nem mások, mint 128 bites MOV hegyek.
(De azért természetesen ott sem teljesen mindegy a sávszél.)

"a SPECfp_rate teszt nem reprezentativ egy CPU SIMD FP teljesitmenyenek. Ugyanugy ahogy a SPECInt_rate nem reprezentativ az Int teljesitmenynek."
Nagyon értelmetlen ez ebben a formában (ezek mind valós alkalmazások, többszálúan futtatva) - nagyon hiányzik innen a "raw" vagy "elméleti" szó. Ami mellékesen senkit sem érdekel, hanem a gyakorlati teljesítmény. Hacsak nem egy egyszálas programot akarsz futtatni egy többmagos és/vagy többprocis gépen...

De mondom, a fentiek alapján fenn tartom, hogy nem pusztán a rendszer sávszél (DC, HT, IMC) miatt teljesít jól a K10 többszálú fp/SIMD tesztekben, hanem a magokon belüli teljes végrehajtási lánc áteresztőképessége által. Egy erős FPU félkarú óriás enélkül. (Oké, a skalár számításokat jól fogja vinni.)

[ Szerkesztve ]

Nem viccelek, de te ugy latszik igen. Hogyan befolyasolja a memoria savszelesseg-tobblet egy memoria-hozzaferes (latency) intenziv program teljesitmenyet? Mert az utobbi 30 ev eredmenyeibol nekem ugy tunik sehogy.

"Nagyon értelmetlen ez ebben a formában (ezek mind valós alkalmazások, többszálúan futtatva) - nagyon hiányzik innen a "raw" vagy "elméleti" szó"

Akkor miert nem irtad eredetileg oda? En csak azt latom ott hogy "SIMD FP teljesítményben igenis veri a K10 a Core-t.".

"De mondom, a fentiek alapján fenn tartom, hogy nem pusztán a rendszer sávszél (DC, HT, IMC) miatt teljesít jól a K10 többszálú fp/SIMD tesztekben, hanem a magokon belüli teljes végrehajtási lánc áteresztőképessége által."

Latod pont ez nem jon le valahogy egy teszt eredmenybol sem. Fogd azt a tesztet ahol a legjobban szerepelt a Phenom (techreport) es mutasd mar meg melyik tesztben jobb a K10 a Core2-nel ahol nem befolyasolja az eredmenyt a jobb elerheto memoria savszelesseg.

[ Szerkesztve ]

Privat velemeny - keretik nem megkovezni...

"Hogyan befolyasolja a memoria savszelesseg-tobblet egy memoria-hozzaferes (latency) intenziv program teljesitmenyet?"
Mintha nem tudnád, hogy nem csak sávszélesség többlet van ott, hanem latency-ben is jobb az AMD. De szerintem több programnak a sávszél sem mindegy.

"Akkor miert nem irtad eredetileg oda?"
Mert épp azt bizonygatom, hogy nem csak összteljesítményben jobb.

Csak hozzátettem, a lényeg végülis az utóbbi, és a RATE tesztek éppen ezt hivatottak mérni. (Mint ahogy pl. a CineBench multithreaded tesztjében is jobban skálázódik a Phenom, mint a C2Q - holott ez nem használja ki a SIMD teljesítményt.)

A mostani tesztekben nem sok SIMD teszt volt... Talán az egyedüli:

(Mint látható, intenzíven SIMD-ezik a codec, a Penryn esetén legalábbis sokat profitál az SSE4-ből [ami integer SIMD].)

Ha most ti lennétek a helyemben és procitesztet kéne csinálnotok, milyen programokat használnátok?
Lehet írni listát.

"I press keys on a keyboard all day and click a mouse in front of a glowing rectangle. Somehow that turns into food and shelter."

Jó lenne valami pure SIMD teszt (SSE2/SSE3/SSE4), de nem ismerek ilyet. Akosf, P.H., írtok ilyet?