- 200 megapixeles zoomkamerát sem kap az S26 Ultra?
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Motorola Edge 60 és Edge 60 Pro - és a vas?
- Redmi Note 13 Pro 5G - nem százas, kétszázas!
- Okosóra és okoskiegészítő topik
- Xiaomi 15 - kicsi telefon nagy energiával
- Samsung Galaxy Watch7 - kötelező kör
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Nem növel telepméretet a Galaxy S26 Ultra
- Hivatalosan is bemutatta a Google a Pixel 6a-t
-
Mobilarena
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
fLeSs
nagyúr
válasz
Raymond
#4578
üzenetére
Elvileg most az AMD illetve az IBM sincs lemaradva.
"This new approach to implementing high-k/metal gate will be available to IBM alliance members and their clients in the second half of 2009. **"
"**All future dates and specifications are estimations only; subject to change without notice."
szerk: megnéztem a videót dezz oldalán, és a végén asszondják benne, hogy a 32 nm-es techet már felhasználhatják 3D-s chipek készítésére.
erre várok már egy ideje, az lesz az igazi áttörés!
-
fLeSs
nagyúr
válasz
Raymond
#4541
üzenetére
"Alapbeallitasok mellett is sirnak."
ezért írtam, hogy be kéne állítani rendesen a gépet.
ha ez a dolog igaz lenne, már akkora botrány kerekedett volna belőle, hogy processzorvisszavonásról, kártérítésről beszélhetnénk, mint anno a pentium idejében.
a kis TLB-s hibát hogy felkapta a sajtó? ehhez képest erről egy szó sincs sehol. -
Oliverda
titán
válasz
Raymond
#4531
üzenetére
Az újabbak tényleg gyengébbek. Nekem is nagy szerencsém volt hogy el tudtam cserélni a 0749-es csereprocimat egy régebbi, 0743-asra. A 0749-es 2.6GHz-et sem tudom 1.4V-nál, ez 2.8-at tud 1.3V mellett. Olyasmit olvastam hogy a régebbiek azért jobbak mert amikor még azokat gyártották terveben volt a 9700es is, sőt ugye néhany oldal kapott 9900-es ES-t is ha jól emlékszem.
-
-
fLeSs
nagyúr
válasz
Raymond
#4499
üzenetére
Jó, nem volt szerencséjük.
De ez még nem változtat a tényen, hogy az AMD ilyen magas feszültséggel nem adna ki Phenomot, mert kiválogatnák a jobbakat.
Ezért amit a toms mért nem releváns arra nézve, hogy egy gyári Phenom 9700/9900/10812 mennyit fogyasztana, márha létezne. -
fLeSs
nagyúr
válasz
Raymond
#4496
üzenetére
Ez a mérés is egy ökörség, én ezért nem szoktam tuningolt procival fogyasztást mérni.
1,25V-ról 1,4V-ra emelték a feszt, ez +12%.Egyrészt ilyen magas fesszel nem kerülne forgalomba Phenom, nekem pl. 2,8-at ment 1,3V-on, annyi eszük lenne, hogy kiválogassák a jobbakat, másrészt a feszültséggel négyzetesen emelkedik a fogyasztás.
órajelben +17%
feszültségben: +12%. -
dezz
nagyúr
válasz
Raymond
#4496
üzenetére
Na, ez már legalább valami. Bár ez is elég hihetelen. Az az alap 98W is sok, tekintve a 9700-asokra megadott 95W TDP-t, nem gondolod?
(A kép nálam nem jött be.)
Az ésszerű érvekre mindig nyitott vagyok, te ilyennel nem szolgáltál. Illetve szolgáltál, de 1-2 ponton hibás volt. Arról nem tehetek, hogy nem bírod elviselni, ha rámutatnak az érv(elés)ed hibájára, amire állandóan teljesen infantilis módon besértődsz.
-
dezz
nagyúr
válasz
Raymond
#4483
üzenetére
Kár, hogy téves volt a levezetés, mert 1., elsősorban nem a fesz növekedése miatt van fogyasztás-ugrás pl. a 9700 és a 9600 között, hanem a magasabb NB freki miatt; 2., a 140W TDP nem azt jelenti, hogy 140W-ot fogyaszt, hanem hogy a 140W-os TDP osztályba tartozik, azaz már nem fért bele a 125W-osba, pl. 130W-ot eszik. Továbbá az is világos, hogy nem a fogyasztás itt az elsődleges probléma (amiről te beszéltél), hiszen tuninggal is alig megy 3 GHz-t. De azért csak fényezd magad tovább nyugodtan; és mindenkit, aki nem ért veled egyet, nevezd csak aminek akarod, ha ettől jobban érzed magad.
-
Gyuri27
félisten
-
naffeju
csendes tag
válasz
Raymond
#4246
üzenetére
Akkor tagolom, hogy a külföldiek is megértsék:
A Shanghai szilíciumon létezik, legkésőbb január eleje óta. Sőt, hadd idézzem Ruiz pápát:
"It is exciting to point out too that at the same time, we’ve had silicon on a quad-core 45 nanometer product that we’re as pleased with the results"
(gyk: Egyúttal izgalmas rámutatni, hogy elkészült egy négymagos 45 nanométeres termék szilíciumon és elégedettek vagyunk az eredménnyel)
Aztán Meyer érseket:
"We’ve got internal samples of our 45 nanometer microprocessors, we’re putting them through their paces"
(gyk: Belső használatú mintapéldányaink vannak a 45 nanométeres mikroprocesszorainkból, jelenleg teszteljük őket)
Hogy Q2-ben tömegtermelésbe megy, az ellen azért fogadnék mondjuk néhány deákkal. Először is féléves validációs idő az rettenetesen rövid, ez azt feltételezi, hogy minimális változtatás történt architekturális szinten, egy elektronikai újraimplementáció történt gyakorlatilag. Másrészt a Barcelona termékéletciklusa ezzel 2 negyedév se lenne, ez elfogadhatatlanul rövid a partnereknek. Q2-es termelés és Q3-as rajt négymagos Phenomnál elképzelhető szerintem.
-
dezz
nagyúr
válasz
Raymond
#4274
üzenetére
És még el is fért volna...?
Na ja, szervereknél jól jön az a L3. De a 2-8 utas K8-Opteronos konfigokban sincs olyan, mégis "elvannak".Desktopon meg jóval kevésbé számít, K10-ből is terveztek L3 nélkülit a 2-magosok között (Rana). L3 helyett lehetett volna 1MB L2-s K8-ból építkezni.
Nem mondom, hugy ugyanolyan jó lett volna, de sokkal korábban piacon lett volna.
fLeSs: Azért korábban is időbe telt az órajel emelése. Szóval max. azt tehették volna meg, hogy várnak, amíg magasabb órajeleket érnek el + jobban felfut a gyártás, és akkor dobják piacra. (Mint az Intel - az utóbbi években.) Nem? Most ugyanúgy nem lett volna jó megvárniuk, amíg ki tudják hozni a 3 GHz-est. Sokmindenben más a helyzet, de ebből a szempontból hasonló.
-
dezz
nagyúr
-
fLeSs
nagyúr
válasz
Raymond
#4255
üzenetére
OK, és a Cell PPE-je is képes a cache-t különböző módokon kihasználni, területeket elkülöníteni xy módon az egyik szál számára, míg a többi szál a megszokott módon használja azt? Van közvetlen útvonal a GPU és az L2 cache között? A rendszerbusz és a regiszterek között?
-
#3954
shabbarulez
őstag
Raymond
#3952
shabbarulez
őstag
válasz
Raymond
#3952
üzenetére
A mobil procinál nem véletlenül van 35W TDP, az asztali 65W TDP helyett. Az 2.8 Ghz-es mobil modell ez alapján bele is fog férni. 2008Q3-ban pedig jön majd a javított 45nm-es gyártástechnológia, ott már 25W TDP-s modell is lesz 2.53Ghz mellett. Jól látszik hogy itt nem csak lineáris órajel csökkentésről van szó, hisz az alapján max 25/35*2.8Ghz=2Ghz-es proci jönne ki ilyen TDP-vel, nem pedig 2.5Ghz-es. Ez a szokásos félidőben érkező gyártástechnológia javítás, P1266->1267 amit korábban is a mobil eszközöknél használnak, azért is késnek ezek az eszközök mindig a desktophoz képest. De biztos lesz ennek pozitív visszacsatolása desktop fronton is, ahogy 65nm-nél is volt.
-
#3917
csatahajós
senior tag
Raymond
#3893
csatahajós
senior tag
válasz
Raymond
#3893
üzenetére
Ez komoly? : "teljesn eltuntetette roluk (Bulldozer)" - van esetleg linked egy ilyen roadmaphez?
Ez igazán nagy lábonlövés lenne a részükröl
, ahogy fless is írta ha a Nehalem-mel csinálnak egy szerverprociként is jól mükődő cuccot Intelék (elvileg a quickpath sikerén/implementálásán múlik ) akkor AMDéknek tényleg annyi -a,ot mindannyian nagyon sajnálnánk.Mit gondoltok az IBM vagy valaki más nem fog mentőövet dobni AMDéknek?
-
dezz
nagyúr
válasz
Raymond
#3893
üzenetére
"3) "shipments in the second half" annyit jelent osznel hamarabb nem latsz termeket. Ha ugy lenne akkor azt mondtak volna Q3"
Igen, és mikor is jön a Nehalemből a csúcs és a mainstream...?
Oké, nyilván semmit sem lehet készpénznek venni, főleg AMD-nél mostanában.P.H.: Elvileg 2008Q2-ben jönnek a kétmagosak.
Tudjátok hogy van, mostanában a quad-core az IT buzzword - és az olyan gyártók, mint Dell, HP, stb., akik most újra szóba állnak az AMD-vel is (Intel kénytelen volt engedni), elsősorban a négy-magosakra hajtanak, valószínű azt tudják a legnagyobb haszonkulccsal forgalmazni. Az AMD is elsősorban ettől az üzlettől vár nagyobb bevételeket az asztali szegmensben.
-
dezz
nagyúr
válasz
Raymond
#3891
üzenetére
No és ez elkerülte a figyelmedet - ugyanarról az oldalról?
"AMD executives are already on the record saying the ramp of 45nm production will begin in the first half of 2008, followed by shipments in the second half."
"And statements have gotten bolder since then indicating that AMD may be further along in development than previously thought. In a recent interview with CRN, AMD executive Mario Rivas said that AMD will have initial "Rev C" samples in January that may be bootable."
-
#3890
shabbarulez
őstag
Raymond
#3888
shabbarulez
őstag
válasz
Raymond
#3888
üzenetére
Valóban voltak ilyen hírek is. De nekem úgy tűnt hogy ahogy tolta egyre hátrább AMD K10 2 magosok megjelenését, 2007 novemberről, 2008 márciusra majd legutóbb júniusra, úgy jelentek meg olyan hírek Nehalem mainstreamről is hogy az is tolódik 2009Q1-ről H1 majd legutóbb H2-re. A háttérben gondolom az áll ha AMD nem tolja a szekeret Intel sem erőlködik, hanem bevárja. Ővék a piaci elsőség desktop és mobil fronton, nincs hova sietniük, a Penryn életciklusa nagy valószínűséggel hosszabb lesz mint ahogy eredetileg tervezték, más kérdés hogy akkor mi lesz majd a 2 éves tic-tac modellel.
Szerver front más ott nincs egyértelmű elsősége Intelnek, ezért a Nehalem szerver család tuti nem fog kitolódni, az meg fog jelenni 2008Q4-re. Mert szükség van rá hogy az utolsó piaci szegmensben is bebiztosíthassa az Intel piacvezető szerepét.
-
dezz
nagyúr
válasz
Raymond
#3882
üzenetére
1) Végülis akár az is lehet, hogy nem sokkal utána...
Egyébként meg nem "140W-os" az a 9900, hanem 140W TDP osztályú. Lehet, hogy a valós (szuper-csúcs) fogyasztása 126W. (Lásd pl. LostCircuits-os mérés, ahol 115W-ot evett full terhelésen.)4) Elvileg addigra az AMD is elkezdi a 45nm-es gyártást.
-
dzsi2006
tag
-
#95904256
törölt tag
válasz
Raymond
#3819
üzenetére
Az számomra is egyértelmű hogy az újabb és újabb steppingek azért jönnek ki mert jobb lesz tőle a termék. Egyébként a K8-nál szerintem is szép fejlődést látthattunk, de ez ott sem egyszerre következett be. Ha ezt veszem alapul, akkor a K10-nek kelleni fog minimum egy év 20-30%-os órajel növekmény eléréséhez.
-
-
-
#3628
shabbarulez
őstag
Raymond
#3626
shabbarulez
őstag
válasz
Raymond
#3626
üzenetére
Ezek a TDP-k amik azóta úgy tudom nőttek, pl. a 95W 115W-ra változott, szóval ezek még novemberi gyártásra alapozott értékek. Ahogy az adott gyártástechnológia fejlődik, egyre jobban kiismerik a sajátosságait, úgy tudnak belőle egyre többet kifacsarni az újabb steppingekkel. Épp ezér 2008Q2-Q3-ra egyáltalán nem elképzelhetetlen hogy ez megoldódik és jóval kisebb feszültség mellett lehet majd elérni egy órajelet, így a TDP is kordában tartható.
Gondolj arra hogy az Intel is 2006 novemberében 2.66Ghz-ig tudta skálázni a 4 magosát, annak is 130W volt a TDP-je, gyanítom a 3Ghz-es azért nem jött ki mert az már messze e fölött lett volna. De az idén júliusban kihozott új steppinggel ez már nem volt gond, az új G0-ás stepping modelljei jóval húzhatóbbak lettek mint a korábbi változatok, köszönhetően annak hogy az eltelt időszak alatt többet tudtak kicsiholni a gyártástechnológiából.
-
#3622
shabbarulez
őstag
Raymond
#3618
shabbarulez
őstag
válasz
Raymond
#3618
üzenetére
Szerintem lesz, csak nem olyan gyorsan ahogy az AMD szerette volna. Az Intel is elérte ezt a Ghz-et, miért nem sikerülne az AMD-nek is. Azért nem olyan béna cég az. Csak ki kell futnia magát a gyártásnak, ugyanúgy ahogy X2-nél is eljutottak igen magas Ghz tartományba, csak idő kérdése volt. Szerintem ugyanez lesz K10-zel is 2008Q2-Q3-ra szerintem lesz 3Ghz-es FX. És kell is hogy legyen mert a 45nm-es desktopok eljöveteléig ki kell húzni valamivel, az X2-re nem lehet a végtelenségig építeni. Márpedig az X2 életciklusát is most kényszerűen meghosszabítják, hisz kell egy áthidaló 6 hónap amíg a K10-es X2-esek még kijönnek és addig valamivel bevételt kell termelni, ezt pedig csak úgy lehet elérni, ha minél nagyobb mértékben 65nm-ra alapuló, gazdaságosabban gyártható 2 magos termékekkel teszik.
Az más kérdés hogy a 2-3 negyedév múlva elért 3Ghz-es termék mire lesz elég a piacon, addigra elég megkésett lesz. Ahogy az AMD gyártástechnológiája is "összeérik", úgy az Intel 45nm-ese sem fog egy helyben toporodni ezen negyedévek alatt. Könnyen lehet hogy addigra már alulról fogják nyaldosni a 4Ghz-et, ha valóban szükség lesz rá. Átlépni nem hiszem hogy fogják, ez a marketing fegyvertényt meg fogják hagyni a Nehalemnek.
-
-
P.H.
senior tag
válasz
Raymond
#3408
üzenetére
Igazad van, a Revision Guide-ok nem egészen naprakészek, a legfrissebb K8-as (2007 október) sem.
Ez az egész kezd hasonlítani egy szappanoperára. Kezdve ott, hogy:
"Saucier clarified the exact nature of the workaround for the erratum that AMD has provided to motherboard makers and PC manufacturers. The fix comes in the form of a BIOS update, and this BIOS patch includes an update to the CPU microcode."És
"Because the hardware bug—known as an erratum—affects all revisions and clock speeds of AMD's quad-core processors, it affects the newly introduced Phenom 9500 and 9600 processors, as well. And although AMD is no longer shipping quad-core Opterons to major server vendors and general customers, it is shipping Phenoms to large PC builders and distributors."
Az Opteronok alacsonyabb órajelen mennek, mint a Phenom-ok, de náluk több a magasabb terhelés esete, mint asztalon. És "Saucier flatly denied any relationship between the TLB erratum and chip clock frequencies."No most szétnéztem a Tyan server-oldalán: a Thunder h2000M S3992(-E) november 19-én kapott új BIOS-t (a szeptember 12-ei BIOS-ok óta támogatják a Quad-Core Opteronokat), a szeptember 14-én útjára indított (Thunder/Tomcat) h1000E sorozat november 13-án kapta az újat. A (nekem sokat sejtető; az Asus gyakorlatilag 'dobta' az összes nV3600 lapját a négy socketes megoldása kivételével, az nV2200-as Socket F-es lapok támogatják a K10-et) 'nVidia 3600 NPF' alatti Thunder n3600R (S2912)-nél ez olvasható BIOS-update alatt:
2007/08/14 S2912_v300 v3.00
TYAN Thunder n3600R (S2912) BIOS V3.00
New features and Fixes:
* Updated AGESA code to v3.1.1.0
* Added AMD Quad Core CPU Support*
*Note: Must use AMD Barcelona B3 stepping CPU's (or later) for Quad Core Support
[/I]
Akár ebből is gondolhatom, hogy a B3 stepping-en (és a hibán) nem november 19-én kezdett el gondolkodni az AMD...Az Asus részéről (esküszöm, az elmúlt két-három héten a Quad-Opteron logo-k ezen az oldalon kiszúrták az ember szemét, a felsoroltak mind szerepeltek ott, quad-támogatással):
- KFN4-D16(/1U): legutóbbi BIOS 2007/05/24
- KFN4-D16/SAS: legutóbbi BIOS 2007/07/03
- KFN4-DRE: legutóbbi BIOS 2007/11/07 (1.Fix Barcelona BA cpu revision is unknow. 2.Fix Barcelona B2 cpu revision is unknow.)
- a 4x4 kukába került
Ez vagy azt tükrözi, hogy vagy az Asus-lapok fél éves BIOS-szal (tökéletesen) támogatják a K10-családot, vagy az Asus 'szívózását', vagyis inkább komolytalanságát szemlélteti.
Mindenesetre a Newegg (tárolt oldal persze) kora ősszel még árult kombó Asus KFN5-D SLI-t + Barcelona-t. -
P.H.
senior tag
válasz
Raymond
#3405
üzenetére
Nem hiszem, hogy újabb lenne a probléma, ezt a .PDF-et majdnem egy hónapja mentettem le (a korai K8-as MOVS hibára kerestem forrásokat), most csak azt néztem meg, hogy nincs újabb az AMD oldalán, tehát a B2-vel alig változott az errata-lista.
(Hogy 'most derült rá fény'? Mese vég nélkül, ahogy korábban említettem.
) -
ftc
nagyúr
válasz
Raymond
#3402
üzenetére
Szal amit tudnak gyártani az megy a kormányhivataloknak és szervezeteiknek Nasa,CIA stb..
Ez a K10 amit kiküldtek tesztekre is van egy érzésem nem a végleges K10 volt...nehéz a gyártás sajna...Intel is ezértn em válalta bePhenomot lehet kapni felénk is végre 9500-s ára átszámolva 57K a 9600-s 8K-al több 9700-s állitolag olcsobb lesz mint 9500
-
P.H.
senior tag
válasz
Raymond
#3399
üzenetére
Ez lehet: 254: Internal Resource Livelock Involving Cached TLB Reload
Description: Under a highly specific and detailed set of conditions, an internal resource livelock may occur between a TLB reload and other cached operations.
Potential Effect on System: The system may hang.Bár a virtualizációs hibát (INVLPGA of A Guest Page May Not Invalidate Splintered Pages) a B2-re elméletileg kiküszöbölték, több más, hétköznapokat is érintő hiba is lehet még (244: A DIV Instruction Followed Closely By Other Divide Instructions May Yield Incorrect Results, 260: REP MOVS Instruction May Corrupt Source Address, 278: Incorrect Memory Controller Operation In Ganged Mode)
280: Time Stamp Counter May Yield An Incorrect Value - ezen akár is mosolyogni lehet
-
dezz
nagyúr
válasz
Raymond
#3337
üzenetére
Nos, mint láthatjuk ezekből a tesztekből, a Penryn híres Radix-16 enginje által nem gyorsabb lett az osztása, mint a K10-é, hanem ezzel lett egyenértékű, és előzőleg volt lassú...
Az is látható (újfent), hogy az Intel compilere, és a saját procinak kedvezése is jópár százalékot nyom a latban a különféle programokban.
-
dezz
nagyúr
válasz
Raymond
#3333
üzenetére
Tényleg érdekes, hogy ugyanaz a codec verzió (6.7) itt csak 25%-ot gyorsul a full search SSE4 módjában az SSE2-höz képest, miközben a Techreportos cikkben 40%-ot. (Csak nem direkt olyan forrást kerestek, ahol a lehető legjobban ki tud jönni az SSE4 előnye?
)De én (félig-meddig) megkaptam a választ: igen rossz a codec (mondjuk a többi is) multithreadingben, egészen minimálisan gyorsul tőle Intelen 1 vs. 2 vs. 4 magon; AMD-n jobb a helyzet, de közel sincs ott sem az 100%-os gyorsuláshoz. Csak nem tudom, mitől, mert sávszél [gondolom, itt inkább ez játszik szerepet, semmit a latency] még úgy tűnik, van bőven.
yoid: Tesztek? Ebben és ebben a topikban találhatsz linkeket tesztekre.
-
dezz
nagyúr
válasz
Raymond
#3299
üzenetére
"Nem."
Önmagában nézve: de."Mar irtam hogy egy 8mag/4socket Opteron rendszer (2x 2Ghz 8212 CPU) erdemenye (72 [link] )"
Ezt már később írtad."is messze magasabb mint a 8mag/2socket Xeon eredmenye. Szerinted a K8 FPU-ja annyival jobb lenne mint a C2-e hogy ugyanazon a frekvencian ugyanazzal a mag mennyisegel kb. 28%-al nagyobb osszteljesitmeny ad?"
Itt már igencsak más körülményekről beszélünk, még ha a magszám meg is egyezik. Itt már nem 2:1 az arány a memóriavezérlők számának tekintetében, mint mind a 2x2 mag K8 vs. 2x2 mag C2, mind a 2x4 mag K10 vs. 2x4 mag C2 esetében."Vagy ott van meg peldaul az a teny is hogy a 77.3-as ( [link] ) Barcelona eredmeny csak 7%-al magasabb az ugyanannyi magot tertalmazo K8 rendszernel. Errol mit gondolsz?"
1. Utóbbinál szintén 2x annyi memóriavezérlő van a rendszerben.
2. Nem láttam ezeket az eredményeket, így nem foglalkoztam vele. Talán előbb kellett volna felhoznod, ahelyett, hogy kapásból a hülyének nézést forszírozod.
3. Talán azt is mutatja, hogy nem nagyon használják ki ezek a tesztek a szélesebb FPU-t, azaz nem igazán 128 bit SIMD-esek."Hat...nem szerepel jobban:
2x Opteron 2350 = 88.3/77.3 link
2x Xeon 5335 = 92.2/78.1 [link]"
Ne zavarjon, hogy az egyik Auto Parallelizáló, új Inteles fordítóval született, a másik meg pgcc és egyéb compilerekkel... A "jobban"-t különben is úgy értettem (az előzőekben láthattad), hogy magához képest, "ledolgozva" a nem-rate int tesztben kijött 31%-os Core előnyt."Eddig is vilagos volt. Csakhogy 4mag/1socket K10-es fp_rate teszt eredmenyek nincsenek es soha nem is voltak publikalva. Tehat ilyen eremenyekre nem hivatkozhatsz. Ha leirod hogy 'Lásd SPEC_FP és főleg SPEC_FP_RATE teszteredmények.' akkor csak azokat lathatod amik leteznek."
LOL, mint látod, a SPECfp-re is hivatkoztam, mint amiben szintén jobb (non auto-paralellized esetben 9%-kal jobb is!). Előállhat szerinted olyan helyzet, hogy mind fp-ben, mind 2-procison futtatott fp_rate-ben jobb valami, de 1-procis fp_rate-ben nem? Azt egy szóval sem mondtam, hogy a többutason mért fp_rate-et 1 procira kell vetíteni. Nem is foglalkoztam vele, van-e 1-procis fp_rate teszt, vagy nincs."Vili, az az eletcelom hogy veled vitazzak az internete kizarolag abbol az okbol hogy ne aludj nyugodtan"
Hát, legalábbis te nem aludtál nyugodtan, ha északa 2-kor is ezzel foglalkoztál...
"Upsz, ezt elirtam. Arra koncentraltam hogy a *letezo* rate eredmenyeket nem hasznalhato a 4mag/1socket K10 eredmenyek megsaccolarasara de valahogy az a fenti badarsag jott ki belole. Pardon."
Raymond mode ON: ááá, csak magyarázkodsz! Már hetek óta folyamatosan azt hangoztatod, hogy a rate eredmények nem érnek semmit, és csak a nem-rate tesztekkel foglalkozzunk... Holott ez ugyanolyan semmitmondó lehet egy egész többmagos proci esetén, tehát ugyanúgy nem lehet belőle saccolni erre vonatkozóan."a Mandelbrot nem egyszalas."
Próbáld értelmezni a mondatot - egy szóval sem mondtam, hogy az 1-szálas."A HT nem jatszik semmilyen szerepet a memoria latency-nel sem pedig savszelessegben egy 4mag/1socket K10 rendszernel. A tobb socket-es rendszereknel igen, de ahogy itt tuzetesen kifejtetted nem azokrol beszelsz."
Előzőleg általánosságban beszéltem a rate tesztről (lásd #3237, amiben leírtam, hogy a rate annyi magon tesztel, amennyi a rendszerben van), és később kezdtünk konkrétabban a 2-procis rendszerekről beszélni. Egyébként az, hogy te kapásból a HT-vel jöttél, meg a rate tesztek diszkvalifikálásával, és a sima (1-szálas) tesztek forszírozásával jöttél, az is erősen arra vall, hogy nem nagyon jutott el akkor még a tudatodig, hogy 1 tobbmagos proci teljesítményét is a rate tesztek adják vissza."?? Nem is vittatam soha. Ha szerinted igen akkor ird mar meg hogy hol legyszi."
Egy ponton úgy tűnt, de mindegy, hagyjuk (nem egyértelmű, mert miközben én memória(hozzáférés)-intenzivitásról beszéltem, te sávszélről)."Wow. A rate tesztek system bound. Direkt arra talaltak ki oket, nem kell eredmenyek tanulmanyozasaval "latni" es megvilagosodni. Ezt mar le is irtam az elejen."
Nem ez volt a kérdés. (Ezt különben sem vitattam eddig sem, hanem azt próbáltam közölni, hogy hiába nagyobb a sávszél, jobb latency, ha az FPU gyenge - ezt próbáltam bizonyítani azzal is, hogy pl. az int_rate teszeknél nem jön ki a rendszer jobbsága [persze mint utóbb kiderült, szépen kijön ott is])."Nezegesd meg a SPEC-et mert rohadtul nem mindegy hogy egy base vagy egy peak eredmenyrol beszelunk."
Alapvetően persze nem mindegy, de ha hasonlóak az arányok, akkor gyakorlatilag mindegy, melyiket használjuk az összehasonlításra.akosf: Lényegében arról, vajon a sima vagy a rate tesztek alkalmasabbak-e két proci összehasonlítására. Mivel a sima tesztek 1-szálasak, azaz csak 1 magot tesztelnek, miközben a rate teszt annyi szálat futtat, ahány mag jelen van, így nyilvánvalóan a rate teszteket kell használnunk. Ezt már a legelején leírtam (meg már korábban is). Az egy másik dolog, hogy jelenleg nincsenek 1-procis teszteredmények.
A többi töltelék szövegelésben Raymond majd összetöri magát, hogy hülyének állítson be, de a nagy igyekezetben időnként magából csinál azt.
-
dezz
nagyúr
válasz
Raymond
#3290
üzenetére
Basszus, nem veszed észre, hogy nyitott kapukat döngetsz? Ha nem vetted volna észre, az előzőekben előkerültek a nem-rate számok, amik megmutatták, hogy 1 szálon nem erősebb a K10.
"Pontosan. Eleg faraszto hogy a sajat szavaidat nem ismered el, pedig itt vannak par hozzaszolassal odebb."
Valamit elismerek, de azt biztos nem, ami csak te adsz a számba.'Csak úgy emlékeztem, a sima (1-szálas) SPECfp teljesítmény is valamivel jobb volt, mint a másiké, csak a rate (többszálas) még jobb.' <- Ez itt múlt idő...
"Belinkeltem a szamokat neked. Lattad hogy az egy szalas eredmeny nem jobb? Igen vagy nem?"
De, ba***eg, láttam. Sőt, magam is előkapartam számokat a fLeSs linkjét követve. Sőt még összehasonlításokat is tettem. Szerinted mindazt csukott szemmel vittem véghez?"Hogyan magyaraznad meg a pusztan 40% elonyt a Xeon eseteben ketszer annyi maggal sajat maga es a regi K8 ellen ha az fp_rate teszt nem elsosorban a memoria savszelessegtol fuggene?"
Belátom, jobban el kellett volna gondolkodni ezen, de én inkább arra a részére koncentráltam, hogy ha a jobb memória-elérés egy szintre hozza a gyengébb K8-at a 2-magos Xeonnal (2-2db), akkor a hasonló felállású (2-utas) Barcelona vs. Clovertown meccsben mutatkozó jelentős Barcelona előny arra vall, hogy önmagában is jobb az FPU-ja. Nem találod ezt logikus gondolatnak?Az int_rate-tel kapcsolatban mindketten tévedtünk, mert éppenhogy ott is jobban szerepel a (2-utas) Barcelona (ha nem is feltétlenül a nagyon sávszél miatt, hanem általánosságban a jobb memória-elérés által, amiben benne van az alacsonyabb latency is).
"Szoval tobb socketes fp_rate eremenyeket 1 processzor FP (SIMD vagy sem) teljesitmenyenek megitelesere hasznalni badarsag."
Igen. De miből is gondoltad, hogy én nem így gondolom? Figyelmedbe ajánlanám a legelső ide vonatkozó megjegyzésemet:
'Lásd SPEC_FP és főleg SPEC_FP_RATE teszteredmények.' (#3226)
Szó sincs itt többutas rendszerekre vonatkozó RATE eredményről. De egy 4-magos proci teljesítményének megítésésére igenis a RATE eredményeket kell nézni.
Az ide vonatkozó következő hsz-emben (#3237) le is írtam, miért:
'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?'Világosodik már valami?
"Nezd nem en allitottam badarsagot az elejen es nem en vagyok az aki most probalja uj es uj kondiciokkal valahogy bemagyarazani hogy nem is azt irta amit irt."
Igenis nem írtam badarságot, csak te szépen rosszhiszeműen félreértelmezted, több ponton is. Igencsak rosszhiszemű személy vagy, úgy látszik. "Ehez lasd a fenti peldat (K8/K10/Xeon eredmenyek). Nem bagatelizalom. Azt irtam mar le nem egyszer hogy az 1 CPU 1 socket teljesitmeny megitelesere alkalmatlan a felepitese miatt."
Ez hülyeség! A sima teszt 1 magot tesztel, de egy többmagos prociban több mag van.
"Ezt nem is vitattam soha."
Akkor miért is az 1-szálas SPEC-t, meg ilyen Mandelbrotokat erőltetsz?"Nem mondtam hogy a latency nem szamit, azt montam a savszelesseg nem szamit. A latency-t te keverted bele miutan az Int eredmenyekkel akartad alatamasztani azt az allitasod hogy az fp_rate teszteknel sem a savszel szamit."
Basszus, vedd észre, hogy az "ilyen alapon" kezdetű kijelentésem nem konkrétan sávszélre vonatkozott!!!! Erre reagáltam vele: "a HT miatt gyorsabb az Opteron" - ami nem csak sávszélre vonatkozik, hanem a HT másik előnyére, a kisebb latency-re. Meg ugye ott van még az IMC is, mint az AMD CPU-k jellemző velejárója. Te emlegetted utána csak a sávszélt, miközben én (1 eset kivételével - arra írtam, hogy már belebeszélted a fejembe a sávszél szót, mellesleg ua. hsz-ben az általános kifejezést is használtam) szándékosan az általános memória-intenzív, memóriahozzéférés-intenzív kifejezéseket használtam, amibe természetesen beleértendő a latency is. (Főleg pl. egy véletlenszerű hozzéférésú path findingnél!)"Na itt keverted bele a latency-t, addig senki nem hozta fel."
Nem kellett azt belekeverni, mert már eleve benne volt, a HT, és úgy általában az Opteronos platform emlegetése által."Ami szep probalkozas volt elterelni mas iranyba a temat"
Nem akartam én elterelni semmit sehová, csak vissza a helyes útra (tehát hogy egyszerre van szó sávszéltöbbletről, és jobb latencyről)."de a kerdest nem valaszoltad meg. A valasz az eredeti kerdesre az hogy "sehogy","
Benne is volt: 'Mintha nem tudnád, hogy nem csak sávszélesség többlet van ott, hanem latency-ben is jobb az AMD.' = itt nem (feltétlenül) a sávszél játszik szerepet, hanem a latency."Es meg azt allitod en nem tudom elismerni ha nincs 100% igazam es csusztatok amikor azt mondom miket allitottal. Hat most ideztem igy nincs hely felreinterpretalasnak."
De, úgy tűnik, nagyon is van, ha már ilyen eszelősen erre törekszel. Hát ennyire nehezedre esik elismerni, hogy van ott bőven memória(hozzáférés)-intenzív program?Egyebkent a legjobb SPECInt_rate eredmeny a 2GHz 5335-nel 92.2, tehat hatrany nincs."
Ó, micsoda óvatos fogalmazás... Nem az számít, hogy nincs hátrány, hanem hogy hová tűnt az a 31%-os előny... Mindenképpen deficit."Csak megint nem arra valaszoltam amit kerdeztem."
Csak felhívtam a figyelmed egy nem mellékes körülményre."Meg megprobalhatod leirni."
Tudod mit? Magyarázd meg inkább te, hogy lehet ez, amikor láthatóan system-bound az int_rate is. Kíváncsi vagyok."A base eredmenyekhez javaslom nezd meg megint mirol szol a SPEC. Tenyleg faraszto hogy ezt itt kell megvitatnunk mert nem vagy kepes utannanezni."
Itt most rohadtul nem számít, hogy base vagy sem. Azért base számot írtam, mert kevesebb számolással össze lehetett hasonlítani. De akkor inkább számolok még egy kicsit, hogy "ne sírjon a szád".Auto-Parallelization nélküli SPECfp_2006:
AMD 1.9GHz - 11.3 --> 2 GHz: 11,9
Intel 2.66 GHz - 14.5 --> 2 GHz: 10,9
Tehát, Intel előnyt jelentő Auto-Parallelization compiling nélkül 9% az AMD gyorsabb. Na ehhez mit szólsz? Valószínű jópár programnál az Inteles fordító használata jópár százalékkal befolyásolja az eredményeket."Beidezem de nem ertem miert nem nezed meg magadtol. Peldaul a piCOLOR, Cinebench, 3DSMax, Folding@HOME GROMACS."
Késő van ahhoz, hogy most ennek nekiálljak utánanézni, de tudtommal a Cinebench és a 3DMax tudtommal skalár fp-t használ."Ugye nem fogd az Inteles kartyat kijatszani a Sandra-nal"
Itt most mire gondolsz? Az Inteles optimizációra? Ja, tudom, "nem nagyon" hozták vele hátrányos helyzetbe a többi procit, csak egy kicsit... LOL.(#3291): Huh, ha ezt most nem írtad volna le, biztos hülyén halok meg.
Főleg miután akorf már emlékeztetett. -
dezz
nagyúr
válasz
Raymond
#3281
üzenetére
Kezd egy végtelen ciklusra hasonlítani ez a vita. Nyilvánvaló dolgokat felesleges ismételgetned, mint pl. a szöveget a rate tesztekről - tisztában vagyok vele, hogy azok mik, magam is írtam már többször. Csak úgy emlékeztem, a sima (1-szálas) SPECfp teljesítmény is valamivel jobb volt, mint a másiké, csak a rate (többszálas) még jobb.
Ettől még lehet pl., hogy 1 procis, 4 szálas esetben is az AMD jöhet ki győztesen, és van is rá példa.
Látom, nem tudod elfogadni, ha nincs 100%-ig igazad. Pedig most sincs.
1. Állandóan próbálod bagatellizálni a rate eredményt, holott éppen ez mutatja meg, hogy szerepel egy platform különféle hétköznapi esetekben. Ez számít, nem az, mennyi a pure, elméleti max. teljesítménye a proci FPU egységének.
2. Szerinted nem számít a sávszél/latency az int_rate tesztekben. Pedig már felvetettem neked, hogy akkor hová tűnik a 30%-os előny? De akkor nézd meg a számokat (fLeSs által linkelt oldalról):SPECint_2006:
2x Barcelona 1,9 GHz: 11,3 --> 2 GHz: 11,9
2x Xeon E5335 2 GHz: 15,6 -----> előny: 31%SPECint_RATE_2006:
2x Barcelona 2GHz: 88.3
2x Xeon E5335 2 GHz: 84.2 ----> 4,8% hátrány!
(Pedig itt [is?] alkalmazásra került egy bizonyos Auto-Parallelization fordításnál Intelnél, ami kb. 8%-kal növelte a teljesítményét.)"De mondjuk lenyegtelen, mert az igazsag az hogy a savszelessegtol nem fugg."
Nem tudom, hogy csak a sávszélességtől, vagy inkább a latencytől, de láthatod, hogy függ."Ezt a #3258-ben leirtam de valahogy most sem valaszoltal ra."
Dehogynem, már ott is leírtam a 30%-os előny eltűnését."Csak sajnos a realitas az hogy"
...az Inteles számokat 8%-kal növeli az Auto-Parallelization az Inteles compilerben.
Anélküli számok (SPECfp_base2006):
AMD 1.9GHz - 9.97 --> 2 GHz: 10,5
Intel 2.00 GHz - 10.9"Valami pelda? Nem fogok linkelni semmit, hagyom hogy keress egyet akkor talan rajossz vegre mennyire nincs igazad. Mutass egy intenziv SIMD Int kodot hasznalo programot ahol egy K8 vagy a K10 gyorsabb mint egy Core2 CPU mert nagyobb a memoria savszelesseg."
1. Most nem jön be a spec.org, később leírom, melyikről gondolom, hogy SIMD-es.
2. Miért előlteted továbbra is ezt a sávszélességet, amikor már megbeszéltük, hogy nem csak erről van szól, hanem a latencyről is?"Akkor lehet hogy erthetobben kene irnod? Nem fogom beidezgetni a hozzasolasokat egyenkent mert ennek ninsc ertelme."
Hát tényleg nincs, mert én már a legelején úgy fogalmaztam, "memória-intenzít", illetve "memóriahozzéférés-intenzív", amibe beletartozik a latency is. Csak te jöttél állandóan a sávszéllel. (Lehet, hogy utána 1-2x engem is félrevittél ezzel.)"Erre a #3246-ben mar felsorltal parat azzal a kiulonbseggel hogy mar csak az 1/3-a a teszteknek az elozoleg allitott "csupa" helyett"
Jaj, de szépen tudsz csúsztatni. Ezt írtam:
"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.""A tesztekbol nem jon elo szamottevo kulonbseg. Valami mas lehet az oka."
Mi lehet még?"Van ott egy csomo masik program ami szinten SIMD intenziv azokban megsem szerepel olyan jol."
Melyik az a "csomó"?"Es azokbol van a tobb - gyakorlatilag az osszesben lasabb."
Gyakorlatilag nem, lásd VirtualDub and DivX encoding.Ami a Mandelbrot tesztet illeti: idézet a Sisoft oldaláról [link]:
[i]Q: Are the tests in the CPU Multi-Media Benchmark optimised for a specific CPU?
A: Yes, the tests are optimised as far as possible but without introducing instructions that would generate large penalties on other processors.ALU (Integer) Test - Optimised for Intel Pentium core.
FPU (Floating Point) Test - Optimised for Intel Pentium core.
MMX (Integer) Test - Optimised for Intel Pentium MMX core.
Enhanced MMX (Integer) Test - Optimised for AMD Athlon.
SSE (Integer & Floating Point) Test - Optimised for Intel Pentium III.
SSE2 (Integer & Floating Point) Test - Optimised for Intel Pentium 4.
SSSE3 (Integer) Test - Optimised for Intel Core 2.[/i]"Az hogy a Phenom nem pont ketszer annyi mint a K8 nem arra mutat hogy a programban van a problema hanem inkabb arra hogy a Phenom-nal vagy meg valami nem ul a bug-ok miatt vagy hogy ennyi lett a javulas"
Előfordulhat, mint ahogy az is, hogy Phenomra nem olyan jól optimizált. -
dezz
nagyúr
válasz
Raymond
#3258
üzenetére
[OFF]"Azzal kezdodott hogy a SIMD FP teljesitmenyt az fp_rate tesztel tamasztod ala. Modtam hogy azt nem lehet."
Ha egy hw gyakorlati teljesítményét akarjuk megtudni magas kihasználtság mellett, akkor nagyon is a RATE teszteket kell használnunk, nem pedig az egyszálas simákat.De mint írtam, az egyszálas fp eredmény is elég jó volt (mivel a tesztek jó része fp SIMD-es kód). Majd még megpróbálom előkeríteni. Vagy ki kell várnunk, míg újra publikálják. Viszont ennek nem sok gyakorlati jelentősége van...
Hát még egy full szintetikus elméleti maximumot tesztelő raw teszteknek. Az annyira nem érdekel senkit, hogy mint kiderült, nem is nagyon találni ilyen teszprogramot...
"Akkor jottel azzal hogy ha az fp_rate eredmenye tenyleg a savszelessegtol fuggene akkor az Int_rate is elohozna az elonyt."
Idézz pontosan: ha csak attól függene. Az természetes, hogy ettől is függ."Erre mondtam hogy nem, mert azok a programok messze nem olyan savszelesseg igenyesek."
A memóriahozzáférés-intenzív nem csak sávszélességet jelent, hanem latency-érzékenységet is. És van olyan ott bőven, aminek ez sokat számíthat.Ezen kívül több is van közöttük, ami nyugodtan használhat int SIMD kódot, és az bizony nagyon is lehet sávszél-igényes.
"Megnezted"
A feltételezéseidet ne tálald tényként, amíg nem tudod kétséget kizáróan bizonyítani (ha az nem lett volna elég, hogy közöltem)."es jottel hogy az 1/3-aduk fugg a savszelessegtol es a kesleltetestol is es felsoroltal parat. Tehat mar abbol az 1/3-bol amit magad talaltal sem fugg az osszes a savszelessegtol."
Értsd már meg, hogy eleve nem csak sávszélességről volt szó, csak te gondoltad ezt."Raadasul ha egy pointer chaser-es programot mint peldaul az a path finding akarhany peldanyban is futtatod ha a ket teljesen proci egyforma es csak az elerheto mem savszelessegben kulonboznek az eredmeny ugyanaz lesz mindkettonel mert egyszeruen nem szaturaljak a bus-t."
Lásd eggyel feljebb."Komolyan nem ertem miert vitazal felesleges ahelyett hogy megnezned."
Mit nem nézek meg?"Tegnap irtam par eredmenyt azt nem magyaraztad el (nem is tudnad vele az allitasod bizonyitani)."
De igen: azok 99%-ban nem (fp) SIMD-es tesztek.[/OFF]"Itt van meg valami akkor. Nezd meg milyen Int_rate eredmenyt kap egy 3Ghz 5160-as Xeon. 36-ot a legjobb submission-el, az atlag olyan 32-33. Ugyanebbol a procibol kettopedig kap 68-at a legjobb submission-el az atlag pedig 60-62. Majdnem idealis a skalazodas. Azt az 5-6%-ot leveszted a system overhead-el, de vilagos hogy a memoria savszelesseg egyaltalan nem jatszik szerepet. A 3Ghz-es Opteron 2222-nel ezek az eredmenyek 29-30 egy processzorral es 57-58 ketto-vel. Ennel vilagosabban mar nem tudom megmutatni hogy sem a SPECInt sem pedig a SPECInt_rate eredmenyek nincsenek az elerheto memoria savszelessegel befolyasolva. Remelem ez a tema ezzel befejezve."
No és azt mivel magyarázod, hogy sem az egyprocis, sem a kétprocis teszteket összehasonlítva nem jön ki a Core alapú Xeon 5160-as kb. 30%-os integer előnye? Csak nem mindkét esetben kompenzálódik az Opteronos rendszer sávszél és latency előnye által?De tegyük fel, itt kevésbé számítanak ezek. Ezzek még nem bizonyítottad, hogy fp_rate-nél csak ezek számítanak.
"Mondjuk a Cinebench skalazodas erdekelne miert van, mejd egyszer utana jarunk"
Valószínű, hogy mivel egy scene-n dolgoznak a szálak, közös adatbázisból dolgoznak, így sokszor előfordulhat, hogy a L3-ba kerül az adat, és több mag hívja onnan. Továbbá ray-tracingnél sok a kicsi és véletlenszerű memória-hozzáférés is, ami az független memória-csatornákon jobban megy. Talán latency-ben is jobb még valamivel a Phenom."Hat ugy oszinten az minden csak nem pure SIMD teszt."
Nem is, de SIMD-intenzív. Jól is szerepel benne a Phenom..."Viszont a pure SIMD tesztre ami sem a memoria savszelessegel es a processzor semmi mas tulajdonsagaval nincs befolyasolva csakis a tiszta SIMD kepesegekkel arra van ott egy kivalo pelda. Megpedig a Sandra Mandelbrot teszt. Ket processzor eredmenye semmi mastol nem fugg csak az Int es az FP SIMD teljesitmenytol. Szepen latszik melyik processzor mitt tud. Eleg osszehasonlitani ugyanazon csalad ket tagjat. Peldaul a 6000+ es a 6400+ csak az orajelbol adodo kulombseget mutatja ugyanugy ahogy az E6600 es a Q6600 csak a dupla annyi magbol adodo kulombseget mutatja."
Ha tényleg annyira pure az a teszt, akkor valami nagyon nem stimmel a Phenom számaival. Ha az 5600+ (2,8 GHz) 62939-es eredményét megszorozzuk 4-gyel (2x mag, 2x bitszélesség), és levonjuk az órajelkülönbségből adódó 7%-ot, a Phenom 9900-asnak (2,6 GHz) ~234133 pontot kellett volna hoznia. Ehelyett hozott 192141-et... Ez 18%-os deficit. Talán azt mondod, 1 K10 mag azonos órajelen 18%-kal lassabb, mint 1 K8 mag, fp SIMD-ben...? (Az int-et most nem számolom ki.)"Kerestem tegnap a prezentaciot vagy az oldalt ahol kepeket kozoltek rola de nem talaltam. Itt is linkeltuk pedig a topic-ban nem is egyszer. Majd meg lehet megnezem de per pillanat semmi kedvem. Ha viszont megtalaltad belinkelhetned."
A varsóira gondolsz? -
dezz
nagyúr
válasz
Raymond
#3247
üzenetére
"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].) -
dezz
nagyúr
válasz
Raymond
#3245
üzenetére
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.)
-
dezz
nagyúr
válasz
Raymond
#3243
üzenetére
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.
-
dezz
nagyúr
válasz
Raymond
#3240
üzenetére
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.
-
dezz
nagyúr
válasz
Raymond
#3232
üzenetére
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]
-
#3175
VaniliásRönk
nagyúr
Raymond
#3172
-
#3170
VaniliásRönk
nagyúr
Raymond
#3162
VaniliásRönk
nagyúr
válasz
Raymond
#3162
üzenetére
Látom humorodnál vagy.
Lassan írom hogy megértsd! Hiteles adatok még nem állnak rendelkezésre (2 teszt nem teszt, TDP is csak szerinted valós adat, mindenki más szerint elméleti, AMD szerint is, ezért lett bevezetve az ACP), a K8 X2 meg a K10 közötti fejtegetésed meg a végtelenségig le van egyszerüsítve, sacc/kb. alapon exhas számok, azt írtam szerintem valószínűleg túlzóak. (szemellenzővel meg ne dobálózz kérlek, nem ***** vagy te hogy az ilyen sértegetés legyen az ultimate weapon) -
dezz
nagyúr
válasz
Raymond
#3166
üzenetére
És az nem zavar, hogy ezek a feszek nem esnek egybe a felsoroltakkal? Meg amit írtam, tehát hogy egyes prociknál 1 fesz van, másoknál 2, ismét másoknál 3, stb. Pedig mind tudja a C'n'Q-t. Én fenntartom, hogy kihozatalfüggő a fesz, egy határon belül (ami lejjebb is bírja, abból lesz a Low Power, ami meg csak feljebb működik, az már selejt).
korcsi: Köszi. Na, akkor ez azt jelenti, hogy jó esetben 1,1V-on is elmegy a Phenom 9600-as... Talán a tokra írt fesz az abszolút max.
-
-
dezz
nagyúr
válasz
Raymond
#3159
üzenetére
Ha jól értettem, azt mondod, ez, hogy "1.10/1.15/1.20/1.25V" azt jelenti, hogy a különféle P-state-ekben ezek a feszek, tehát 1.25V a full speed, és 1,1 a C'n'Q-s. Nem hiszem, hogy így lenne ez. Pl. az én procimnál csak egy fesz van megadva, pedig tudja a C'n'Q-t ez is. Inkább arról lehet szó, hogy kihozataltól függően más-más feszt kíván... Ez is ezt támasztja alá: "Igaz a Toms adatai szerint az az 1.25V inkabb 1.225V."
A 2,3-as normál Brisbane-nál is 3 variáció van megadva (1.325/1.35/1.375V), miközben a BE-nél csak 1.
ps. #3163 végén persze 9600 Black Edition.
-
dezz
nagyúr
válasz
Raymond
#3156
üzenetére
3) Ez igaz, de éppen fogyasztási megfontolásokból tették lehetővé, hogy alacsonyabb frekin és feszen működjön.
(Meg ugye ne feledkezzünk meg, hogy van ott 2MB L3 is.)
"Ha megnezed a novekedest akkor lathatod hogy nem linearis tehat a nagyobb orajel eleresehez feszultseget is kell emelniuk."
Feltéve, hogy nem fake info... Nézd meg azt a korábbi fogyasztási képet! Kb. 10W-tal fogyaszt ott csak többet a 9900-as, mint 2600-as. És nem emlékszem, hogy írták volna, hogy nem valódi 9900-as van náluk, csak egy Engineering Sample, amit ide-oda szorzóztak, mint 1-2 másik oldal. Persze az is lehet, hogy mégis az volt, és nem bántották a feszt, mert ment rendesen.(#3157) Gyuri27: Jaja, meg is van a shot, csak nem találom, honnan mentettem le. És az valódi 9600-as volt, nem ES. Egyébként egészen pontosan 0,976V-ot mutatott a CPU-Z. (Nem biztos persze, hogy jó az adat.)
Egyébként egy dologról végig megfeledkezünk: "Independent Dynamic Core Technology", azaz hogy meg lehet tenni, hogy 1 magot jól felhúzunk, és a többit meg lazítani küldjük. És máris elég jól futnak a játékok. Remélem, ezt meg lehet majd tenni azzal a bizonyos 2600 Black Editionnal is.
-
#3161
VaniliásRönk
nagyúr
Raymond
#3160
VaniliásRönk
nagyúr
válasz
Raymond
#3160
üzenetére
Az elérhető hivatalos fogyasztási adatokból, meg a hibás BIOS-okkal mértekből, meg egy 65nm-es CPU-ból ami a T-Bred A-hoz hasonlóan hirtelenjében lett összegányolva.
Intelnél bezzeg nem a hivatalos adatokból indulsz ki, hanem a már rendelkezésre álló hiteles mérésekből. Miért esik nehezedre kivárni hogy Phenomról is hiteles adatok álljanak rendelkezésre, miért kell mindeféle találgatások alapján csatározni? -
dezz
nagyúr
válasz
Raymond
#3152
üzenetére
3) Na de te azt mondtad, hogy a bővített FPU és NB miatt (többiről nem beszélve) nem 2x-esét, hanem annál még jóval többet kell fogyasztania. De nem azt teszi, hanem kevesebb, mint 2x-esét fogyasztja, azonos órajelen (2,6 GHz).
Így nem feltétlenül kell ahhoz Low Power, hogy ha nem is a 125W TDP kategóriába, de a 140-esbe beleférhessen a 3 GHz-es. (Most a 6000+ 120W-ját felejtsük el, az 90nm-es.)
"140W a 9900 majd valamikor marcius vegen. Akkor hol lenne egy 3Ghz-s Q2-ben? Es hogyan? Mert szerintem sehogy. Majd talan 45nm-en."
Jaj, ne bomolj már, a 140W az új kategória, nem a 9900-as fogyasztása. Nyilván műszakilag (abszolút max. fogyasztás) éppen nem fért bele az AMD-féle 125W TDP-be. (Mint írtam, valós full loados fogyasztása ~120W.) Hanem ez lesz a 140W-os kategória legkisebb valódi fogyasztású tagja. Attól még a 3 GHz-es is benne lehet ebben a kategóriában.
Na ja, szervereknél jól jön az a L3. De a 2-8 utas K8-Opteronos konfigokban sincs olyan, mégis "elvannak".
Tudom, ez nem az a hely ahol közgazdasági foglamakat tárgyalunk ki, de ez megfogott.
, ahogy fless is írta ha a Nehalem-mel csinálnak egy szerverprociként is jól mükődő cuccot Intelék (elvileg a quickpath sikerén/implementálásán múlik ) akkor AMDéknek tényleg annyi -a,ot mindannyian nagyon sajnálnánk.
Ez nem túl biztató 
)
Ú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.
- Házimozi haladó szinten
- Kertészet, mezőgazdaság topik
- 200 megapixeles zoomkamerát sem kap az S26 Ultra?
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Sugárhajtómű ihlette a Zalman CPU-hűtőjét, de nem az üzemzaj tekintetében
- Autós topik
- Motorola Edge 60 és Edge 60 Pro - és a vas?
- Kerékpárosok, bringások ide!
- AMD Ryzen 9 / 7 / 5 / 3 5***(X) "Zen 3" (AM4)
- Okos Otthon / Smart Home
- További aktív témák...
- Lenovo LEGION Pro 5 / Pro 7, Lenovo Yoga Pro gépek (RTX 4060 / 4070 / 4080 / 4090)
- AKCIÓ! AMD Ryzen 7 3800X 8mag 16szál processzor garanciával hibátlan működéssel
- Bomba ár! HP ProBook 440 G7 - i5-10GEN I 8GB I 256SSD I HDMI I 14" FHD I Cam I W11 I Gar
- Beszámítás! Sony PlayStation 4 PRO 1TB fekete játékkonzol extra játékokkal garanciával hibátlan
- TELJES KÖRŰ IT BESZERZÉS
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest