Új hozzászólás Aktív témák
-
#275
dezz
nagyúr
Balala2007
#273
dezz
nagyúr
válasz
Balala2007
#273
üzenetére
Csak 1db MOV? És a visszatöltés?
"Ez nem er sztem, itt egy mesterseges butitast vettek ki egy low budget core-bol."
Az x64-et illetően igaz, viszont a D0-ás Palermo "nagy testvére" a Winchester volt, amiben szintén nem volt még SSE3, az E3/E6-osé pedig a Venice, amiben már igen.
(Közben itt "rájöttem" magamban, hogy hogy is tudhana egy FMAC 1-1 független FADD-ot és FMUL-t, hiszen nincs hozzájuk külön port.)
"Mi koze van az LSU-nak az EU-k operandusszamahoz???"
Nincs persze közvetlen kapcsolat, de ha nem csak regiszterekkel dolgozunk egy jól optimalizált kódban, akkor kevés lehet.
-
#274
P.H.
senior tag
Balala2007
#273
P.H.
senior tag
válasz
Balala2007
#273
üzenetére
Örömmel látom, hogy azért figyeled a Bulldozerrel kapcsolatos topikokat.
"A Willamette-tol a Preslerig megfigyelheto hasonlo ~10% nagysagrendbe eso difi az L1D es L2 write kozott."
Valóban, viszont ott ez nem változik kisebb (32-16-8 bit) írt adatméret esetén sem, tapasztalataim szerint. Mivel Ti azt 128 bites méretben tesztelitek és gondolom, Bulldozeren 256 bites AVX a tesztméret, a WCC jótékony hatásának egyre csökkenő írási méret esetén egyre nagyobbnak kellene lennie. A Netburst-öt integer végrehajtásban konkrétan megölte ez, Bulldozernél is ez a helyzet?
Mondjuk ha egy line 64 byte-os, már 32 byte-os írásnál is látszania kellene a hatásának.Az AGLU-ra linkelt paper-ed nekem nem elérhető, de akkor innen ered az INC/DEC-cel - "mint egyszerű utasítással" - példálozás, amit máshol is láttam már. Pedig annyira egyértelmű pedig, hogy:
- a legegyszerűbb integer ALU műveletek a MOV, MOVZX, MOVSX és a NOT, mivel azok a flag-eket se módosítják
- ha van EFLAGS-kimenete az AGLU-knak, akkor a logikai műveletek következnek, mivel azok az EFLAGS bizonyos bitjeit fixen törlik
- bonyolultsági sorrendben aztán jönne ADD, SUB, NEG, amik már a teljes EGFLAGS-et módosítják
- csak eztán jön az INC/DEC, aminek már (virtuális) "EFLAGS-bemenete" is van (CF)
De akkor ez nem most lesz.Amit a Bobcat-Bulldozer párhuzamról írsz: vajon milyen opt. guide-ot lehetne hozzá készíteni? Olyan egyszerű, mint a faék. Az Intel az Atom-ot lerendezi ~20 oldalban latency/throughput táblával együtt egy mellékletben (az is olyan, amilyen), pedig az inorder és csak az egyik pipe-nak van full SIMD-FP-MEM végrehajtója/hozzáférése. A Bobcatról mi olyat lehetne írni, ami nem egyértelmű már ránézve a felépítésre?
Úgy látom, hogy a Bulldozer továbbviszi azt az alapvető cache-felépítést, ami a K8/K10-ben is volt, azaz hogy az L2 és az L3 továbbra is csak a módosított adatokat tárolja, az L1 az egyetlen olvasási cache: a csak olvasott, nem módosított adatok meg sem jelennek az L2/L3-ban; ha szükség van a helyükre, azonnal törlődnek, későbbi újbóli hozzáférésnél pedig újra a memóriából olvassa be őket. Ennek láttad valamilyen cáfolatát?
-
#273
Balala2007
tag
dezz
#272
Balala2007
tag
Gondolom, nem akkorát, mintha nem is lenne.
Az FMA4 mindig kivalthato 1db MOV + 1 db FMA3-mal, ahogy az az eredeti SSE5 koncepcioban is szerepelt. A dologban az az igazan erdekes, hogy az anandtech szerint mar az IVB behozza a BDZ ket elonyet: 256b szeles DIV/SQRT + MOVxPy elliminalas, utobbit az IVB teljesen altalanosan GPR-ekre is tudja. A Haswell reszleteirol tudtommal 0 info szivargott ki eddig az AVX2 es az FMA3-on kivul, de meglepne, ha nem tudna mindazt, amit az IVB. Ha ehhez meg hozzavesszuk, hogy legtobb matrixszorzo, xAXPY stb. rutinhoz eleg az FMADDPx231-es alak MOV nelkul, akkor ez nem egy elfogadhatatlan kompromisszum. Persze a legjobb az lenne, ha csak FMA4 lenne.
A Palermo esetére gondolok, ahol az E3-mal "jelent meg" az SSE3 és az E6-tal az x64.
Ez nem er sztem, itt egy mesterseges butitast vettek ki egy low budget core-bol.
Ezek szerint nem sok értelme itt a nagy számokkal "villogni", fontosabb az asszocivitás és még ki tudja, mi...
Igen, a meret es a latency is szamit, de legalabb a Steamrollerig nem szamitok komoly valtozasra.
A friend working at a MOBO company told me Bulldozer went from -5% to 17.5% increase in IPC over Thuban with new stepping+ new AGESA, but there is still some L3 issues.
Ezt max. majd a BDZ launch utan kommentalom, mar csak par nap a tervek szerint.
A K10 sem tudja?
1 EU-val az sem.
Mármint, ott sem mehet egyszerre az FADD és FMUL?
De, csak azt 2 db EU csinalja. Ha 2 EU-t nezel, akkor BDZ-n
VADDPx xmm0, xmm1, xmm2 + VMULPx xmm3, xmm4, xmm5 lat=5(6) tp=1
VADDPx ymm0, ymm1, ymm2 + VMULPx ymm3, ymm4, ymm5 lat=5(6) tp=2Csak mert az LSU-k ott is ugyanannyi adatot tudnak betölteni/kiírni ciklusonként.
Mi koze van az LSU-nak az EU-k operandusszamahoz???
Egy plusz ciklussal nem oldható meg a dolog?
Azt full pipeline-nak hivjak.
-
#272
dezz
nagyúr
Balala2007
#270
dezz
nagyúr
válasz
Balala2007
#270
üzenetére
"Eleg gyorsan ki fog derulni, hogy mennyi hatranyt jelent a gyakorlatban az FMA3 az FMA4-gyel szemben."
Gondolom, nem akkorát, mintha nem is lenne. Meg aztán x64 alatt van elég regiszter, van hova pakolni, még ha ez 1-2 további utasításba is kerül."Ez igaz, ezert irtam, hogy "reg-reg latency/througput szempontbol"."
Ahh, cseles!
De ugyebár minket az általános teljesítmény érdekel."x64-en azert annyira talan mar nem ritka."
Nem úgy tűnik, mintha sokat változott volna az átlag IPC."Ott a modell number valtozott, nem a stepping. 10Fxx -> 20Fxx."
A Palermo esetére gondolok, ahol az E3-mal "jelent meg" az SSE3 és az E6-tal az x64." "The WCC is 4 KB in size and is 4-way set associative" 47414_3_03.pdf, 39. oldal."
Köszi! Nem láttam még sehol említve."Mivel a WCC az egy cache line-on beluli irasokat gyujti egy tranzakcioba, 16KB-nyi folytatolagos iras mellett biztos lehetsz benne, hogy maximalisan ki van hasznalva."
Az tuti, de én arra gondolok, hogy külön le lehetne mérni a sávszélét <=4K-s írással, hiszen kódfüggően adott esetben az lesz a mérvadó.BTW, egy érdekes megjegyzés a cache-sávszélekkel kapcsolatban: [link] (Csak mert épp tegnap olvastam.) Ezek szerint nem sok értelme itt a nagy számokkal "villogni", fontosabb az asszocivitás és még ki tudja, mi...
BTW2, ez is friss:
"A friend working at a MOBO company told me Bulldozer went from -5% to 17.5% increase in IPC over Thuban with new stepping+ new AGESA, but there is still some L3 issues." [link]"Arra gondolsz, hogy 1 db FMAC nyomjon MUL-t es ADD-ot egyszerre? Az sztem mar csak azert sem fog menni, mert 4 db source-ot 2 db resultot kellene oda/elvezetni EU-nkent."
A K10 sem tudja? Mármint, ott sem mehet egyszerre az FADD és FMUL? Csak mert az LSU-k ott is ugyanannyi adatot tudnak betölteni/kiírni ciklusonként. Egy plusz ciklussal nem oldható meg a dolog?"100%-ra allithatom, hogy lesz FMA3, BMI es TBM a 610Fxx a Piledriverben."
Na, hát ez tök jó, akkor.(#271) Abu85: Nem visszaírni, hanem visszakapni.
De egyébként max. azokat fogja picit idegesíteni, akik kézzel optimalizálnak ASM-ben, a többség viszont rábízza a C-fordítóra... -
#271
Abu85
HÁZIGAZDA
Balala2007
#270
Abu85
HÁZIGAZDA
válasz
Balala2007
#270
üzenetére
Eleg gyorsan ki fog derulni, hogy mennyi hatranyt jelent a gyakorlatban az FMA3 az FMA4-gyel szemben.
Sanszos, hogy a feldolgozás sebessége szempontjából nem lesz hátrány. A programozónak viszont az lesz, mert az FMA4 "rugalmasabb". Annyira nem jó dolog az egyik operandus regiszterébe visszaírni az eredményt, mert ha kell onnan később az eredeti adat, akkor azt előbb át kell másolni valahova. -
#270
Balala2007
tag
dezz
#269
Balala2007
tag
Ez itt a reklam helye: a tech partner oldalunkra kikerult az AMD logoja.
Ez ha jol gondolom tovabbra sem kezzelfoghato termek.
Nem, de az a doksi eleg beszedes.
Mivel ugye már a Piledriverben is benne lesz az FMA3, így az is kb. egy évvel hamarabb lesz AMD oldalon.
Eleg gyorsan ki fog derulni, hogy mennyi hatranyt jelent a gyakorlatban az FMA3 az FMA4-gyel szemben.
DBZ vs. Bobcat: azért nem csak az ALU-k számítanak az IPC-ben, hanem erősen a frontend is. Elágazásbecslés, stb.
Ez igaz, ezert irtam, hogy "reg-reg latency/througput szempontbol".
az első eset elég ritka hétköznapi kódban, nem beszélve a 4-ről.
x64-en azert annyira talan mar nem ritka.
Volt már, hogy így vezették be pl. az SSE3-at.
Ott a modell number valtozott, nem a stepping. 10Fxx -> 20Fxx.
A BDZ-ben kell lennie egy bizonyos WCC-nek (Write Coalescing Cache) a L1 és L2 között, írás esetén. De senki sem tudja ennek méretét és sávszélét.
"The WCC is 4 KB in size and is 4-way set associative" 47414_3_03.pdf, 39. oldal. Mivel a WCC az egy cache line-on beluli irasokat gyujti egy tranzakcioba, 16KB-nyi folytatolagos iras mellett biztos lehetsz benne, hogy maximalisan ki van hasznalva.
megoldják-e, hogy az FMAC-ok 1-1 független FADD és FMUL-t is végre tudjanak hajtani egyidőben, mert úgy tűnik, most nem tudnak. Vagy mégis?
Arra gondolsz, hogy 1 db FMAC nyomjon MUL-t es ADD-ot egyszerre? Az sztem mar csak azert sem fog menni, mert 4 db source-ot 2 db resultot kellene oda/elvezetni EU-nkent.
A bdver2 nem a Piledriver, hanem a Steamroller!
Ez dezz-informacio.
(bocs, nem birtam kihagyni) Az egy regi roadmap, amibe utolag hekkeltek bele kekkel a megjegyzeseket. 100%-ra allithatom, hogy lesz FMA3, BMI es TBM a 610Fxx a Piledriverben. Hogy ezen kivul mi lesz es mi nem lesz, azt nem kivanom felfedni. -
#269
dezz
nagyúr
Balala2007
#262
dezz
nagyúr
válasz
Balala2007
#262
üzenetére
-
#268
dezz
nagyúr
Balala2007
#262
dezz
nagyúr
válasz
Balala2007
#262
üzenetére
"OK, jogos, az FMA4 es XOP is jo huzas, csak az FMA3 es az AVX2 miatt fenyeget a marginalizalodas ("3DNow!-sodas") veszelye."
Mivel ugye már a Piledriverben is benne lesz az FMA3, így az is kb. egy évvel hamarabb lesz AMD oldalon.
DBZ vs. Bobcat: azért nem csak az ALU-k számítanak az IPC-ben, hanem erősen a frontend is. Elágazásbecslés, stb. A Bobcatnál valószínűleg gyengébb a frontend.
"+31% (~79mm²) die koltsegert +2,5MB L3 kesleltetu L2, -2x (FPU, fetch, decode, L1I,.. ) kapacitasproblemakkal tuzdelve ilyen nyomott aron sztem tovabbra sem jo uzlet, meg ha az I/O linkeket szamolom is"
Nyilván ha gyenge a uarch, akkor kár bele a cache. Ha tényleg olyan gyenge...
"Ez a beszed!"
Nos, azért előfordulhat, hogy az egyik szálon éppen 3 independent utasítás jön, a másikon pedig csak 1. Viszont, az első eset elég ritka hétköznapi kódban, nem beszélve a 4-ről.
"Steppingekben bugokat/kihozatalt, aprosagokat javitanak, semmi lenyegi valtoztatas nem szokasos."
Volt már, hogy így vezették be pl. az SSE3-at. Teljesítményproblémáknál meg kell tenni, amit lehet.
"A Willamette-tol a Preslerig megfigyelheto hasonlo ~10% nagysagrendbe eso difi az L1D es L2 write kozott."
A BDZ-ben kell lennie egy bizonyos WCC-nek (Write Coalescing Cache) a L1 és L2 között, írás esetén. De senki sem tudja ennek méretét és sávszélét. Érdemes lenne erre is tesztelni...
Bugok: nos, ha a cache-kezelést illetően van még valami bug, az is komoly, hiszen igencsak vissza tudja fogni a teljesítményt.
"rakerdeztunkre megerositettek, hogy a rendszer lenyegeben a piacra szanttal megegyezik."
HW-ileg valószínűleg így van, de a hírek szerint pl. az AGESA-t folyamatosan "hekkelik"... (De persze korábbi döntések [mi kerüljön piacra] is felülbírálásra kerülhetnek.)
"mivel a PileDriverben lesz FMA3", "PileDriver ISA bovitesei mar reg ismeretesek"
Nocsak! Erről nem hallottam, de úgy tűnik, Abu és Oli sem, mert nem volt róla itt hír. De máshol sem láttam. Egyébként azt nem biztos, hogy már most mindent világgá kürtölnek a változásokat illetően. (Pl. hogy megoldják-e, hogy az FMAC-ok 1-1 független FADD és FMUL-t is végre tudjanak hajtani egyidőben, mert úgy tűnik, most nem tudnak. Vagy mégis?)
-
#266
Valdez
őstag
VaniliásRönk
#265
Valdez
őstag
válasz
VaniliásRönk
#265
üzenetére
Azért az valahol nem sok jót jelent, hogy még meg sem jelent a cucc, de már az utódjáról beszélnek.
-
#265
VaniliásRönk
nagyúr
Balala2007
#262
VaniliásRönk
nagyúr
válasz
Balala2007
#262
üzenetére
"Mar megvan a PileDriver Optimization Guide is."
Ez ha jol gondolom tovabbra sem kezzelfoghato termek.
-
#264
Balala2007
tag
Oliverda
#263
Balala2007
tag
válasz
Oliverda
#263
üzenetére
Igazad van, ezt sajnos elneztem. A szovegben azert ott van az FMA3, es azt tartom, hogy benne lesz a PileDriverben. Koszi a javitast!
-
#263
Oliverda
félisten
Balala2007
#262
Oliverda
félisten
válasz
Balala2007
#262
üzenetére
PileDriver ISA bovitesei mar reg ismeretesek:
BMI,TBM,FMA3Az FMA3 alá linkelt slideon az "FMx infrastructure" a foglalatra utal (FM2 talán) és nem az utasításkészletre.
-
#262
Balala2007
tag
Balala2007
tag
(#161) dezz
Már szállítják a szervergyártóknak és a Craynek.Ezt rosszul irtam, bocsanat. A Zambezire gondoltam, de most mar ugy nez ki, hogy legalabb egy paperlaunch azert lesz.
Nem csak felzárkóztatja.
OK, jogos, az FMA4 es XOP is jo huzas, csak az FMA3 es az AVX2 miatt fenyeget a marginalizalodas ("3DNow!-sodas") veszelye.
Úgy emlékszem, ez volt az egyik jelentős B1 bug vagy (szándékos) BIOS-os butítás, vagy nem?
Inkabb mintha felcsereltek volna az L2 read-ben az elso 2 szamjegyet mesterseges hibakent, anelkul teljesen OK lenne.
Igen, ezt már én is írtam itt a topikban (vagy egy másikban?), de az AMD egyik emberének volt erre egy magyarázata, hogy miért nem jelent nagyobb problémát. Nyilván jól átgondolták, hogy ez jó lesz-e így...
Nekem meg az is az eszembe jutott, hogy talan azert sincs hivatalos Bobcat OptimGuide meg fel evvel a megjelenese utan sem, mert kapasbol ki lehetne szurni mennyire hasonlit a ket proci integer resze, es ez talan nem tenne jot a BDZ megitelesenek. Ennek az lenne ertelme, hogy talan valamennyit sporolnak a tervezesen, es reszben kozos a K14-K15 integer optimalizacio.
Ehhez azért tegyük hozzá, hogy a Gulftownban 1,5MB L2 + 12MB L3 van, szemben a Bulldozer 8 MB L2 + 8 MB L3-jával. Azt hiszem, HT linkből is több van a chipen, mint QP-ből a másikon.
+31% (~79mm²) die koltsegert +2,5MB L3 kesleltetu L2, -2x (FPU, fetch, decode, L1I,.. ) kapacitasproblemakkal tuzdelve ilyen nyomott aron sztem tovabbra sem jo uzlet, meg ha az I/O linkeket szamolom is
De miért ezt hozod fel, miért nem a Thubant vagy SandyB alapú procit a másik oldalról?
Mert 32nm es nincs benne IGP.
K10-zel hasonlítva kicsit jobban látszik, mennyit nyertek vele.
346mm² a 45 nanos 6magos Thuban. Az, hogy megeri-e, majd a teljesitmeny tukreben lesz erdekes.
>jo esetben magasabb freq-ra lehet szamitani
Ha kellő mértékű, az épp elég...
Meglepetes...Nem is lenne sok értelme, lévén a modulonkénti "előtét" 4-utas.
Ez a beszed! (Ehhez kepest azert volt szo "accelerate mode"-rol is, 8 way decode, es egyeb abrandok)
"Okosodni" azért okosodhat (milyen műveletek mehetnek egyszerre, stb.), bár ezt a next.gen.-től várják.
Steppingekben bugokat/kihozatalt, aprosagokat javitanak, semmi lenyegi valtoztatas nem szokasos.
aztan nehogy felsuljetek a szubjektiv talalgatasokkal.
Ma is tanultam vmit: Az AIDA64 processzor benchmarkjainak BDZ-n elkovetett finomhangolasat talalgatasnak nevezik.
A 281. oldalon levő táblázat a rev. 3.02-ben még így nézett ki, de pár nappal később a rev. 3.03-ra lecserélték az egyszerűsített táblázatra.
Igy tortenelmi kitekintesben meg erdekesebb... Folytatas varhato a temaban.
A P4 a write-through L1-ét szimplán az L2 sebességével írta,
A Willamette-tol a Preslerig megfigyelheto hasonlo ~10% nagysagrendbe eso difi az L1D es L2 write kozott.
Az AGLU-val mi a helyzet?
Eszerint az ISSCC paper szerint meg tudott volna legalabb INC/DEC-eket is, de az Optim Guide ennek ellentmond. Igy marad az effektiv cim szamitas CALL-nal es LEA-nal meg a memoriaoperandusoknal. "Two-way integer execution, Two-way address generation". Ez persze csalodas, de nezzuk az elonyos oldalat: reg-reg latency/througput szempontbol ~95% ugyanaz az integer Bobcat mint a BDZ.
1 órajel alatt tud két double-t (mondjuk két egymást követő AVX-utasítást) fordítani a front-end?
Lattam ra peldat, de messze nem volt annyi gepidom a BDZ-vel, hogy ezt teljes altalanossagban ki merjem jelenteni.
az előző generációs (nem AVX-XOP-FMA4, hanem még SSEx) tesztkódokban hogyan viszonyulnak a Thubanhoz és a Sandy Bridge-hez?
Ezzel sem volt ido alaposan foglalkozni, de ami elojott, az alapjan pont olyan, amilyennek varja az ember, az eroforras problemak kevesbe jelentkeznek, csak a nagyobb latency-k sujtjak.
És az AMD procik?
Az AMD tetovasaga miatt nincs kint a logojuk, mi kitennenk. Igyekszunk nem reszrehajloak lenni. Konkretan 2009 juniusatol van FMA4 kodunk, amikorra lecsengett az SSE5/FMA3/FMA4 speckohaboru. A finomhangolas 2011 majusaban volt, hogy a
juniusiaugusztusiszeptemberioktoberi launchra minden meglegyen. Mi elkeszultunk idore.amiben sokak szerint még komoly bugok vannak, de működik már annyira, hogy ne húzzák vele tovább az időt
A komoly bugok olyasmik, amik pl. a K10 revision guide-jaban vannak, mint a hiresse valt #298-as TLB bug. Kulonleges korulmenyek kozott rendszerleallast, hiabas eredmenyt adnak, vagy mas modon elternek a specifikaciotol. Ha mazlijuk van, akkor kiadnak ra valamilyen workaroundot, pl. a Llanoban nem reszletezett korulmenyek kozott lefagyhat az uj dedikalt integer oszto egyseg, a workaround atkapcsolas a mikrokodos osztasra. (44739_3_04.pdf 44. oldal) A BDZ B2-bol is azert van ketfele, mert elojott(ek) (egy/tobb) lefagyos problema(k), ami(k)re pont nem talaltak, ugy meg nem mehet a userekhez.
Az is elég furcsa, hogy egy alacsony órajelű sokmagos, kimondottan szerverproci alapján mondtok ítéletet a desktop vonalról
Egyreszt a BDZ kimondottan magas orajeleket celoz meg, amint az a magas latency ertekekbol is latszik, (6 clk FADD, stb.) masreszt volt szerencsenk mindkettohoz.
független szakértőknek koránt sincs ilyen rossz véleménye, amit te itt és máshol is megfogalmaztál.
A fuggetlen szakertok osszesen hany orat agyaltak azon, hogy a csucsra kihegyezett kodjuk miert ugy fut -- az AMD kepviselojenek irasbeli tajekoztatasa alapjan a piacra kerulo rendszerrel lenyegeben megegyezo konfigon --, ahogy?
Egyes szintetikus részeredmények és pár elvi gyengeség alapján ilyen súlyos kijelentéseket tenni, nos ennek nem tudom, mi a célja.
Vannak (voltak?) elvarasok, mesek, csak igy kapasbol (plusz ide teheto meg az elobbi accelerate mode is): 1,2,3
Plane a jovore nezve olyan processzorokrol, amiknek a kozeleben sem voltal?
Mar megvan a PileDriver Optimization Guide is.
ti biztos a vegleges verzioju bulldozerrel dolgoztok?
Az eredmenyeket latva ez persze bennunk is felmerult, es rakerdeztunkre megerositettek, hogy a rendszer lenyegeben a piacra szanttal megegyezik. Ha ezt tovabbgondolod, hogy vagy benasagbol/szervezetlensegbol hazudtak nekunk, es aki ezt mondta, az is rosszul tudta, az totalis fejetlenseget jelent egy cegen belul, es ezert nem iger tul sok jot, vagy ha meg szandekosan atvertek azokat a kodereket, akiknek a munkaja alapjan a legjobb szinben kell feltunnie a termekuknek, az meg komplett agyrem.
vagy csak azota is rajtatok lelkes balkani amatorokon rohognek
Itt legfeljebb az Intel rohog, hogy az FMA4-et mar most sikerult a 3DNow! sorsara juttatni - mivel a PileDriverben lesz FMA3, ezzel a kerdes nagyjabol el is dolt.
Sajnos egyelőre nem tudjuk, mi változik az egy éven belül megjelenő Enhanced
PileDriver ISA bovitesei mar reg ismeretesek:
BMI,TBM,FMA3A BDZ optim guide-bol kiderul a CPUID azonositojuk is: 610Fxx es 620Fxx (47414_3_03.pdf 37. o), azaz a foverzio ("K15") megegyezik a 600Fxx Zambezivel. A valtozas valamelyest analog a Athlon 64 -> Athlon 64 X2 atmenettel. Ugyanaz a core es csikszelesseg, kis ISA tuning (~SSE3), a 610Fxx Trinitybenben ugyan kevesebb lesz a magok szama de jar bele integralt GPU is (a dual core analogiajara).
-
dezz
nagyúr
Nagyon hasznosak a szintetikus tesztek, ha valaki fogékony a technikai részletekre, illetve, megmutatják, hogyan futnának a különféle típusú programok, ha minden kézzel lenne optimalizálva az egyes architektúrákhoz.
Csak hát ugye, a hétköznapi programokat ma már nem szokás kézzel optimalizálni, főleg nem ASM-ben írni. Az optimalizáció kimerül a fordító néhány kapcsolójának beállításában, itt is általában az egyik vagy a másik architektúra megcélzásával, ritka a többszörös code-path alkalmazása. (Többek között ezért olyan nagyok az x86 magok, tehát mert hw-ből próbálják kompenzálni az optimalizáció hiányát, több-kevesebb sikerrel.)
Bár némileg változik a helyzet pl. az OpenCL megjelenésével, mert ott nem a már lefordított kód kerül terjesztésre, a fordítót pedig maga a gyártó készíti.
-
#260
Abu85
HÁZIGAZDA
VaniliásRönk
#238
Abu85
HÁZIGAZDA
válasz
VaniliásRönk
#238
üzenetére
A SYSmarkkal elsősorban az a gyártók problémája, hogy tök értelmetlen dolgokat mér. Pl.: egy program hány másodperc alatt települ, és ezek az értelmetlen dolgok, amik a végső pontszámban durván beleszámítanak.
A szintetikus programok ellen valóban fellép az AMD mellett több gyártó is (pl.: VIA, vagy az NV), de nem akarják itt az egész iparágat tönkretenni, csak azt akarják, hogy a szintetikus programok is fejlődjenek a valós alkalmazásokhoz mérten. A SYSmark azért van ennyire célkeresztben, mert évek óta nem fejlődik, és csak a CPU teljesítménye alapján dönt, olyan tesztek felértékelésével, amelyek lényegtelenek a felhasználói élmény során.
A Sandra például nincs annyira célkeresztben. Szintetikus program, de nyitottak az új felületek felé (OpenCL tesztek), és ez már tetszik az AMD, VIA, NV triónak is. Ettől függetlenül mindegyik fentebb említett gyártó valós alkalmazásokat javasol az OEM-eknek tesztre. -
dezz
nagyúr
Bocs, de ezt nem lehetett kihagyni...
És mellesleg igaz is! Még az egyes felhasználói programok között is nagy különbségek tudnak lenni...Nem írtál eredményeket, de ti csak ismeritek azokat és össze tudjátok hasonlítani a linkeltekkel... (Természetesen nem kell közölni, hogy megegyeznek-e vagy sem.)
Nem tudom, mit akarnál idézni tőlem, hiszen nem írtam olyat, hogy tuti biztos szuper jó lesz és lever mindent. Én csak azt mondom, hogy szerintem nem egy alapvetően elszúrt konstrukció (mert 2-way, stb.), és ha nem jön közbe valami váratlan (nehezen javítható bug, az elvárhatónál alacsonyabb órajel, gyártási gondok), akkor meg van az esélye, hogy elég jó legyen. Lehet persze, hogy kell még neki 1-2 revízió/stepping, és a kihozatalon is javítani kell (nem csak működő/nem működő szempontból, hanem hogy milyen feszen milyen órajelet visz az adott chip).
Ha nem is alakul minden olyan jól az első időkben, bennfentesek szerint még csak nem is egy második Agena. Akkor azért csak nem akkora bukás...
Ami a jövőt illeti, szerintem nagy potenciál van ebben a kialakításban, főleg kisebb csíkszélességen. Sajnos egyelőre nem tudjuk, mi változik az egy éven belül megjelenő Enhanced és az azutáni Next Gen. Bulldozereknél. (Néha az Enhancedet is next gennek mondják.) De ha csak itt-ott okosítanak még rajta, már azzal is komoly előrelépést érhet el (erről kérdezd P.H.-t), nem beszélve pl. az FPU CU-ra (Compute Unit) cserélésének lehetőségéről.
-
Fiery
veterán
Aranyos vagy
Pont 8 evvel ezelott kezdtunk el benchmarkokat fejleszteni, azota kicsit tobb ralatasom van a dologra. A felhasznalok szemszogebol most is jobbnak latom, ha nem a szintetikus benchmarkokbol indulnak ki, amikor almat (AMD) a kortevel (Intel) hasonlitanak. De pl. tuningnal pont a szintetikus benchmarkok jonnek jol, ill. akkor is, ha pl. hardverhibat vagy beallitasi hibat keres a juzer.Egyebkent nem is ideztem szintetikus benchmark eredmenyeket a Zambezi kapcsan, ha nem tevedek. Benchmarkok futtatasa nelkul is egyertelmu volt szamunkra mar az elso zambezis "encounter"-nel is, hogy mire lesz eleg a Zambezi, es mire nem.
"Teljesen felesleges minden tesztet figyelembe venni, amikor szinte alig van olyan felhasznalo, aki az ido nem elhanyagolhato szazalekaban minden egyes teruleten kihasznalna a gepe teljesitmenyet"
Ezt tovabbra is tartom. Meg a tobbit is, mert tovabbra se jatszok, tovabbra se "content create"-elek, tovabbra se CAD/CAM-ezek. Es tovabbra se nezem a szintetikus eredmenyeket egy review-ban. Mondjuk mar par eve idom sincs vegigolvasni egy 20-30 oldalas review-t, elolvasom a conclusiont, oszt jovan.
A Sandrara meg most is köpködhetnék, plane mivel a konkurenciank, de a tisztesseg azt kivanja, hogy inkabb ne mondjak rola semmi rosszat. A potencialis vasarlok az en kritikam nelkul is el tudjak donteni, hogy melyik szoftver mire jo es mire nem.
En meg majd idezem az osszes ilyen szovegedet, amikor eljon a "nagy nap"
Illetve nem fogom tenni, mert en nem szemelyeskedek, es nem asok elo regi szovegeket csak azert, hogy megprobaljak valakit diszkreditalni.Adok egy jo hirt is, csak mert ilyen kedves voltal velem ebben a postodban: a review site-okhoz me'g ebben a honapban megerkeznek a "final" Zambezik, ha minden igaz. Mar kaptam AMD altal futtatott benchmark eredmenyeket is, de me'g abban se ugy szerepel a Zambezi, ahogy sokan szeretnek. Ez van.
-
Remus389
veterán
hehe
egyebkent ha hihetunk neki akkor olyan phenom1 szaga van
megis 1-1,5 evvel kesobb kihoztak a phenom2/athlon2-t ami mersekelt siker lett
kijavitottak a hibait, magasabb orajeleket kapott/tudott elerni, olcson adtak, es egesz korrekt lett
szerintem ha lemennek 22 nanora, kicsit toldozzak, jo aron adjak megismetelhetik a phenom2 sikereit
sajnos AMD-nel kenytelenek elore gondolni, nem tehetik meg mint az intel hogy az aktualis gyartastechnologiara kihozzak a legoptimalisabbat
talan a phenom1 azert lett gyenge mert 65 nanora nem volt valo
talan ugyanez lehet itt is ez a felepites versenykepeseb 22 nanon
tehat az alapotlet jo volt phenom1-nel is, de az adott gyartastechnologia illetve az akkori programok nem tudtak kiaknazni, ezert lett csalodas viszont kesobb a phenom2 jo lett
itt ia jo az alapotlet, de 32 nanon nem biztos hogy nyero es a mai progikkal, majd 1-2 ev mulva a javitott valtozata a bullnak jo aron majd sikeres lesz
persze ha hihetunk neki
-
dezz
nagyúr
Hát izé, korábban még egy picit más volt a véleményed a Sandráról és úgy általában a szintetikus tesztekről... Inkább nem idézem: [link] Nos, akkor ugye fogadjuk meg a tanácsod...?
És mégegyszer: egy herélt ES példánnyal készült a teszt. Ha nektek is hasonló eredmények születtek, nálatok sem klappol valami, legalábbis a desktop Zambezi nem egészen ilyen lesz.
-
Fiery
veterán
Mondj 5 "rendes" programot, amivel dolgozni lehet
Raadasul amivel benchmarkolni is konnyu, es nem is reteg alkalmazas (pl. nem CAD/CAM).Konnyu fikazni, de en pl. hardver teszteket is irtam, jo nehany eve meg mar benchmarkokat fejlesztunk, szoval nem a megfelelo embernel fikazod a benchmarkokat
-
Fiery
veterán
>A neten több helyen is elő lehet rendelni -- áron alul,
>mivel ugye zsákbamacska.El kell hogy szomoritsalak: nem aron alul. Ez ennyibe fog kerulni, mert igy jon ki az ar/ertek arany. Igy kapsz majd egy jo procit a penzedert. Jo procit, kicsi penzert. Akinek ez kell, az elo is rendelheti
>De, indirekt módon, amikor azt írtad, hogy az Intel
>ritkán biházik és akkor sem nagyotEnnyi erovel beszelgessunk az F00F meg FDIV bugrol, ugyanennyire nem idevaloak azok se
-
Fiery
veterán
válasz
Remus389
#248
üzenetére
>es egy a 2500k-t alulrol surolo proci lesz a legjobb bulldozer
Erre me'g van remeny
>ilyen benchmarkok azert ugy vannak irva hogy inkabb
>az intel felepitesnek kedvezzenNo offense, de nonszensz, amit irsz. Nyilvan amikor vannak "industry standard" benchmarkok, felmerulhet hasonlo vad, de amikor nagy altalanossagban, azaz a kulonfele benchmarkok es jatekok nagytobbsegeben is egyarant gyengen muzsikal valami, akkor felesleges vegigmenni a benchmarkokon/jatekokon, es egyenkent mindegyikre rasutni, hogy X ceg fele huznak. Nem a benchmark programok tehetnek arrol, ha egy CPU rosszul sikerul
-
dezz
nagyúr
válasz
#95904256
#213
üzenetére
Csak a hozzászólás szövegét nézd, és vedd úgy, mintha a Pentium M-re vonatkozna.
A fogyasztás tekintetében lehetőleg ne 130nm-es procit hasonlíts 65nm-essel...
(#225) smkb: Éppen ezzel kapcsolatban írta Hans de Vries, amit a #203-asban idéztem. Szóval, teljesen irreleváns...
(#216) Fiery: A neten több helyen is elő lehet rendelni -- áron alul, mivel ugye zsákbamacska.
(#228): 2012-ben már jön a Trinity...
"Az AMD sem hulye: ha csinalnanak egy olyan termeket, ami felvenné a versenyt pl. egy 2600K-val, raadasul lenyegesen dragabb lenne legyartani annal (lasd SNB vs BDZ die size), miert ne adnak dragabban vagy pont annyiert, mint a 2600K-t?"
Nagyon egyszerű:
1. Azonos áron a legtöbben Intelt vennének.
2. Növelni kell a piaci részesedést."a Larrabeet sem en rangattam be ebbe a vitaba"
De, indirekt módon, amikor azt írtad, hogy az Intel ritkán biházik és akkor sem nagyot...
-
Remus389
veterán
remeljuk azert a beszamolod utan kellemes csalodas er minket es egy a 2500k-t alulrol surolo proci lesz a legjobb bulldozer
a sisoftos eredmenyekrol:
a: jo lett volna ha azonos orajelen jarnanak az intel +200mhz elonye volt, picit szamit azert
b: a ilyen benchmarkok azert ugy vannak irva hogy inkabb az intel felepitesnek kedvezzen
c: gondolon a win7es drivert nem hasznaltak
d: talan meg sikerul javitani valamit rajta
a+b+c+d talan megkozeliti az sb-t, talan
de mar nincsenek illuzioim
-
Fiery
veterán
Rajtunk lehet nevetni, de nem mi fogunk milliardokat bukni a Zambezi fiaskon
Nekunk egyebkent baromira mindegy, hogy a Zambezi jo lesz vagy rossz. Ugyis lesz nalunk is egy diszpeldany belole, mint ahogy minden masbol is van. Ha sz** lesz, legalabb olcsobb lesz megvenni majd a procit 
Mert minden ellenkezo hiresztelessel ellentetben, a gyartok nem halmoznak el minket ingyen cuccal, megvesztegeteskent Pedig talan lenne az a hardver mennyiseg -
Remus389
veterán
lehet inkabb izzitani kellene a penzt egy SB 2500k@5.0 ghzre
bar raer amire en hasznalom arra egy wolfdale@3,6ghz is eleg(net+jatek, ritkan konvertalas)
az a nagy helyzet hogy sajnalok cpu-ra kiadni penzt, mert nincs ertelme
olyan vagyok mint egy opel astras aki sajnalja a penzt a mercire, mert amire nekem kell, ugyanugy kenyelmesen elvisz, teszi mindezt gyorsan+halkan+kis aramfogyasztassal
mondjuk a legjobb ilyen szempontbol egy i3as, gyors keveset fogyaszt olcso(meg a wolfdalenel is jobb), ketmagon tudja azt mint az AMD negymagosa kis tulzassal
-
Fiery
veterán
Igy van. Meg persze az AMD adhat(na) otletet arra is, hogy mit varialjunk at a benchmarkjainkban, hogy minel szebb eredmenyt kapjanak a termekeik. De akarmilyen meglepo, ilyenre nem volt me'g pelda eddig (Intel es VIA kapcsan sem). Alaposan elmagyaraztuk az AMD-nek, hogy a mi benchmarkjaink szemszogebol, ill. az architektura elemzese alapjan milyen problemakat veltunk felfedezni, ill. hogy szerintunk mi az oka annak, hogy X processzor Y benchmarkban Z beallitassal valahany %-kal meg tudja verni a Zambezit. Azt hittuk, majd azt mondjak, benan csinaljuk, es bennunk van a hiba. Azt hittuk, majd elmondjak, mit csinaljunk maskepp, hogy jobbak legyenek az eredmenyek. De nem volt semmi erdemi reakcio. Lehet, hogy csak csendben tudomasul vettek, hogy mi jol csinaljuk amit csinalnunk, de a proci ennel tobbre nem kepes. C'est la vie...
-
Fiery
veterán
válasz
Remus389
#240
üzenetére
>AMD szempontjabol annyira nem fontos, hisz a profit
>nagyresze a szerverekbol es a fusionokbol(laptop, olcso
>PC) jon nem pedig a kisszamu asztali PC fanatikusbol
>(workstation+gamer)Ennyi erovel nem is kellett volna ennyit erolkodni a desktop Bulldozerrel, inkabb csinalhattak volna egy 6 vagy 8 magos Stars architekturaju chipet (Llano plusz nehany mag minusz iGPU), oszt jo lett volna az a desktopra, nem?
Sot, az AMD lehet, hogy mar honapokkal ezelott megbanta, hogy nem ezt az alternativ megoldast valasztotta >nem lehetseges-e hogy a win7 bulldozer "driver"
>nagymertekben javit majd a teljesitmenyen?Egy olyan kernel patch, amivel a Windows utemezoje kulonbseget tudna tenni az egyes magok es "magok" kozott, hasznos lehetne. Talan.
>ti biztos a vegleges verzioju bulldozerrel dolgoztok?
Semmi sem biztos, hiszen a Zambezi me'g mindig nem kerult piacra. Lehet, hogy a B2 nem a vegleges desktop stepping, hanem a B3 lesz az, ami me'g iden jon. Vagy a C0, ami jovo ev elejen jon. Vagy ki tudja...
>tehat az AMD ezentul szerverekbe fog, fusionos
>gepekbe fog foleg szallitaniEn azert bizok abban, hogy ez a Zambezis "bukta" csak atmeneti lesz, es jovore magara talal ebben a szegmensben is az AMD.
-
-
#241
Fiery
veterán
VaniliásRönk
#238
Fiery
veterán
válasz
VaniliásRönk
#238
üzenetére
Ha az AMD nem tekintené fontosnak a szintetikus benchmarkokat, akkor se a Sandra iroja, sem mi nem kaptunk volna iden annyi segitseget es figyelmet toluk. De ha megis kiszallnak a bulibol, mi a lehetosegeinkhez merten ugyanugy folytatni fogjuk az eddigi munkat, azaz nem fogjuk feladni az AMD CPU-k tamogatasat es az AMD procikra valo benchmark optimalizaciot. Sajat jol felfogott erdekunk is, hogy ne huzzunk egyik iranyba sem. Az nVIDIA-val peldaul minimalis kapcsolatban vagyunk, megis tamogatja az AIDA64 az osszes piacon levo nVIDIA chipsetet es nVIDIA GPU-t.
-
Remus389
veterán
Kedves Fiery,
csalodassal olvasom a beszamolodat hogy az AMD a bulldozerrel talan nem is olyan jo asztali fronton, ha pedig hazon belul is megveri neha a Thuban az kinos(bar lattam mar ilyet amikor a phenom1est megverte a 6400+X2)
1. AMD szempontjabol annyira nem fontos, hisz a profit nagyresze a szerverekbol es a fusionokbol(laptop, olcso PC) jon nem pedig a kisszamu asztali PC fanatikusbol(workstation+gamer)
2. lepjunk ezen tul, vizsgaljuk meg mit tud felmutatni az SB ellen? azt mondod gyenge a mai felhozatalhoz
a: nem lehetseges-e hogy a win7 bulldozer "driver" nagymertekben javit majd a teljesitmenyen?
b: ti biztos a vegleges verzioju bulldozerrel dolgoztok?
egyebkent ha tenyleg nem nagy durranas es meg a 2500K-val is nehezen veszi fel a versenyt, az sajnos azt jelenti hogy a felsokategorias asztali pck piacan nem lesz arverseny
tehat az AMD ezentul szerverekbe fog, fusionos gepekbe fog foleg szallitani:-(
-
#237
Fiery
veterán
VaniliásRönk
#236
Fiery
veterán
válasz
VaniliásRönk
#236
üzenetére
Nem hiszem, hogy jol jarnanak. Ha nem tevedek, az elso 2 szoftverben vagyunk az FMA4 tamogatas kapcsan. Mi megyunk hozzajuk mindig, es ragjuk a fuluket, hogy az AIDA64 minel hamarabb tamogassa az uj termekeiket. Mar elkezdtunk targyalni a GPGPU benchmarkrol es egy un. platform benchmarkrol is, ami osszteljesitmeny pontszamot adhatna a CPU+iGPU parosrol, vagy aka'r egy CPU+iGPU+dGPU harmasrol is. Nem sok olyan ceg van a piacon, ami nepszeru benchmark szoftvert fejlesztene, es ilyen feszitett tempoban kovetne az iparagi fejleszteseket. Ha mi kiesunk, marad a Sandra, de a Sandra-fele Bulldozer leak miatt ennyi erovel a Sandra is kiesik -- sot, az esik ki elobb, mint mi. Akkor meg az AMD egyedul marad, mint a kisujjam
-
Abu85
HÁZIGAZDA
Én sem akarlak megbántani, csak túl sok feneket kerítesz a CPU-nak, amikor most lett kész két olyan Intel szabvány, ami nem fogad dedikált GPU-t. A platform lesz a kulcs, és ahogy hozza az Intel ezeket a dGPU-kat kizáró szabványokat ez egyre nyilvánvalóbb lesz.
Én egyelőre azt vallom, amit P.H. itt leírt. [link] - A jelenlegi fejlesztésekből ítélve ez a három cég erre megy.
Az Intel számára egyértelmű, hogy már nem tudnak ütőképes GPU-t építeni, így a lehető legerősebbek kell a procira koncentrálni (érkező AVX2 is ezt mutatja). Az NV-nél ugyanez, csak fordítva, és a GPU-ra koncentrálnak (az ARM miatt ez kötelező, és a CUDA erőltetése a cél). Az AMD a kettő helyzet között próbálja megtalálni az arany középutat.
Ebből lesz az a helyzet, hogy ez a mondatrész válik nagy igazsággá: ... az ez-egyiken-gyors-másikon-lassú éra nincs nagyon távol.
Ez magával fog hozni egy szegmentálódást. Ez sok vásárlónak jó lesz. Aki céltudatos, annak biztos, aki nem, hát ők jobb, ha céltudatossá válnak, mert itt tényleg olyan lesz, hogy az egyik, lapka töredéksebességet hozhat egy programban a másikhoz képest, míg egy másik alkalmazásban ez pont fordított.Én a Larrabee-t azért nem tekintem GPU-nak, mert mégis egy GPU-nál minek olyan memória architektúra, hogy az egyik mag, szinte azonnal elérje a másik mag adatát. Ez ok egy 2-8 magos procinál, de a Larrabee-nél 500+ szálról beszélünk. Teljesen kivégzi a teljesítményt ez a modell. Lehet, hogy a Larrabee nem CPU, de hogy nem GPU az is biztos.
Vagy ha GPU, akkor egy alapjaiban elrontott rendszer. -
#233
Fiery
veterán
VaniliásRönk
#231
Fiery
veterán
válasz
VaniliásRönk
#231
üzenetére
Miert ne kapnank? Mondtam en konkret szamokat? Lehet hinni nekem egyaltalan? Sokan azt szeretnék hinni, hogy nem lehet nekem hinni
Lehet remenykedni abban, hogy nincs igazam, szivetek joga Egyebkent akarmilyen hihetetlenul is hangzik, en az AMD-nek szurkolok. Rendkivul szimpatikus ceg, csak sajnos nem mindig sikerul jol vegigvinniuk a remek otleteiket. Csinaltak mar nagyobb marhasagot is, mint a Bulldozer, es azt is tuleltek. Ezt is tul fogjak elni, Ti meg itt a forumon plane tulelitek. Nehanyotok vesz majd Bulldozert, mert nem kell abszolut ertekben csucs teljesitmenyu CPU, es az ar/ertek arany megfelelo lesz. Azok is Bulldozert vesznek majd, akik nem akarnak mast venni, mint AMD-t. Akiknek meg a leheto legnagyobb teljesitmenyu CPU kell desktopra, azok szepen csendben elballagnak a boltba, es vesznek egy SNB-t.
-
#231
VaniliásRönk
nagyúr
Fiery
#228
-
Fiery
veterán
Ez nem ilyen egyertelmu. Az SKU-k arazasa egy adott termekcsaladon belul nem all linearis aranyban a teljesitmennyel. Max. az lehetne referencia, ha az FX-8150 alatti FX SKU lepcsot hasonlitanad a 2500K-hoz, arban es teljesitmenyben is. De felesleges is SKU-t SKU-hoz hasonlitgatni, eleg annyi, hogy altalanossagban a csucs FX olcsobb, mint a csucs SNB, ergo nem lesz gyorsabb annal. Ilyen egyszeru az egesz
-
-
Fiery
veterán
Nem akarlak bantani, de en vegig a 2011-2012-es AMD es Intel CPU termekekrol beszeltem, a Larrabeet sem en rangattam be ebbe a vitaba. Siman lehet, hogy _hosszutavon_ a Bulldozer architektura egy jovobeni frissitese/kiegeszitese, parositva az AMD rendkivul versenykepes iGPU-ival egy nagyon eros APU-t fog eredmenyezni, ami ar/ertek aranyban es/vagy abszolut teljesitmenyben is tulmutat _majd_ az Intel aktualis jovobeni megoldasain.
En csupan azt probalom erzekeltetni, kulonfele modokon (mivel konkret szamokat nem mondhatok), hogy -- es akkor nevezzuk neven a gyereket -- az FX processzor mint termek egyszeruen nem lesz versenykepes -- ha lesz egyaltalan. Az AMD sem hulye: ha csinalnanak egy olyan termeket, ami felvenné a versenyt pl. egy 2600K-val, raadasul lenyegesen dragabb lenne legyartani annal (lasd SNB vs BDZ die size), miert ne adnak dragabban vagy pont annyiert, mint a 2600K-t? Ha viszont nem sikerult olyan jol, mint egy konkurens termek, es nincs olyan presztizsuk, nevuk a piacon, mint a konkurencianak (Intel), akkor csak arban tudnak alavagni a konkurens termeknek. Raadasul az arkulonbseg eleg durva is...
Megjegyzem, a Larrabee GPU, es nem tud CPU lenni, hiszen ahhoz pl. be kellene tudnia bootolni egy operacios rendszert. Es nem egy hobbibol Larrabee-re portolt alap Linux kernelre gondolok
-
-
Abu85
HÁZIGAZDA
Rendben van, hogy CPU-to-CPU összehasonlítást csinálsz, de szerinted a dark silicon problémája hány generációig tartható homogén többmagos chipekkel? Most sem lesz SB-E prociból 8 magos asztali fronton, mert nem lenne a magok órajele 3 GHz fölött. A dark silicon problémája már most tetten érhető, és generációról generációra rosszabb lesz. Ez szimplán fizikai jelenség, és kivédhetetlen. Ahogy anno véget vetett az egymagos procik karrierjének, úgy véget fog vetni a homogén többmagos chipek karrierjének is.
Azon lehetne vitázni, hogy a Larrabee micsoda. Inkább CPU mint GPU, legalábbis az, hogy az egyik mag egy órajellel később már eléri egy másik mag adatát, egyáltalán nem GPU tulajdonság. GPU-n is van szinkronizálás, de ott több órajeles léptékben, addig a magok dolgoznak a saját kis feladatukon, majd a fejlesztő ezt az egészet kontrollálja.
Természetesen a vállalatok hosszútávú tervében a system integration szerepel, és az Intel a Larrabee-vel akarja ezt megcsinálni. Pár főmagból, és egy csomó Larrabee magból áll majd a rendszer, ami 2015-2016 után jön. Addig persze folytatni kell az integrálást, mert a dark silicon jelensége nem vár 2015-2016-ig. 2013-2014-től már nem számítok olyan processzorra, amiben nincs IGP. Más lehetőség nincs a teljesítmény drasztikus növelésére, hacsak nem nő jelentősen a fogyasztási limit. Persze meg kell csinálni azt, hogy a CPU és a GPU magok teljesen koherens gyorsítótárt használjanak, és közös legyen a címtér. Ez lényegében a fúzió következő lépcsője. Az persze lehet, hogy az Intel ezt kihagyja, legalábbis az AVX2 erőltetéséből én erre következtetek. Viszont a heterogén többmagos chipek elkerülhetetlenek. A 2015-2016-os lépcső arról szól, hogy a CPU és a GPU közötti logikai különbség legyen elfedve. Cell-szerű chipek várhatóak. -
#222
#95904256
törölt tag
VaniliásRönk
#221
#95904256
törölt tag
válasz
VaniliásRönk
#221
üzenetére
Úgy érted adjak kölcsön procit meg lapot, hogy letesztelhesd?
Lehet róla szó... Van jó pár ilyen proci a gyűjteményemben. -
#221
VaniliásRönk
nagyúr
#95904256
#218
VaniliásRönk
nagyúr
válasz
#95904256
#218
üzenetére
A lenyeg a hsz elso resze, tehat hogy nem a memoria a problema.
#222: Ha nem gond kerlek merd le, hogy mi az eredmeny, ha DDR-200-zal megy alaporajelen, meg a DDR-333-mal. Aztan tuningold FSB : RAM 1:1-ben.
A tavolsag miatt szerintem a postazas sem jatszik, a szemelyes talalkozas meg meg kevesbe... -
#218
#95904256
törölt tag
VaniliásRönk
#217
#95904256
törölt tag
válasz
VaniliásRönk
#217
üzenetére
Valóban nem tévedsz, nem annak készült. De ettől még elég jól lehet következtetni az architektúrák teljesítményére, ha nem tévedek...
-
#217
VaniliásRönk
nagyúr
#95904256
#215
VaniliásRönk
nagyúr
válasz
#95904256
#215
üzenetére
En meg ezt szivesen megneznem magasabb FSB-vel es visszaosztott, meg lassabb memoriaval.
A TDP megint egy masik kerdes, ha a tuningpotencialt es az elerheto teljesitmeny-maximumot viszgalod zero jelentosege van. Az a teszt sem architekruralis osszehasonlitasnak keszult mint sok masik sem, ha nem tevedek.
#216 Fiery: En csak azt nem ertem miert okoz ez neked ilyen beteges oromot... de biztos tortent valami a laboratoriumodban, ami kiverte a biztositakot.
-
#215
#95904256
törölt tag
VaniliásRönk
#214
#95904256
törölt tag
válasz
VaniliásRönk
#214
üzenetére
Igen, egyértelműen az.
A Banias a maga idejében korszerű architektúra volt, akárcsak a K8-as. De mobil processzornak készült ( TDPmax = 24,5W ), míg a K8 asztali processzornak ( TDPmax = 125W ).
Dezz érdekes módon linkelt is egy hozzászólást, hogy az órajelet "ne buzeráljuk" és adjuk meg a lehetőséget a K8-asnak, hogy 5-ször akkora fogyasztás mellett gyorsabb lehessen. Szerintem egyértelmű, hogy nagyobb energiabüdzséből gyorsabb lesz, de ez nem az architektúra hibája.
(#206) dezz: "De mi lett volna az az erős architektúra? A K8-cal kb. egyidőben (3 évvel a P4 után) megjelent Banias és a 3 évvel később megjelent Yonah (Core Solo/Duo) is gyengébb volt nála. Csak a további 7 hónappal később kijött Conroe (C2D) tudta megfogni."
Sőt, még azt is hozzá lehet tenni, hogy a Core ( Yonah ) és a Core2 ( Conroe / Merom ) közt az egyik legnagyobb teljesítménybeli különbséget az adta, hogy a Core2 a dupla széles FPU miatt az SSE utasításokat már nem két részre bontva hajtotta végre. Az meg biztos, hogy nem ettől "tudta megfogni" a K8-at, hiszen az AMD-nél ez a korszak csak a K10-zel jött el...
-
#214
VaniliásRönk
nagyúr
#95904256
#212
VaniliásRönk
nagyúr
válasz
#95904256
#212
üzenetére
Komolyan ugy gondolod, hogy az alacsony memoriasavszelesseg a jelenseg gyokere?
#213: dezznek szerintem az a baja, hogy fLeSs eloszeretettel tuningolt Intelt ugy, hogy az a rendszer szuk keresztmetszetet szelesitesette, AMD-t meg ha tuningolt is lehetoleg olyan modon tette, hogy a szuk keresztmetszet valtozatlanul megmaradjon. (pl. K10-es processzorokat szorzoemelessel tuningolt, hogy az NB orajele veletlenul se emelkedjen, kovetkezeskepp a tuning vajmi keveset valtoztatott a rendszer teljesitmenyen)
-
#212
#95904256
törölt tag
VaniliásRönk
#209
#95904256
törölt tag
válasz
VaniliásRönk
#209
üzenetére
Az Intelnél régóta bevett dolog, hogy a mobil processzorok fogyasztásának visszafogása érdekében az FSB sebességet alacsonyan tartják. Ennek következtében a memóriasávszélesség is alacsony, de gondolom számodra is látszik a linkelt szinetikus tesztekből ( épp a Dothannál a legalacsonyabb, nahát... ). Szóval erről árulkodik.
-
Fiery
veterán
(ez mar tenyleg kezd nagyon offtopic lenni...) A P4 kapcsan csupan az a bajom, amivel az Intel is kuzdott anno: hiaba terveztek nagyon magas orajelekre (4+ GHz), keptelenek voltak elerni, me'g nagy aldozatok aran sem. Szoval ahhoz, hogy igazan versenykepes legyen (anno a K8 elleneben), irrealisan magas orajeleket kellett volna elernie.
A K8 nagyon jo architektura volt a maga idejeben, de nehezebb dolga lett volna, ha nem lett volna egyertelmuen jobb, mint az akkori legjobb, amit az Intel le tudott tenni az asztalra. Az Intel anno nagyon szetforgacsolta a fejlesztesi kapacitasait, hiszen parhuzamosan futott a Banias, a Netburst es az Itanium aktualis iteracioja is. Ha a 3 vonalat osszefuttatta volna idoben az Intel, akkor a K8-nak jobb konkurenciaja lehetett volna a maga idejeben. De ha az AMD idoben (azaz mar 3-4 evvel ezelott) kihozza a Bulldozert, nagyot szakithatott volna megint, hiszen a Nehalemet es a Sandy Bridge-t is kicsit keson lépte meg az Intel. A Bulldozer pl. egy Core 2 elleneben sima gyozelem lett volna. De tul sok a "ha" es a "lett volna" ebben az egeszben
-
#209
VaniliásRönk
nagyúr
#95904256
#208
VaniliásRönk
nagyúr
-
Yutani
nagyúr
Szerintem nem akarja elvitatni a K8 érdemeit (nem is lehet a tényeken változtatni), mivel jó proci volt, amikor megjelent, és olyan képessége is volt (CnQ), amit az Intel csak 3 évvel később, a C2D-vel hozzott el desktopra. Nekem például ezért is volt mindig szimpatikusabb a K8, mint a P4.
-
dezz
nagyúr
Akkor eléggé félreérthetően fogalmaztál. De mi lett volna az az erős architektúra? A K8-cal kb. egyidőben (3 évvel a P4 után) megjelent Banias és a 3 évvel később megjelent Yonah (Core Solo/Duo) is gyengébb volt nála. Csak a további 7 hónappal később kijött Conroe (C2D) tudta megfogni. Az Intel sem tud csak úgy előkapni valamit a cilinderből... De amúgy miért állítod be úgy, mintha a P4 mindenestül olyan rossz lett volna? Évekig elég jónak számított, csak utána már egyre nehezebbé vált az órajel emelése. Nem kéne ennyire elvitatni a K8 érdemeit...
-
Fiery
veterán
>Szóval, ez már a sci-fi kategóriája, hogy ha az
>Intel a P4 helyett (vagy akár közvetlenül utána)
>a SandyB-t hozza ki, akkor a K8 nem festett
>volna olyan jól... Hát, erre csak azt lehet
>mondani, hogy: pfff...En nem ezt irtam. Hanem, hogy az architekturat tekintve a P4 (Netburst) kozel sem volt olyan izmos cucc (az akkori kor technologiai fejlettsegehez merten), mint a SNB napjainkban. Vagyis, a K8-cal sokkal konnyebb volt aratni, mert nem tamasztott az Intel olyan eros konkurenciat, legalabbis az architekturat tekintve. A SNB elleneben egy zsenialis, korszakalkoto, foldet megrengeto architektura tudna csak "ütni". A BDZ nem ilyen, sajnos. Vannak jopofa otletek benne, persze...
Az L3 latency pedig nem sokat jelent, legalabbis az architektura szempontjabol. Majd meglatjuk, milyen lesz az "uj" B2 vagy a B3 vagy a C0. De ha az AMD ilyen sokat kell hogy faragjon a steppingeken, akkor me'g a vegen 2012-ben lesz csak BDZ, epp mielott az Ivy Bridge megerkezne. Az ido -- es az Intel -- borzasztoan ellenuk dolgozik
-
dezz
nagyúr
Találtam:
"Well,
The latency results for simple sequental access show that prefetching is disabled in this ES....
In Sandy Bridge preftching reduces the L3 latency by a factor 2 or so. Latency reduction is responsible for most of Sandy Bridge's IPC increase over Nehalem.
Regards, Hans"
(Hans de Vries, a napokban napvilágot látott Sandra eredményekkel kapcsolatban.)
És úgy tűnik, a B2-ből is több különböző van... Anand szerint pl. ami 2 hétnél korábbi gyártású, az eleve "nem játszik".
(#202) Henkei: Arról nem beszélve, hogy nem éppen 1 lépésben értek el ők sem a P3-tól a SandyB-ig... Először a Core Solo és Duo jött, amit PC téren csak mobil vonalon indítottak (az Apple viszont ezzel indította az x86 alapú gépeit desktop vonalon is), aztán a Core2, és így tovább. Szóval, ez már a sci-fi kategóriája, hogy ha az Intel a P4 helyett (vagy akár közvetlenül utána) a SandyB-t hozza ki, akkor a K8 nem festett volna olyan jól... Hát, erre csak azt lehet mondani, hogy: pfff...
Ejnye, mintha Fiery néha valami olyat szívna/szúrna/dobna/akármi, amit nem kellett volna...
-
Henkei
tag
japersze. ha nagyanyamnak meg femkerekei lettek volna akkor villamosnak hivtak volna es nem jutkanak. ha meg az elso core i7 20 szazalekkel gyengebbre sikerult volna akkor a phenom 2 is mas kepet adott volna. hurra mert sikerult feltalalni a relativitast!!
a topicbol nekem eddig egyedul az derult ki biztosra hogy mitol olyan silany valami az aida mint amilyen.
-
dezz
nagyúr
"de me'g azokban az idokben sem tudott az AMD 50% piaci reszesedest sem elerni."
Amiben az Intel illegális praktikáinak is volt némi szerepe.
"Ha a K8 idejeben az Intel ilyen (lasd SNB) eros architekturat tett volna le az asztalra, akkor a K8 nem lett volna akkora nagy szam."
Ismered a mondást...
"A Pentium D-rol nem remlik, hogy barmi gond lett volna vele."
Egy systembuszon ült a két mag, ami sok alkalmazásban visszafogta, és a fogyasztás sem volt túl alacsony.
"Az Itaniumnak sosem volt AMD-fele konkurenciaja, es igy nem is szamit az AMD szemszogebol, hogy az Intel mit benazik vele."
Dehogynem, hiszen az IA32-t akarták leváltani vele mindenestül. Erre válaszul született az AMD64, ami végül meggátolta ezt a törekvést.
"A Larrabbee pedig nem egy CPU, en pedig az AMD es Intel CPU bizniszerol beszeltem."
Egyrészt általános kijelentés volt, másrészt a Larrabee egy CPU-cluster.
(#192): "Meg orajelben."
Abban csak kisebb mértékben.
"A 22 nanot pedig az AMD utolso 2 evet nezve nem egyhamar fogja a Bulldozer architektura elerni"
A 22-t egy ideig valóban nem, de jövőre legalább már 28nm-en jön.
"Mobil gepekben? Kotve hiszem."
Ott tényleg nem, de 4 Piledriver mag sem lesz olyan rossz elvileg.
Persze, önmagában van értelme a clocl-to-clock összehasonlításoknak, elméleti alapon. De a gyakorlatban nem csak ezen múlik a dolog, hanem erősen belejátszik az órajel is, márpedig a Bulldozert viszonylag magas órajelekhez tervezték, amit előbb-utóbb el is fognak érni.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
De ugyebár minket az általános teljesítmény érdekel.
(bocs, nem birtam kihagyni) Az egy regi roadmap, amibe utolag hekkeltek bele kekkel a megjegyzeseket. 100%-ra allithatom, hogy lesz FMA3, BMI es TBM a 610Fxx a Piledriverben. Hogy ezen kivul mi lesz es mi nem lesz, azt nem kivanom felfedni. 
Nekunk egyebkent baromira mindegy, hogy a Zambezi jo lesz vagy rossz. Ugyis lesz nalunk is egy diszpeldany belole, mint ahogy minden masbol is van. Ha sz** lesz, legalabb olcsobb lesz megvenni majd a procit 
Mert minden ellenkezo hiresztelessel ellentetben, a gyartok nem halmoznak el minket ingyen cuccal, megvesztegeteskent 
Persze Vér Istvánnak kötelező a drágább, jobb...
Új hozzászólás Aktív témák
- Xiaomi Redmi 12C 64GB, Kártyafüggetlen, 1 Év Garanciával
- Keresek gamer laptopot RTX 3050 , RTX 3060. RTX 4050 , RTX 4060
- Eladó szép állapotban levő Apple iPhone SE2020 64GB / 12 hó jótállás
- HIBÁTLAN iPhone 13 mini 256GB Pink -1 ÉV GARANCIA - Kártyafüggetlen, MS3408
- OLCSÓBB!!! Dell Latitude Precision XPS Üzleti gépek, 2-in-1 gépek, Vostro 8-12. gen.
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest