Intel "Conroe" Core 2 Duo CPU-k tesztje

Intel

Az overclockers.com.au alaposan szemügyre vette az Intel kiadás előtt álló új Core 2 Duo szériából való Conroe kódnevű desktop processzorait. A processzorok július végén jelennek hivatalosan meg a retail hálózatban, úgyhogy most egy kis előzetest kaphatunk belőlük. A cikk itt.

( pett1 | 2006. 07. 14., p – 16:01 )

Én a prohardver.hu cikkét olvastam el, sztem jó lett (mármint az írás). Az Intel meg most úgy odabaszott az AMD-nek, hogy szerintem még otthon anyámék is hallották a füles csattanását - pedig nekik aztán nem sok közük van az informatikához. Már csak a válaszra vagyok kíváncsi. Ami szerintem nem fog jönni a következő 3-4 hónapban, de lehet, hogy fél évig is az Intel lesz a király megint. És milyen fasza árakon...

( zoli78 | 2006. 07. 14., p – 16:18 )

átnézve a core architektúrát, némi ébredést érzek az intelnél. 20 év alatt sikerült rájönniük, hogy szarok a procijaik??? lám-lám mégis csak nagy tartalékok vannak és nem véletlen 3x olyan gyors egy ultrasparc, mint egy hyper-szuper intel szerverprocesszor? azért én szégyennek érzem, hogy a decoder egységnek kell kioptimalizálnia azt, hogy az x86 utasításkészlet már 20 éve elavult (ugye most valósították meg, hogy több x86 utasítást összevonnak egyetlen belső utasítássá, ami amúgy a risc prociknál simán egy utasítás, vagy még annyi sem). Szeritnem gazdaságosabb lenne, ha magát az x86 architektúrát megküldenék a kuka felé és átállnának risc-re. A létrejövő teljesítménykülönbség bőven elég lenne arra, hogy a már x86-ra lefordított progikat menet közben fordítsa át risc-re, az új progik meg mennének, mint a szélvihar! De pénz beszél, mérnök ugat...

Gondolom ilyenkor a "macro-fusion"-ról beszélsz...
Ami meg ugye egy cmp és egy jmp összevonását jelenti egyetlen micro-oppá.
Erre mondhatod, hogy jé, ilyen van RISC-ben csak ez tévedés. Sorry.
Sokat keresgéltem most, de nem találtam olyan gépet, ahol van olyan utasítás, ami összehasonlít két regiszter értéket, és eszerint ugrik, max olyat találtam, hogy egy regiszter értéke alapján ugrik...
Persze lehet, hogy csak én nem találtam meg, de mindegy is, mert még ha lenne is ilyen, akkor is megelőzné két LOAD utasítás, ami betölti a két reg értékét, míg az x86-nál a cmp egy regisztert és egy memóriában lévő adatot is összehasonlíthat...

Ezt csak azért írtam, mert nem szeretem ha rossz példával támasztanak alá egy amúgy nem feltétlen hibás megállapítást, miszerint az x86 utasításkészlet felett eljárt az idő...

A RISCnek nem az az előnye, hogy egy utasítással leírható ami CISC-en kettő, sőt pont az ellenkezője igaz. A CISC utasítások könnyen olvashatóak, ez volt a cél mikor kitalálták őket.
Aztán, mikor már a programozók többsége nem asmben programozott, rájötek, hogy inkább az alapján kéne kitalálni az utasításkészletet, hogy mit könnyű utána dekódolni, végrehajtani. Na ez a RISC.

Az intel szar procikat gyártana? Nem hinném. A piaci adatok sem ezt mutatják.
Lehetne ennyi tranzisztorból más felépítéssel, más utasításkészlettel gyorsabb procit építeni? Persze. Szoktak is.
Csak ezek általában maximum magukkal kompatibilisek.
A felülről kompatibilitás pedig fontos, és az is marad, míg nem írnak szinte minden programot valami Java-like rendszerre...

"A létrejövő teljesítménykülönbség bőven elég lenne arra, hogy a már x86-ra lefordított progikat menet közben fordítsa át risc-re, az új progik meg mennének, mint a szélvihar!"
Rengeteg példa van arra, hogy ez nem igaz. De álmodozni lehet...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

ha a macrofusion csak ennyit csinál, akkor az nagyon sovány!
Még van pár dolog, amit kereshet, mert tipikus áramkörileg megvalósított dolog:
- háromoperandusú utasítások: r2 = r0 @ r2, ennek akkor van jelentősége, ha a következő utasításban az r0-t ismét fel kell hasznáni.
- +1/-1 (carry bemenet közvetlen vezérlése). Pl. r2 = r0 + r1 + 1 vagy r2 = r0 - r1 - 1
- stb.

"Persze lehet, hogy csak én nem találtam meg, de mindegy is, mert még ha lenne is ilyen, akkor is megelőzné két LOAD utasítás, ami betölti a két reg értékét, míg az x86-nál a cmp egy regisztert és egy memóriában lévő adatot is összehasonlíthat..."
A risc egyik alapszabálya, hogy csak regiszteroperandusokat használunk. És ez nem gond, mert a leggyengébb 32 bites risc prociban is minimum 32 teljesen egyformán kezelhető általános célú regiszter van. összehasonlításképpen az x86-ban 4 (egyesek szeretik 8-nak feltűntetni, mert beleszámolják a sp, bp, sp, dp regisztereket is, amik egyeltalán nem általános célúak), de még a 4 regiszter (ax, bx, cx, dx) is csak látszólag általános célú, mert sok utasítás van, ami fixen ezt vagy azt a regisztert használja (pl. osztás/szorzás: ax,dx; loop: cx, stb.). Ezek miatt elég nehéz optimalizálni és sokat kell mentegetni a memóriába.
A másik, hogy a példádban is csak egy load-nak kéne a risc oldalon lennie, mert az x86-os utasításnak is csak az egyik operandusa lehet memóriaoperandus. Amúgy ez a közvetlen memóriából turkálunk szép kis leállásokat okoz a pipeline-ban. Ha cache-ben van, nem gond, mert a 32 fokozatból 2-3 arra erre van és el van rejtve. De ha memóriából kell behoznia, akkor az már akár 100-200 órajelciklus is lehet (egyébként az amd azzal dobot nagyot, hogy ezt le tudta rövidíteni).
Risc-nél eltolt load/store műveletek vannak és a load/store-t külön pipeline végzi, ami miatt a többi utasításnak nem kell várakoznia.

Ezek (és még sok egyéb) lenne az a tartalék, amivel az intel procik is rendelkeznének megfelelő utasításkészlet esetén. Illetve ahogy nő a felhasználható tranzisztorok száma, lehetőség nyílik arra, hogy maga a processzor végezzen peephole optimalizációval egybekötött utasításdekódolást (gyakorlatilag risc-re fordít, illetve a risc ment le microcode szintre annak idején).
Amúgy nem utálom az intelt, csak jobb szeretném ha megtörne a monopolhelyzete. Tudnak ők rendesen és jól tervezni, csak az x86-ot túlzottan elterjesztették és nehéz a visszaút (az itanium a példa rá, hogy szerveroldalon szakítani akartak az x86-tal. Csak nem lett áttörés és inkább elkezdték nyomatni a xeonokat).

Ha nekem magyaráztál ennyit, akkor kár volt. :)

Ahogy az Intel diákat nézem a Macro-op fusion annyit csinál amennyit mondtam.

A regiszterek száma tényleg kevés, bár amd64-ben már 16, + mmx regiszterek. ("mindenkinek elég kell legyen" :) )
Ez tényleg nem sok, és valóban gond lenne amit leírtál, ha nem lenne Register renaming, Out of Order, stb.
(Mielőtt belekötsz, ilyenek vannak G5-ben is...)

Valóban hátrány, hogy az x86 utasításokat dekódolni kell, de az a tranzisztormennyiség, amit erre fordítnak, alig pár %-át teszi ki a procinak, és ez az arány egyre csökken.

Véleményem szerint a RISC is lassan mehetne a süllyesztőbe, az EPIC (IA-64) sokkal fejlettebbnek, igéretesebbnek látszik.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

ne aggódj nekem is szakmám, úgyhogy nem kötök bele semmibe se. Pontosan tudom, hogy működnek ezek a dolgok (architektúrális szinten és nem elektronikai szinten!)
Az IA-64-et is ismerem architektúrális szinten, nagyon brutális, de én már csak a multiplatformos programok széleskörű terjedésében látok arra némi reményt, hogy kikopik az x86. Örültem volna neki, hogy ha az AMD és az intel megállapodtak volna valamilyen hatékonyabb utasításkészletben és abban valósították volna meg a 64 bites bővítményt. Persze ez a fordítóprogram és oprendszer fejlesztőknek okozott volna némi munkát.

Jó neked, nekem nem szakmám. Vagy csak igen távolról. :)

Igen én is csodálkoztam anno mikor megjelent az amd64, hogy ha már megnövelik a regiszterek számát, akkor miért csak 16-ra, miért nem mindjárt 32-re vagy többre. Csak ugye ami úgy tűnik, hogy sokat számít, az a való életben nem biztos, hogy tényleg annyit számít.

Gondolom hosszas méregetés előzte meg a döntést.
Elvégre mikor jó a sok regiszter? Pl ha a fordító inline-osít. Azt nem tudja bármilyen mélységben.
Plusz egy általános GUI-s program mutatókkal, stringekkel, és hasonlókkal manipulál, olyan nagyon sokat nem számít a sok regiszter.
Sőt, még egy kézzel írt FFT-nek sem kell 15-nél több. És egyébként is ilyesmikre ott az MMX regiszterek sokasága.

Akkor igazán jó a sok regiszter, ha kiváltható vele a veremhasználat még normál függvényhívásnál is, de ehhez meg valami cirkuláris regisztertömb kéne, mint ami a SPARC-ban van (ha jól emlékszem).
Azért az meg elég nagy váltás lett volna ahhoz, hogy ne legyen értelme...

Meg aztán a 2 MB-s cache-ek, és fejlett prefetch algoritmusok korában ennek egyre kisebb a jelentősége. Nem véletlen, hogy az Apple is milyen könnyedén váltott a "Csodás" G5-ről a "gagyi" Core-ra...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

"A CISC utasítások könnyen olvashatóak, ez volt a cél mikor kitalálták őket."
Nem egészen emiatt volt, de nem tévedsz sokat. cisc: sokan még assembly-ben programoztak, lassú és kevés volt az operatív tár, amit csak lehetett a procin belül meg akartak csinálni. De azért lett vége, mert elterjedtek a fordítóprogramok és a félvezető memória. Aztán kiderült, hogy alig vannak a procik kihasználva, olyan dolgokra pazarolnak, amit a fordítóprogik nem használnak. És más megoldásokat kerestek (a risc-el együtt jelentek meg a nagyszámú regiszterek is).

"Csak ezek általában maximum magukkal kompatibilisek."
Ezt is cáfolja a risc világa. Ott is vannak szabványok.
Amúgy meg az x86 csak és kizárólag saját magával kompatibilis.
Ha powerpc-ből lenne 90% a piacon, akkor azt tekintenénk a normálisnak, pont úgy, ahogy most az x86-ot.
Persze, az intel nem gyárt szar procikat, abban az értelemben, hogy a termékeik használhatatlanok lennének, de rengeteg energiájuk megy el az utasításkészlet miatt. Bár most ez már egyre kevésbé hátrány nekik, mert már a tranzisztorszám kisebb százalékával is sokkal bonyolultabb logikákat ki tudnak alakítani, hogy ezt megoldják.

"Rengeteg példa van arra, hogy ez nem igaz. De álmodozni lehet..." transmeta crusoe, efficienon?! keményen rácáfol az állításodra!

Amúgy a risc és utána jövő architektúráké a jövő, ezt az intel is nagyon jól tudja és nagyon erősen szorulnak ki az x86 procik minden más területről, ahol nem kell az x86 kompatibilitás. És egyre több program x86 független PC kategóriában is!

"Amúgy a risc és utána jövő architektúráké a jövő, ezt az intel is nagyon jól tudja és nagyon erősen szorulnak ki az x86 procik minden más területről, ahol nem kell az x86 kompatibilitás."

Sokkal inkább úgy tűnik, h az x86 tör egyre felfelé a szerverpiacon, ahol eddig csak RISC-ek voltak...

Te:
"A létrejövő teljesítménykülönbség bőven elég lenne arra, hogy a már x86-ra lefordított progikat menet közben fordítsa át risc-re, az új progik meg mennének, mint a szélvihar!"

Én:
"Rengeteg példa van arra, hogy ez nem igaz. De álmodozni lehet..."

Te:
"transmeta crusoe, efficienon?! keményen rácáfol az állításodra!"

Már miért is cáfol rá? Transmeta mintha éppen csődközelben lenne, mert nem úgy muzsikál az ötlet, mint várták...
De ha úgy vesszük, a mai x86 procik pont azt teszik, amit mondasz, csak hardverből.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

A csődjének a piachoz van köze és nem a proci képességeihez. Sajnos a 90nm-re való nehézkes átállás és sok csúszás miatt lemaradtak a piaci lehetőségekről. Aztán jött a pentium-m...
Amúgy crusoe: 64 bites vliw, az efficienon meg 128 bites vliw proci, melyen egy "virtuális pc" szoftver értelmezte az x86-os utasításokat, valamint optimalizált fordítást végzett a forró pontokon.

Tudom, hogy mik a Transmeta procik filozófiája, és azt olvastam, hogy bár a fogyasztási mutatóik igen jól alakultak, a teljesítményük elmaradt a várttól.

Egész egyszerűen nem igaz az manapság, hogy a RISC processzorok az utasításkészletük miatt nagyságrendekkel gyorsabbak lennének.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

"Amúgy a risc és utána jövő architektúráké a jövő, ezt az intel is nagyon jól tudja és nagyon erősen szorulnak ki az x86 procik minden más területről, ahol nem kell az x86 kompatibilitás. És egyre több program x86 független PC kategóriában is!"

Én épp az ellenkezőjét tapasztalom (anélkül, hogy minősíteném, vagy kommentálnám, csupán ténymegállapítás). Mindenhonnan kiszorulóban vannak a RISC-es megoldások, kivéve, ahol szükséges a (önmagukkal való) kompatibilitás, pld. mert az adott alkalmazás csak Solaris/SPARC-on használható.

Nekem a RISC-es szegmens erősen szűkülőnek tűnik. Ami a részesedését eszi, az nagyobb arányban az x86, kisebb arányban (egyelőre) az Itanium, utóbbi leginkább a high end részben.

hány darab játékkonzolt fognak eladni?
xbox360: ibm powerpc
ps3: ibm cell (powerpc)
a többiek közt még MIPS proci is előfordul, de csak az előző generációs xbox használt pentium procit.
Beágyazott rendszerek: nyomtatók, fénymásolók, routerek, pda-k, mobiltelefonok, mind risc-et használnak (egyébként ezen utóbbi kettőre be akar az intel törni x86-tal).

Azt hittem, hogy általános célú számítógépekről, azon belül is inkább szerverekről beszélgetünk. :)

Nyilván ez is nagy piac, bár kötve hiszem, hogy túl nagy befolyással lenne úgy általában a számítástechnika alakulására (asztali gépek és szerverek területén).

"Sokat keresgéltem most, de nem találtam olyan gépet, ahol van olyan utasítás, ami összehasonlít két regiszter értéket, és eszerint ugrik"

IBM 370 és utódai?
360-asnak volt valami hasonló kezdeménye, dehát több mint húsz éve, hogy utoljára IBM-et láttam... :(

--
Fel! Támadunk!

Ezzel az a gond, hogy RISC-nél fix utasításhossz van ugye, mondjuk 64 bit. (esetleg ibm360 még csak 32?)
Na ebbe kéne beleférni az utasítás kódjának, két regiszter sorszámának (amiből RISC-ben sok van) és a köv utasítás címének (eltolásának). Necces...
Főleg, hogy az egyik regiszter helyén nem volna rossz, ha konstans is állhatna.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

http://en.wikipedia.org/wiki/System/360:

# 32-bit words

Most System/360s had 16 general purpose 32-bit registers (R0–R15). They also had four floating point registers that could be programmed for either 32-bit or 64-bit floating point operations.

amikor os/390-et tanultam, akkor még azt mondták, h a 8 bites gépekre írt programokat is tudja futtatni. ez kompatibilitás.

Az intellel kapcsolatban én azt nem értettem sose, h amikor 486 után nem 586, hanem pentiumm-al jöttek elő, akkor miért nem vágták sutba az x86-ot. kompatibilitással nem kellene takarózni az ő esetükben imho ;-)

Nem a szóhosszra, hanem az utasításhosszra gondoltam. A kettő nem feltétlen kell egybeessen.

Sőt, a wiki szerint:
"Instructions were always 1 byte (8 bits) followed by at least a 1-byte immediate operand. Instructions were always situated on 2-byte boundaries. There were three types of instructions: those that took no operands (2 bytes), one operand (4 bytes), and two operands (6 bytes)."

Upsz, ez nem is RISC.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Érdekes, mikor legutoljára láttam 1 GHz körüli US-t, nagyon nem olyan érzés volt, mint egy 3 GHz-es Xeon, akármivel is néztem.

Van egyébként hasonló órajelű. Ha minden igaz idén fognak átvándorolni a Sun kínálatába a SPARC64-es processzorok, a jelenlegi gépek és processzorok (USIII, IV) lassú kihalása mellett.
Annál a maximum órajel 2,16GHz, konkrét összehasonlításom nincs mondjuk egy hasonló Intel processzorral (pld. egy újabb Xeon51xx-szel), de egy US T1 és egy Intel Core-leszármazott, összességében azonos órajelű felépítés nekem csúcsteljesítményben kb. azonos volt, ami azt jelenti, hogy nem láttam az azonos órajelen háromszoros szorzót.

Használtál már 1 GHz körüli US-ot és 3 GHz körüli Xeont?