-
Mobilarena
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
robyeger
addikt
válasz
Raymond
#1454
üzenetére
Igen K8-nál az XBAR az IMC, a HTT és az SRQ között 2db 64bites magórajelen futó busz van, de az SRQ és a L2 között 2x2db 64bites busz van, pont azért mert itt alapórajelre lassulunk vissza, viszont feltételezésem szerint az L1 és a TLB az SRQ-hoz már szintén magórajelen kapcsolódik, ezért nem nevezhetjük klasszikus FSB kialakításnak. De ha te szerinted máshol van a processzor szorzója, akkor várom a javaslatodat.
[Szerkesztve] -
robyeger
addikt
válasz
Raymond
#1447
üzenetére
1db off hsz erejéig válaszolok a nyelvészeti kérdésedre
:
[link] Ez biztos, hogy magyarul van?, mert én egy kummányit se értek belőle, de könyörgöm el ne magyarázd
Jó vettem a célzást, magyarosan megfogalmazva: ''az L2 gyorsítótárak áteresztő képessége a magok között''
A full duplex és a double pump-ra nem mondtam, hogy teljesen azonosak, csak számszakilag egyezik meg az elméleti sávszélességük.
[Szerkesztve] -
robyeger
addikt
válasz
Raymond
#1445
üzenetére
Ugye azt nem várod el tőlem, hogy a ''hülyeség'' és a ''lepke'' hasonlattól megváltoztatom a véleményem, de mire is?, gondolom majd ha túl leszel a költözködésen kifejted részletesebben is.
Amúgy az a 2db adatút Full duplex vagy ''double pump'' vagy nevezd aminek akarod, de beszélhetünk 4db 64bites adatsínről is, mint a hammer prezentáció 26. oldalán látható ábrán is a CPU és az SRQ között [link], szóval tök mind1, számszakilag ugyan az lesz = 2x2x64/8x200 = 6400 -
dezz
nagyúr
válasz
Raymond
#1419
üzenetére
Nekem nem úgy tűnik, mintha nagyon változnának:
(A Chip Architectes oldalon látható táblázat: )
:::::::::::::::::::::::: 130 nm to 90 nm | 90 nm to 65 nm | 65 nm to 45 nm |
:::::::::::::::::::::::::::: transition :::::: | ::: transition :::: | :::: transition :::: |
------------------------------------------------------------------------------------------------------
Ideal Area Scaling :: | ::::: 0.48 :::: | :::::: 0.52 :::::::: | ::::::: 0.48 :::::::: |
Logic Area Scaling : | ::::: 0.72 :::: | :::::: 0.70 :::::::: | ::::::: 0.70 :::::::: | (Intel)
SRAM Area Scaling | ::::: 0.67 :::: | :::::: 0.64 :::::::: | ::::::: 0.48 :::::::: | (Intel)
Mint láthatod, az ideális (elméletileg elérhető, amibe nyilván beleszámolták azokat a bizonyos fizikai és kémiai kötöttségeket) 65->45-nél is 0,48... Az SRAM-nél sikerül is (AMD-nél még jobban, ott mindig megvan a ~0,50). Namost az egy dolog, hogy az Intel a magot nem is törekszik 0,70 alá nyomni, az AMD-nél más a helyzet, ők korábban is megközelítették a magnál is a 0,50-et, tehát lehetséges a mag SRAM-ot közelítő összenyomása. Mi alapján állítod akkor, hogy ez 65->45-nél lehetetlen?
Még1x: nem én állítom, hanem sok helyen lehetett olvasni, hogy a Brisbane egy gyors, felületesebb shrink volt, mint a korábbiak, mert így is le voltak maradva a 65nm-re való átállással, és mivel órajelben sem túl jók, olcsó procik lesznek belőlük. Nézd végig a termékvonalat, a nagy része ma is 90nm-es. Az első, igazán jól megcsinált 65nm-es proci a K10 lesz, a Brisbane csak egy kis bemelegítés volt hozzá.
De nézzük csak meg jobban a képeket! Mérjük csak a Brisbane magját a Barcelonáéhoz! Szélesebb. De ez még nem minden: a L1-ek is szélesebbek - miközben magasságban megegyeznek... Pedig szélességben kellene egyezniük, nem magasságban, mivel láthatóan függőlegesen széthúzottabbak a Barcelona L1-ei! Jól van ez így? Mármint, jól méretezték be a Brisbane képét (elvileg méretarányos az összes kép)? Úgy tűnik, a magasságot vették alapnak, nem a szélességet! Megfelelő méretre kicsinyítve a Brisbane magot (90%-ra) egy érdekes történik: a két mag is egyforma szélességűvé válik így! Szal szerintem ez a megfelelő méret!!! Így összehasonlítva a 90nm-es Windsor maggal már 0,60 az arány, nem 0,67! Ez már nem is olyan rossz, megközelíti a korábbi váltás 0,56-ját!
És nézzük csak, mennyivel hosszabb így a Barcelona egy magja (a 2. FPU nélkül!), mint a Brisbane-é: 13,5%-kal! Azaz nem éppen csak a 2. FPU egységgel nőtt a mag.
[Szerkesztve] -
dezz
nagyúr
válasz
Raymond
#1417
üzenetére
Te melyik képről beszélsz, mert én erről: [link]
Világosan látszik, hogy a 250nm->130nm váltáskor is, és a 130nm->90nm váltáskor is majdnem pont a felére sikerült nyomni a magot.
Igen, az Intel sorra csak kb. 70%-ra nyomja a magot, de akkor nézzük az AMD-s számokat:
130 nm ---- (Hip7) -------- 55 mm2
90 nm ------ Windsor ---- 31 mm2
65 nm ------ Brisbane --- 20.8 mm2
65 nm ------ Barcelona - 25.5 mm2
31/55=0,5636 -> az eredeti 56%-a.
20,8/31=0,67 -> az eredeti 67%-ára, ebből is látható, amit írtam, de más forrásból is lehetett hallani: a Brisbane egy gyors, ''felületes'' shrink volt - túl sokat nem volt érdemes dolgozniuk vele, a gyártás kisebb részét teszi ki, stb.
25,5/20,8=1,226 -> 22,6%-os bővítés (a. verzió)
Ha viszont azt feltételezzük (a korábbiak alapján), hogy a 130nm->65nm váltásból is ki tudták volna hozni a közel ''felezést'', ha nagyon akarták volna, akkor a Brisbane egy magja 16-17 mm2 is lehetett volna. Ehhez képest a 25,5 mm2 az nagyjából 50%-os bővítés (b. verzió).
Valahol az a. és a b. verzió között van az igazság.
-
dezz
nagyúr
válasz
Raymond
#1415
üzenetére
Persze, de én az előzőleg linkelt képen látható 90nm-es ''Rev. F Dual Core''-hoz hasonlítottam.
A K8-féle 65nm-es állítólag csak egy gyors, átmeneti megoldás volt, nem kihasználva az összes kicsinyítési lehetőséget, így ahhoz nem annyira érdemes hasonlítani. Ha viszont azt vesszük, hogy ahhoz a bizonyos Rev. F-hez képest 50%-ra kicsinyítés helyett kb. 75%-ra kicsinyítettek, az azt jelenti, hogy a bővítés nélküli állapothoz képest 50%-kal nagyobb lett. -
#1269
VaniliásRönk
nagyúr
Raymond
#1267
VaniliásRönk
nagyúr
válasz
Raymond
#1267
üzenetére
Te épp az ''én jobban tudom'' szemüveget viseled, és mindenáron ki akarsz okatatni.
A teljesítmény nem teljesítmény/clock, attól meg hogy aki a leggyorsabbat keresi az az Intelnél nézelődik még nem jelenthető ki általánosan, hogy az AMD az nem alternatíva, attól függ mennyit szánhatsz ilyen célra. Ennyi. -
dezz
nagyúr
válasz
Raymond
#1232
üzenetére
Az XbitLabs kicsit máshogy tudósit:
Sources close to AMD did not expect the company to release quad-core chips at frequencies of more than 2.60GHz this year. However, Rick Bergman, who is senior vice president and general manager of graphics product group, said that all the demonstrated high-end products will be available before year end.
“You’ll see those products available for delivery this year,” Mr. Bergman said, emphasizing that the system used off-the-shelf cooling solutions, which means that the machine is not an ultra-overclocked piece of hardware, but something that resembles a PC ready for shipment. [link] -
#95904256
törölt tag
válasz
Raymond
#1223
üzenetére
Ez esetben ( 2 mag vs. 4 mag ) viszont keveslem a 3,6-szoros gyorsulást. Elvárnám hogy a kétszer annyi mag, kétszer gyorsabb SSE motor és a többi sávszélesség bővülés miatt legalább négyszeres legyen a proci vs. proci gyorsulás...
szerk.: Tulajdonképpen az elérhető lebegőpontos műveleti teljesítmény növekmény szerintem olyan 2.0 és 2.5 közé fog esni
[Szerkesztve] -
dezz
nagyúr
válasz
Raymond
#1205
üzenetére
Sajnos az az ''elmagyarázás'' nem állja meg a helyét, lásd Replies.
Btw, az hogy lehet, hogy a pl. 3800+ kevesebbet fogyaszt, mint az 5000+, azonos feszen nagyobb áramfelvétel mellett?
---
Az jó, hogy az Agena egyes példányai mennek 3 GHz-en, de ha 1000-ből 1db képes erre, az már nem az igazi. Mindenesetre ez is azt erősíti (bizonyítja?), hogy nem a maggal magával van baj, hanem a gyártással...
[Szerkesztve] -
Oliverda
titán
válasz
Raymond
#1200
üzenetére
Mégis mire számítottál? 3.0GHz 50W-os TDP-vel 65nm-en kezdés gyanánt?
Főleg azok után nem értem ezt a látszólagos nagy ''lehangoltásgot'', hogy elvileg már egy jó ideje nyomon követed a topikot és minden hírt elolvasol. Várható volt, tudtuk, de én ennek ellenére sem érzem ezt olyan borzasztónak. Komolyan, néha úgy érzem mintha egy két magos CPU-ról lenne szó. -
Raymond
titán
válasz
Raymond
#1200
üzenetére
Meg egy kis info a teljesitmenyhez (vagy hianyahoz):
2GHz Barcelona to compete with 2.33GHz Clovertown
[link]
''When asked about the clock frequencies Barcelona will launch at, Felipe Payet, worldwide channel market development manager in AMD’s server/workstation product group, told us that “we don’t think that’s necessarily all that low.”
Payet then went onto explain the reasoning behind that statement “[AMD] tends to lag in terms of pure clock frequency, but that doesn’t mean we lag in performance. Given the fact that we use a HyperTransport and direct connect based design, clock frequency is no longer an indication of performance.”
Demski then chimed in to add some more context to Payet’s statements. “Even though 2.0GHz doesn’t sound like a lot, we will put our 2.0GHz part up against their 2.33GHz part and we will be very comfortable with that.
“If you compare our medium power part to their medium power part we think we’ll be compare very favourably. And the same is true with the low power parts. The thing we’re lacking is that we don’t have that SE high performance part, which is coming later this year,” he said.''
A HT-t emeli ki ami azt jelenti hogy a ''comfortable with that'' azt jelenti nem a szamitasigenyes hanem inkabb a transakcio igenyes feledatoknal OK-s a teljesitmeny. Ez mondjuk nem megplepo az eddigi (mar itt is kitargyalt) infok alapjan. -
P.H.
senior tag
válasz
Raymond
#1176
üzenetére
A mostani kétmagos négyjegyű Opteronok (F2, F3) területén az SE-k 119W, a HE-k 68W, a többi 95W TDP-vel rendelkeznek. Miért olyan lehangoló kisebb csíkszélesség, +2 mag, +2 MB L3 és ''megkétszerezett'' méretű FPU-unitok mellett konzekvensen ugyanez az adat (jelenlegi legutolsó kétmagos versus következő első (+ második?) négymagos revision)?
[mod]: Más. K10 esetén ismert már, hogy mennyi lesz a Vcore, illetve, hogy mennyi lesz a HE változatok magfeszültsége?
[Szerkesztve] -
Oliverda
titán
válasz
Raymond
#1184
üzenetére
Jó, én az Intel-hez viszonyítok mert egyrészt most ugye az az etalon, illetve más x86-os 4 magos procit hirtelen nem tudok felhozni.
Az a 95W akkor mondjuk 110W maximális fogyasztást jelent Intel módival kalkulálva. Az AMD is fog majd újabb steppingeket kiadni, már valahol írtak is róla. Tehát szerintem kezdésnek nem rosszak ezek az értékek. -
Oliverda
titán
válasz
Raymond
#1176
üzenetére
Q6600: [link] Thermal Design Power: 105W
1358 SE 2.4 GHz 4x512KB 2MB 120W
Ha figyelembe vesszük az Intel féle TDP számítást, akkor a két CPU kb. ugyanannyit fogyaszt.
Tehát szerintem a fogyasztási adatok rendben vannak, azt ne felejtsük el hogy ez még csak 65 nm.
[Szerkesztve] -
Raymond
titán
válasz
Raymond
#1163
üzenetére
T2080 (1.73Ghz) WXP32bit
Fast_SSE2__:_1 119 298 427 = 656 ms
Fast_SSE___:_1 133 661 451 = 656 ms
Fast_x87___:_1 189 157 762 = 672 ms
Slow_SSE2__:___944 186 594 = 547 ms
Slow_SSE___:_1 164 346 222 = 672 ms
Slow_x87___:_1 165 944 767 = 672 ms
A gepen gyakorlatilag csak a Win, meghajtok es az AVG fut. -
dezz
nagyúr
válasz
Raymond
#1163
üzenetére
Akkor egy PM vs. C2D:
Fast SSE2: 594 / 218 * 1860 / 2295 = 2,21
Fast SSE::: 625 / 218 * 1860 / 2295 = 2,32
Fast x87:::: 625 / 375 * 1860 / 2295 = 1,35
Slow SSE2: 469 / 171 * 1860 / 2295 = 2,22
Slow SSE:: 797 / 375 * 1860 / 2295 = 1,72
Slow x87:::: 625 / 406 * 1860 / 2295 = 1,24
Lehetséges, hogy a háttérben futó dolgok 20-30%-ot rontottak a PM teljesítményén, azt hozzászámolva 6-ból 5 esetben pont egyszeres és kétszeres eredmény jönne ki.
(#1162) akosf: Ki kellene próbálni...
[Szerkesztve] -
Raymond
titán
válasz
Raymond
#1160
üzenetére
PM750 (1.86Ghz) WXP32bit
Fast_SSE2__:_1 004 705 672 = 594 ms
Fast_SSE___:___984 297 701 = 625 ms
Fast_x87___:___998 029 496 = 625 ms
Slow_SSE2__:___797 694 562 = 469 ms
Slow_SSE___:_1 328 507 256 = 797 ms
Slow_x87___:_1 013 922 365 = 625 ms
Hogy oszinte legyek ezekben az eredmenyekben nem nagyon bizom. Ugyanazon teszt tobbszori egymasutani lefuttatasa tul nagy kulonbsegeket adott (pl. 697 ms v. 860 ms). Eleg sok minden fut a gepen. Kivalasztottam a leheto leggyakrabban felbukkano legjobb eredmenyt. -
-
#95904256
törölt tag
válasz
Raymond
#1139
üzenetére
Más a baj. A MULPS és MULPD tesztek 35 bites eredményt írnak ki, míg az ADDPS csak 32 bitest. Túlcsordulásos hiba a programban. Erre még reggel rájöttem, ki is javítottam, de úgy tűnik mégis rossz kódot töltöttem fel a szerverre. Bocs..
A pontos eredményt úgy kapod meg hogy X=N+4.294.967.296.
Vagyis PD930 WXP32bit ADDPS: 5.005.144.860.
Amint hazaértem feltöltöm a javított fájlt. -
-
-
dezz
nagyúr
válasz
Raymond
#1117
üzenetére
''mivel stream-elt adatok feldolgozasarol van szo''
Azért arra is gondoljunk, hogy nem csak pl. összeadni kell itt a számokat, és már lehet is kiírni, hanem blokkonként elég bonyolult műveleteket kell végezni. Tehát a blokk rel. sokáig a cache-ben lehet.
A megosztással/közösítéssel kapcsolatban arra gondoltam, hogy talán adatok is utazhatnak a L2-n keresztül a két mag között. (Nem tudom, a C2D tud-e egyátalán ilyet.) Az persze nem valószínű, hogy már tavaly így optimizált kodekek lettek volna, de szándékosság nélkül is kijöhet ilyen helyzet. -
#95904256
törölt tag
válasz
Raymond
#1117
üzenetére
Oh, elnézést, másféle cache megosztásra gondoltam.
Arra gondoltam hogy a két szál egyszerre dolgozik ugyanazokkal az adatokkal ugyanarról az adatterületről. A C2D hardveres cache megosztásnak a videokódolás szempontjából még kevesebb jelentősége van, ugyanis ebben az esetben mindkét mag teljes gőzzel dolgozik, így nem nagyon tud egyik szál sem profitálni abból hogy a másik mag kevésbé használja a cache-t... -
#95904256
törölt tag
válasz
Raymond
#1113
üzenetére
Szerintem az E4300-asom is megfelel. Ha gondolod, írhatok egy kis programocskát amely meghajtja a 128 bites SSE engine-t és kiírja a futáshoz szükséges órajelek számát a képernyőre. Ez jóval pontosabb eredményt szolgáltat mint a videokódolás, ugyanis az még jelentősen függhet más dolgoktól is ( FSB, RAM, cache méret, ... ).
Sőt, ha ez a ciklusmag megfelel:
cycle:
addps xmm0,[esi+00h]
addps xmm1,[esi+10h]
addps xmm2,[esi+20h]
addps xmm3,[esi+30h]
dec ebp
addps xmm4,[esi+40h]
addps xmm5,[esi+50h]
addps xmm6,[esi+60h]
addps xmm7,[esi+70h]
jnz cycle
Akkor letöltheted innen: [link]
Ez 125 milliószor futtatja le a fenti ciklusmagot, vagyis 1 milliárd 128 bites SSE összeadást végez. Az eredmény a végrehajtáshoz szükséges órajelek száma.
E4300/Win2000: 1.000.792.422 -
#1070
VaniliásRönk
nagyúr
Raymond
#1068
VaniliásRönk
nagyúr
válasz
Raymond
#1068
üzenetére
Azzal hogy a mondandómnak csak a szavatosságát vonod kétségbe, mikor a 1065-ös lényege az hogy gyk. rágalmaztak... minek neveznéd? Amint látod a 1049-es hsz módosíthatósága már rég letelt, mikor akosf először reagált, a 1051-es nem kisregény, plussz a hsz amiből ez a mostani téma kiindult másnap született, akosf nem emlékezhetett rosszul, ez kizárt.
Milyen sajátosságról lehet itt szó? Úgy tudom nincs jelentős újítás a Hi-K-n kívül, az meg csökkenést nem okoz, csak a növekedést akályozza meg.
Amikor tévedek azt elimismerem, láthattad is. Egyébként ''csak'' azzal nem voltam tisztában, hogy a HT DDR, ezt nem sok helyen írták le.
(a cache Penryn esetében pont akkora a képek alapján mint a 2 mag) -
#1067
VaniliásRönk
nagyúr
Raymond
#1066
VaniliásRönk
nagyúr
válasz
Raymond
#1066
üzenetére
Szerinted ha azonos a tranzisztorok száma, és az órajel is megegyezik, akkor mi mástól csökkenne a fogyasztás, ha nem a feszültségcsökkentéstől? Pl. ha jól tudom a Hi-K is azért kell, hogy ne növekedjen a szivárgási áram, és ezzel a fogyasztás.
Kössél belém azért mert nem hagytam szó nélkül azt, hogy olyan állítást tulajdonítsanak nekem, amit le se írtam, nemcsak kiszerkesztettem, le sem írtam. -
dezz
nagyúr
válasz
Raymond
#1042
üzenetére
Hm, én nem látok új press-release-t az AMD-nél. Mindegy, 2.0 GHz augusztusban - még mindig jobb, mint 1.6, egyelőre. Lesz ez még bőven jobb, főleg ha igaz, hogy az a bizonyos Cx kapásból sokat dob majd rajta.
szerk: ja, azt akartam még írni, hogy a bejelentés péntek reggelre időzítésének jelentőségét kicsit eltúlozzák: ezek leginkább OEM-eknek szánt szerver chipek, említett cégeken (akik már amúgy is tudhatnak róla) és a techno-melegeken kívül nem nagyon izgatják a nagy nyilvánosságot.
akosf: Oké, ezek egyenként nem jelentéktelenek, de mint írtam, kérdéses, mennyit számítanak összességében.
[Szerkesztve] -
#963
Komplikato
veterán
Raymond
#962
Komplikato
veterán
Gyártó oldalát megnézted? Én is tudom mennyire ''megbízható'' a Fudzilla (nem mint ha pl. Dailytech nem írt volna már kamu híreket vagy az Inquirer), de azért rengeteg híroldal átveszi ... a marhaságaikat is. Viszont amit ír az nem kamu, adott oldalon tényleg ott az infó, de ettől lehet még hamis adat.
[Szerkesztve] -
#95904256
törölt tag
-
dezz
nagyúr
Oké, de elvileg az Agena FX HT3.0-ás, miközben kétutas (a s.F+ változat). A Barcelona meg HT2.0. Lagalábbis jól titkolják, ha HT3.0-ás mégis. De miért tennék? Vagy úgy gondolod, - a kiszivárgott(?) roadmapok ellenére - HT2.0-ás lesz először a kétutas Agena FX is? Sokan reklamálnak majd. Desktopon, 1-2, max. néhány task futtatása közben kritikusabb a memória-késleltetés, márpedig a másik proci ramjához való hozzáférés az egyik HT linken keresztül megy.
-
dezz
nagyúr
Szal úgy érted, az AM2 lábkiosztásában már elkülönülnek ezen plane-ek, csak a mai alaplapokon még össze vannak kötve?
(#920): Huh, ez kicsit szíven ütött:
''and after hearing our friends at the motherboard companies talk, AMD is close to near/total panic mode right now as the Q3 Barcelona product launch schedule rapidly approaches.''
De utána ez egy icipicivel jobb kedvre derített (de azért nincs teljes egyenes arány a K10 hírek és a kedélyállapotom között ):
''At the same time, others have said that an earlier stepping of the core was overclocked from 1.8GHz to 2.5GHz without too much trouble.''
És itt mondják ki a tutit, azaz hogy lényegében nem tudnak semmit :
''All in all it's tough to say what clock speeds will be possible and when, but we do know for a fact that what we saw at Computex (Barcelona) ran slower than 2.0GHz.''
(#923): Ehhez még egy kis kiegészítés. A Barcelona a 4-magos szerver változat, mégpedig többutas rendszerekbe, 3-4db HT(2.0) busszal. Budapest: ugyancsak 4-magos szerver proci, de egyutas rendszerekbe, viszont már HT3.0-ával. Agena és Agena FX: a 4-magos asztali változat. Nos ez utóbbi lesz majd Phenom X4 és FX néven a boltokban.
Apropó... Miből lesz a cserebogár? Izé, miből lesz az s.F+-os Agena FX? A Barcelonából nem, mert az HT2.0-ás... De a Budapestből sem (elvileg), mert az meg csak egyutas (elvileg)... És ha van Agena FX, akkor miért nincs kétutas HT3.0-ás szerverchip? Itt valami titok lappang!
(Nem szoktak teljesen különálló chipet csinálni csak desktopra.) Nézzük csak meg a die-shotot! 2 HT busz a 4-ből úgy van elhelyezve, hogy nem igazán lehet kihagyni, csak esetleg letiltani. (A másik kettő meg a szélén van, így könnyebben lehagyható.) Nos, szerintem a Budapestből lesz az Agena FX! Mégpedig úgy, hogy ott van szépen az a 2 HT busz, csak a Budapest ''kiadásban'' le van tiltva az egyik. De miért nem adják ki a Budapestet akkor kétutas szerverchipként is?
[Szerkesztve] -
-
#65675776
törölt tag
Nem is szerver frontról beszélek, hanem asztaliról. Itt az Itanium jóval később került volna piacra, mint az A64, viszont az MS közölte, hogy az előbb boltokba kerülő technológiát támogatja asztali fronton. Szerver szinten létezik Itaniumra írt Win. Desktopra nincs és nem is lesz.
-
Andre1234
aktív tag
Ne haragudjatok hogy visszanyúlok két napot a topicban de vettem a bátorságot hogy egy tesztel bizonyítsam én is hogy a cinebench teszt mért is nem szűri le a valóságot..
[link]
''X2 3200Mhz = X4 1600Mhz a Cinebench-ben.'' és ha két magom lenne akkor megvan az eredmény.... ott a pont!!!
Mért ezzel tesztelték???
Ez is mézesmadzag amit orrunk előtt rángatnak csak hogy minél jobban odafigyeljünk??? -
-
P.H.
senior tag
Az én álláspontom szerint az x86-család fennállását »egyedül« a kompatibilitás tartja fenn (akár visszafelé, akár egymással). Ha kijönne egy olyan generáció, amikor ténylegesen dönteni kellene a gyártók (vagy a korábbi, vagy a mostani párhuzamos generációk) között, akkor mennyien gondolkodnának el más platformon (azonos költségek mellett)? Az x86 egyetlen ütőkártyája, hogy ezt 2x éve nem adta ki a kezéből; egy Core2 futtatja az XT-s programokat.
És akárhány gyártó benne volt ebben az szegmensben, arra mindre igaz ez. Az Intel verseny nélkül a saját feldarabolásával játszik. És akkor ráadásul a daraboknak kellene egymás versenytársainak lennie.... (Kapitalista piacon mindenből kettőnek kell lennie.)
[Szerkesztve] -
Oliverda
titán
A kolléga sehol nem írta hogy ő majd a jövőben Quad procira vágyna, és ha jól sejtem nem is vágyik ilyesmire.
Nem tegnapelottol foglalkozom az iparral hogy a ''majd menni fog, tuti'' tipusu kijelenteseket keszpenznek vegyem. - Ehhez képest úgy látom hogy az ''If reports out of Taiwan are to be believed...'' kijelentésekre már többet adsz. Na mindegy, végülis a Te dolgod, semmi közöm hozzá.
-
Oliverda
titán
Várakozás a semmire?
Ahhoz képes eléggé érdekel téged is ez a bizonyos ''semmi'', mert ahogy látom sokat szóltál már hozzá a témához.
Mellesleg azt nem szabad elfelejteni hogy az ígéret szerint a jelenlegi AM2-es lapok többségében is menni fognak a procik. Pár hétből lehet pár hónap, de az is lehet hogy már két hét múlva itt lesznek az új lapok. Arról nem is beszélve hogy pl. az Intel P35 lapkészletre épülő lapok hamarabb váltak kaphatóvá, mint ahogy bemutatták volna őket. Tehát bármi megtörténhet. Az meg hogy pesszimista vagy már a Te bajod.
Ha fejleszteni kell egy C2D-s lapba ugyanugy belerakhatod majd a leszallitott aru Quad procikat ev vegen - Itt szerintem sok embert nem a 4 mag izgat, és főleg nem egy olyan aminek az apukáját rezsónak hívták. -
#770
VaniliásRönk
nagyúr
Raymond
#768
-
dezz
nagyúr
''Nem a pov-ray eredmenyekrol van szo (lasd elozo hsz). Azokbol egyebkent az 1.6Ghz eredmeny lett visszafejtve a megadott szamok alapjan.''
Tudom, csak semmi értelme, mert nem a standard módon futtatta sem az Intel, sem az AMD, így a számok nem jelentenek semmit.
Azt az ''elvileget'' talán érdemes betenni ide:
''Phil Hughes, a spokesman at AMD, said Barcelona is still scheduled to launch in the summer, which is in line with the company's previous target. The spokesman said the component Cray was referring to was its Budapest chip, which will come out in the second half of the year following the Barcelona launch.''
Eddig is valami ilyesmiről volt szó, a Cray talán a befektetőknek azt mondta korábban, hogy hamarabb jön a Budapest is.
(#746) Komplikato: mert az új procik natívan támogatják a DDR2-1066-os ramokat, amik azért fűtenek is (bár annyira csak nem, állítólag egy cég már demózott 1333-asat is - igen DDR2). szerk: kíváncsi leszek, ''mit mennek'' majd a Phenomok ezekkel... De talán az Athlonok is megérzik (főleg a Rana, ami L3 nélküli K10 [2 magos]).
(#748) Keldor papa: Ha még a teljesítményre megy, megértem a C2D-t, de mi értelme lenne ''egy jó kis C2D E4xxx vagyE21xx''-nek? Csak hogy elmondhassa, hogy C2D? LOL. Akkor már értelmesebb egy AM2+-os lap, bele egy olcsó X2, aztán később egy Phenom X2 v. X4, igénytől függően. (Az X2-kkel szerintem kevesebb gond lesz, mármint gyártási szempontból.)
[Szerkesztve] -
Oliverda
titán
-
dezz
nagyúr
Vajon ez az ''initial performance results'' véletlenül nem a POV-Ray benchmarkos téma akar lenni? (Ami semmit sem jelent, lévén tök más beállításokkal futtatták.)
Visszatérve egy pillanatra a Cray-re:
''The AMD processor's on-chip, highly associative data cache supports aggressive out-of-order execution and can issue up to nine instructions simultaneously.'' [link]
Ez meg mi akar lenni? A 4 mag összesen? Az 2.25 magonként, holott az up to 3.0, és így up to 12-nek kellene lennie 4 magra. Vagy az egész mondat a data cache-re értendő (kicsit félrevezetően)?
(Viszont emlegetik a Torrenzát is, és talán terveznek is vele valamit:
''AMD's Torrenza open innovation platform allows Cray and other partners with acceleration technology to increase system performance, scalability, and flexibility. Capitalizing on the Direct Connect Architecture and the AMD64 platform, the Torrenza initiative enables innovation within a common ecosystem. Its open socket specification allows Cray customers to use AMD Opteron processors, Cray custom multithreaded processors or FPGAs in the same high-performance fabric.'')
[Szerkesztve] -
dezz
nagyúr
''Cray's last outlook, dated May 3, 2007, noted that anticipated revenues from quad-core Cray XT4 systems and upgrades were an important factor within the company's overall revenue plan for the year, and a key risk.''
''''Two of our most important goals have been to grow and achieve profitability, both of which are now in jeopardy for 2007''
Biztos repesnek az örömtől...
-
dezz
nagyúr
Lauch event vagy sem, azért demózták a cuccot az új Opteron 2200 személyében: [link]
Ennek a csúszásnak a forrása talán csak a DigiTimes, amely ide vonatkozó hírének hitelességét sokan megkérdőjelezték.
Tudom, a Fudzilla kicsit más súlycsoport, mint ez, vagy akár az Anandtech, mindenesetre ők kicsit mást írnak erről: [link]
Mondjuk kicsit alacsony annak a 2200-asnak az órajele (1.6 GHz), vélhetően ha lenne nagyobb, azt mutogatnák. Ha igaz a csúszás, talán ezzel függ össze...
[Szerkesztve] -
sharKBITE
aktív tag
Ez annyira szép... de tényleg. Remélem legalább annyira bejön majd AMD-nek a Phenom, hogy kilábalnak a mostani helyzetükből, és újra odapörkölnek kicsit Intel bácsiék orra alá. De a topicos fejtegetések alapján úgy néz ki, hogy tényleg újra nyeregben lehetnek ha megjelennek a K10-ek. Mellesleg kész öröm olvasni a topicot, még akkor is, ha csak a negyedét értem a részletekbe menő fejtegetéseknek. Csak így tovább!
-
dezz
nagyúr
-
ftc
nagyúr
megvan az uj háttérképem
mit nem adnák azért ha már egy ilyen dobogna gépem belsejében...sztem Barcelona bemutató a jelnlegi Computexen...
azt ah beszereztem egy ilyet átkéne állni Vistára,vagy Linuxra...de sajna a szi,ulácio csak winen futnak...meggyorsitaná a számolást a 4 mag... -
P.H.
senior tag
Hogyan tudod párhuzamosítani több utasítás elejének és végének meghatározását, ha változó hosszú utasításokról van szó? Meg kell taláni az opcode byte-ot (byte-okat, mert 486/MMX/SSEx esetén a 0Fh prefix is ott van, 3DNow4 esetén kétszer is - 0F0Fop ), - és még szó sem esett még az REPZ, REPNZ, argumentum- , vagy címhossz-befolyásoló prefixek-ről, amik SSEx - x >=2 - esetében válnak fontos tényezővé- , a ModR/M által leírt címhez tartozó azonnali érték, a SIB-byte-ot, és az adathoz tartozó azonnal érték hosszát. (és ezek is 1/2/4/8 byte hosszúak, prefixről változóan).
[Szerkesztve] -
P.H.
senior tag
Nagyon jó cikk, minimális háttérismeretek birtokában érthető (= ha tudja az ember, hogy miről beszél, akkor tudja azt is, hogy mit mond). Egy kicsit zavaró, hogy micro-opokban fogalmaz macro-opok helyett.
dezz #617: K10 esetében is van result bus (írja is, hogy nem ábrázolja, mert túl bonyolult lenne az ábra tőle), result bus nélkül az egész működésképtelen lenne (INT oldalon nincs is register-rename, csak resultbus->ROB/ICU forwarding, legalább K7 óta).
dezz #619: Sajnos az Intel visszatért a PPRO/P2/P3 complex-simple-simple... (itt most még egy -simple, 4-1-1-1 micro-op) decoder felállásához. Valahogy mindig RISC-felfogású decoder-eket akarnak tenni egy x86 elejére P6 óta (Netburst alatt az egyszem decoder szűkösségét elnyomta a trace-cache), pedig pont oda kellene CISC-felfogás. Ezek szerint három egymást követő OP reg,mem típusú utasítást Core2 3, K10 1, (de még ha nem DirectPath Double útra mennének, akkor is) legrosszabb esetben 2 órajel alatt fordítaná. Itt is van egy szűk keresztmetszete, illetve a mem tagokat Core2 1/órajel (cache lehet, hogy dual-ported, de LOAD - port2- csak egy van), K10 2/órajel szélességben hozza fel Data Cache-ből legjobb esetben, akár 2x128 bitet.
akosf #619: üresben ugyan nem járnak, de nem biztos, hogy FP munkát végeznek, lévén shared INT/FPU pipe-ok (számláló, forrás- és célcímek kezelése, branch futtatása, stb...)
Pont a macro-op cache-t említettem korábban is, a fetch/decode itt majd' a pipe felét viszi el, nem csak 2-3 órajelet/stage-t. A másik ötletem, a Hyper-Threading azért játszhatna itt, mert mostmár teljesen tiszta, hogy a pack-stage-ek után nincs vízszintes mozgás a macro-ophármasokban, minden utasítás arra a portra megy, amelyik lane-en van, főleg FPU-ban teli van gap-ekkel. Ezeket tölthetné meg másik szál, INT esetén pedig az 3 micro-op/cycle miatt nem nehezedne nagyobb nyomás (INT-ben sokkal nagyobb gondot okoznak a függőségek, mint a szélesség). A branch-ágak práhuzamos futtatása sajnos nem, megintcsak amiatt, mert nincs INT oldalon register-rename.
dezz #622: 3+2+2+2-t nem tudok kiolvasni az Optimization Guide-ból, csak 3/2+2+2-t. Mivel végig 3-széles maradt a micro-architecture (3 macro-op/sor), szerintem nincs 4 decoder, a VectorPath csak ábrázolásszinten külön oszlop (vagy a 3 DirectPath, vagy VectorPath).
akosf #623: érdekes módon az FSTORE-t az idők folyamán átnevezték FMISC-re. Mindenesetre ennek van belső ROM-táblája a betölthető konstansokhoz, ez kezeli az INT->FP és FP->INT konverziókat (fild, fist(p)), és ahogy mondod, az FSIN, FCOS, ... utasítások által generált spec. micro-opokat futtatja (lehet, hogy csak ez fér hozzá a belső, programozói szinten nem látható átmeneti (scratchpad) register-ekhez?)
IPC: majdnem mondtam, hogy próbálj egy átlapolt, nem függő FPU/INT utasítássort, de azt meg a decode limitálja 3-ra.
dezz #624: azért majd meglátjuk, 65 nm-en meddig fogják felvinni az órajelet, mennyi tartalék van benne.
akosf #625: felfüggesztődik? Nem hiszem el...
SMC: egy (a? ) másik topikban zajló események miatt pár napja multi-core/multi-processor/NUMA témába ástam bele magam. SMC természetesen lehetséges (még mindig 8086 miatt, de már nem sokáig lesz ez így), AMD-nél a MOESI-szerinti cache-probe módosítás esetén kiüríti az I-cache adott vonalát (store-jellegű probe esetén az I-cache-t is ellenőrzi system-wide), és érvényteleníti a teljes CPU-pipe-ot. Ha jól emlékszem, Netburst alatt nyomta ki a teljes instruction cache-t egy SMC.
dezz #628: DirectPath-on mennek egy 1 micro-opos utasítások (3 micro-op/órajel), DirectPath Double-re a 2 micro-oposok (1.5 micro-op/órajel, lényegében ugyanaz, mint a DirectPath Single, csak 2 órajel alatt fordít), VectorPath-ra a többi. Csak ennyi a szabály.
akosf #629: OP reg,mem már 2 micro-op Intel-nél. Most hivatkoznék megint a fenti IDCT-kódomra, sokszor elemi utasításoknál sem férnek el a konstans-ok a 8(/16) XMM-registerbe.
Igen, kb. annak felel meg, aminek leírtad. Csak AMD esetében van DirectPath Double, és sokkal több minden fér bele valamelyik DirectPath-ba, K10 esetén meg már főleg).
Első gondolatom a cikk után az volt, hogy vagy nagyon rááltak a server-piacra, vagy hamarosan több CPU-s rendszereket akarnak látni az otthonokban.
[Szerkesztve] -
dezz
nagyúr
Hmm, Core2 esetén fel van tüntetve egy bizonyos Internal Results Bus, a K10 esetén az ilyesmi hiányzik az ábrákról.
A végkövetkeztetésekben meg egy szó sem esik a natív 4-magosság mellett a másik legfontosabb változás, a kiemelkedő floating-point (SIMD) teljesítmény mind desktop, mind munkaállomás, mind szerver vonalon jelentette előnyről.
(#611) 7600GT: nemrég még ''lázadtál'' a technikai szöveg ellen, most meg egyenesen igényedet fejezed ki? Bár nem tudom, vállalkozik-e Raymond egy 10 oldalas, tömény technikai szöveg pár mondatba sűrítésére. -
P.H.
senior tag
Csúsztatások egy bizonyos szint alatt nem szoktak lenni, csak mese, mese vég nélkül (mint az intelligens mosópor... legiknkább a könnyebb megérthetőség miatt, mondjuk a CPU azért elég intelligens dolog) Sokszor jó, ha az ember megpróbálja lehozni ezeket a meséket is tranzisztor-szintre.
[Szerkesztve] -
#95904256
törölt tag
Hali Raymond!
Az ''ars technica'' cikk valóban érdekes, de első neki futásra kicsit gyanúsak voltak azok a kifejezések hogy: I'm guessing; I'm currently assuming; I'm suspect, ...
Szóval kicsit megmozgattam a Core2 lebegőpontos SSE műveleteket végző egységeit.
100.000 (8x12.500) műveletet végrehajtva az alábbi idők jöttek ki:
ADDPD reg0-7,mem -> 1,1 órajel / utasítás
DIVPD reg0-7,mem -> 31,1 órajel / utasítás (itt már jelentős a várakozás)
MULPD reg0-7,mem -> 1,1 órajel / utasítás (na, ezt hogy csinálta?!)
XORPD reg0-7,mem -> 1,1 órajel / utasítás
SQRTPD reg0-7,mem -> 57,2 órajel / utasítás
Gondolom az 1,1 órajelből az 0,1 azért jött be mert nem volt egy 9. regiszter a további latency time átlapoláshoz. Ha egy ADDPD 3 órajelig tart, és 1 órajeles átlag jött ki akkor hány DP (64 bit) összeadó dolgozott egyszerre? 6...
A MULPD-s mérést többször is átnéztem. Hibátlan eredménynek tűnik. Viszont ez azt jelentené hogy egyszerre 10 DP szorzó egységnek kellett működött. Ez szerintetek lehetséges? Tényleg ilyen ''FPU monster'' a Core2? -
Rive
veterán
Leginkább kapacitásra. Mondjuk egy per-thread dedikált L1Dcache/ICache jó - és: durva - lenne
![;]](//cdn.rios.hu/dl/s/v1.gif)
Itt=IMC.
Ui.: az a gond, hogy igazából semmi olyat nem látok, ami indokolná a K8 -> K10 nevezékváltást SZVSZ csalódás lesz a cucc, ha nem jön be még valami a képbe.
[Szerkesztve]
:
A K8-féle 65nm-es állítólag csak egy gyors, átmeneti megoldás volt, nem kihasználva az összes kicsinyítési lehetőséget, így ahhoz nem annyira érdemes hasonlítani. Ha viszont azt vesszük, hogy ahhoz a bizonyos Rev. F-hez képest 50%-ra kicsinyítés helyett kb. 75%-ra kicsinyítettek, az azt jelenti, hogy a bővítés nélküli állapothoz képest 50%-kal nagyobb lett.
![[kép]](http://www.amd.com/us-en/assets/content_type/DigitalMedia/43263A_low_res.jpg "[kép]")
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Az ide nem illő hozzászólások topikja:[link]
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva.
- Autós topik látogatók beszélgetős, offolós topikja
- Éjszakai műszak
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Gyúrósok ide!
- Óvodások homokozója
- Anime filmek és sorozatok
- HiFi műszaki szemmel - sztereó hangrendszerek
- Milyen légkondit a lakásba?
- Abarth, Alfa Romeo, Fiat, Lancia topik
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- További aktív témák...
- Ritkaság! Csere-Beszámítás! Intel I9 13900KS Processzor!
- Intel Core i7 10700 - 4.8 GHz - 8mag/16szál - Eladó!
- Intel Core i9-14900KF 24-Core 3.2GHz LGA1700 Box (BX8071514900KF) Processzor! BeszámítOK
- Intel Core i7-8700K 6-Core 3.7GHz LGA1151 (12M Cache, up to 4.70 GHz) Processzor!
- Intel Core i7-12700K BOX LGA1700, 12/20 mag BONTATLAN, 3ÉV
- REFURBISHED - HP USB-C Universal Dock G1 docking station (DisplayLink)
- Bomba ár! Dell Latitude 5430 - i7-1255U I 16GB I 512SSD I HDMI I 14" FHD I Cam I W11 I NBD Garancia!
- BESZÁMÍTÁS! NZXT Kraken Elite 360 RGB vízhűtés garanciával hibátlan működéssel
- Motorola E40 64GB, Kártyafüggetlen, 1 Év Garanciával
- 14" Dell Latitude laptopok: 5400, 5480, 5490, 7480, E7440, E7450 / SZÁMLA + GARANCIA
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest