- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Szupervékony külsővel jöhet a Mix Fold 4
- Poco X6 Pro - ötös alá
- Sony Xperia 1 V - kizárólag igényeseknek
- Apple Watch
- Okosóra és okoskiegészítő topik
- Samsung Gear S3 - második kör
- Bivalyerős lett a Poco F6 és F6 Pro
- Vodafone mobilszolgáltatások
- Samsung Galaxy Z Fold4 - egyre megy, honnan nézed
Hirdetés
-
A Biden-kormányt is zavarja a big tech és az adatközpontok energiaéhsége
it Az energiaéhes adatközpontok és a big tech egyre növekvő igényei miatt elindultak a megbeszélések az USA kormánya és a tech szektor között: klímabarát áramtermelést akarnak.
-
Computex 2024: extravagáns üveg-alumínium házköltemény az In Wintől
ph A cég "lopakodó" alaplapokkal is kompatibilis, Signature sorozatú újdonságát szemügyre véve hirtelen azt sem tudjuk, hogy merre van az eleje és a hátulja.
-
Előbb csúcstábla aztán topmobil jöhet a OnePlustól
ma Középpontban a Snapdragon elit teljesítménye.
-
Mobilarena
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
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.
)[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
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.[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
#3680
P.H.
senior tag
VaniliásRönk
#3678
P.H.
senior tag
válasz
VaniliásRönk
#3678
üzenetére
Lehetséges, hogy félreértelmezem, de:
""Processor" shall mean any Integrated Circuit or combination of Integrated Circuits capable of processing digital data, such as a microprocessor or coprocessor (including, without limitation, a math coprocessor, graphics coprocessor, or digital signal processor) that is capable of executing a substantial portion of the instruction set of an AMD Processor or an Intel Processor."
Ebben nincs benne, hogy pl. a teljes AMD64 utasításkészletet ismernie kell az Intelnek.
"For purposes of this Section 3.9, "Indirect Infringement" means a claim for infringement where the accused infringer is not directly infringing the subject patent rights(s), but is in some manner contributing to a third party's direct infringement of the subject Patent Rights(s) by, for example, supplying parts or instructions to the third party that as a result of such parts or instructions enable such third party to infringe directly the subject patent rights(s). Indirect Infringement includes without limitation contributory infringement and inducing infringement."
Így, az Intel lenne vagy nem lenne ...-ben, ha az AMD-t megvenné valamely 'harmadik fél'. Avagy jogi kérdések tömkelege jönne itt, pl. az "infringe directly the subject patent rights" az utasítások mekkora részét engedi ilyen esetben használni, az eladott, a vevő és a 'sértett fél oldalán?
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
Volt hasonlóról szó #500 körül itt és ebben is.
A dolgot egy kissé megnehezíti, hogy egy-egy macro-op mérete több, mint 64 byte-nak tűnik.
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
Elképzelhető, hogy az új procik pl. alacsonyabb órajelen (magszorzóval) indulnak, és ha minden rendben, akkor kapcsolnak normál üzemmódba. (Tehát egyfajta forced C'n'Q-val indítanak.) Vagy akármi. Nyilván az AMD is gondolt erre.
Gondolt.
Power Control Miscellaneous Register CofVidProg (bit 31): COF and VID of P-states programmed. Read-only.
1 = Out of cold reset, the VID and FID values of the P-state register specified by MSRC001_0071[StartupPstate] have been applied to the processor.
0 = Out of cold reset, the boot VID is applied to all processor power planes, the NB clock plane is set to 800 MHz (with a FID of 00h=800 MHz and a DID of 0b) and core CPU clock planes are set to 800 MHz (with a FID of 00h=1.6 GHz and a DID of 1h).
MSRC001_0071 COFVID Status Register StartupPstate (bit 34:32): startup P-state number. Read-only. Specifies the cold reset VID, FID and DID for the NB and core based on the P-state number selected.
Vagy minden 800/1600 MHz-en indul K10-ben, vagy előre beégetett (akár a végleges órajeleknél kisebb) értékeken és feszültségen.
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
SZVSZ mindkettőtök érvelése tartalmaz egy-egy apró hibás következtetést.
akosf: Mint a fentiekből kiderül, az K10 tervezésekor megtartották maguknak azt a lehetőséget, hogy a CPU kisebb feszültség- és órajelértékekkel induljon, mint a névleges (emellett induláskor a teljes rendszerben egyetlen mag indul (Boot Strap Processor), a többi reset-jele egy ideig még él, amíg az indító mag el nem végez bizonyos tevékenységeket ~ el nem jut a BIOS bizonyos részéig). A folyamat úgy folytatódik, hogy először is megnézi a mag, hogy single-plane vagy dual-plane lapon van-e a rendszer, majd a további megismert információk alapján a végleges órajeltől kezdve, visszafelé haladva kiszámolja, hogy egy-egy P(erformance)-state-hez milyen elméleti Amper-mennyiség szükséges, és ha azokat a lap nem tudja szolgáltatni, egyszerűen letiltja azok későbbi beállítási lehetőségét (2.4.2.7 Processor-Systemboard Power Delivery Compatibility Check bekezdés a K10 BKDG-ben). Majd később kapcsol a megmaradt állapotok közül a legmagasabbra; előfordulhat, hogy a névlegesnél alacsonyabb órajelre. Ez a sima AM2-lapoktól is igényel(het) bizonyos kooperációs képességet. Tehát ez nem jelenti plusz teljesítmény elérését (hacsak úgy nem, hogy a folyamat 200 MHz-es external clock-ot vesz alapul a szorzókhoz, ha ezt emeled, akkor sem tilt le bizonyos állapotokat).
dezz: SZVSZ a helyzet fordított. Az AMD az AM2-specifikációk átadásakor érzékeltette, hogy egyes későbbi Phenom processzorai komolyabb elvárásokat támasztanak e téren (vagy nem futnak a névleges órajelükön), ezért az definíciók feletti 'biztonsági tartalékokat' a gyártók komolyabban vették, ezért rendelkeznek jelentősebb tuningpotenciállal az AM2-be tervezett legnagyobb K8-ak is.
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
Nem akarok nagyon belefolyni az üzleti politikába, de van arra valami magyarázat, hogy az AMD miért nem fektet nagyobb hangsúlyt jelenleg a K10-alapú dual-core megoldásokra?
Mindenhol a négy- vagy hárommagos megoldásuk folyik a csapból is (illetve nem is folyik, csak csepeg), de a nagy többség akkor is egy kétmagos megoldással elégedett lenne, tekintve az Intel dual-core és quad-core topikok látogatottságát (és továbbra is fenntartom, amit korábban említettem, hogy SZVSZ egy kétmagos, 4 GHz-ig skálázódó, K10-alapú termékvonaluk kihúzná őket a jelenlegi mocsárból rövid távon).
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
#3895: Nagyjából erre gondoltam, amit az első bekezdésben írsz.
#3896: Tudom, mikorra tervezik, azt nem értem igazán, csak miért akkorra.
#3897: Ha le is lehetett szűrni régóta, hogy a elsősorban a szerver-piacra tervezik a K10 első verzióit, amellett azért nem tudok elmenni szó nélkül, hogy mindezt egy 'béta-terv' (~ mainstream megoldás) nélkül tették, és úgy néz ki, ilyen egészen a közelmúltig nem volt náluk (hozzátéve, hogy egy quad->dual megoldás tervezése sokkal könnyebb, mint egy single->dual-é. Főleg, hogy single megoldás a K8 tervezése óta nincs is igazán az AMD fegyvertárában.)
#3899: egyetértek
+ ennek a magletiltogatós játékhoz is kellett volna lennie mára üzleti alapnak.
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
"Ha arra gondolsz, hogy a K10 mellett párhuzamos folynia kellett volna egy kétmagos K10 fejlesztésnek is, akkor igen, így lett volna az igazi, de ha belegondolsz, hogy a K10 milyen kínszenvedés közepette látta meg a napvilágot, akkor gondolhatod, hogy miért nem így történt."
Igen, az akkori piaci környezetben, amikor elkezdődött a tervezése (és még ma is) ez lett volna az igazi (mert nem sok plusz-munkát igényelt volna; vagy semennyit sem, mert: )
"Nyilván arra appelláltak, hogy a hibás K10-eket fogják eladni letiltott magokkal."
Ehhez hozzáteszem, amit Raymond írt valamely topikban, hogy a jelenlegi kapacitással legyártott négymagos K10-ekre sincs igazán felvevőpiac. Erre értem, hogy nincs az AMD-nél kidolgozott üzletpoilitika jelenleg (miért nincs?) a letiltott magos változatok propagálására és eladására sem.
#3907: nyilván a hiba is szerepet játszik (főleg az, hogy az MS nem adott ki javítást, mint a Core 2 bug-ra), az árat meg szerintem gyorsan mérlegelni fogják (gondolom, hozzáértők irányítják az AMD piaci stratégiáját is).
Bár nem jött össze az nekik, mint az X2-nél.[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
Nagyjából úgy nézett ki a képlet a Core 2 TLB-bugnál, hogy az OpenBSD részéről De Raadt a sárba gyalázta a processzort, Linus Torvalds kifejentette, hogy jelentéktelen a hiba, az MS kiadott egy javítást. (Az Intel meg kiadott később egy kiegészítést a System Programming Guide-hoz a TLB-ről...)
Most az AMD-bugnál az OpenBDS csendben van, az AMD kiadott egy Linux-kernel patch-t ("Linux users may have another option in the form of a patch for that operating system's kernel. Sources estimate this patch's performance hit at less than one percent, but it comes with several caveats") és egy BIOS-patch-t is, (mert) az MS nem tervez részt venni a hiba javításában. ("At present, Microsoft doesn't offer a Windows hotfix to address the problem, and our sources were doubtful about the prospects for such a patch.").
Mindegy, a lényeg, hogy minél hamarabb kellene lennie kétmagos K10-nek is.
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
Mivel még mindíg tart a K10-uborkaszezon, erre visszatérek még egyszer.
A tavaly nyári hírek szerint a kétmagos megoldások 2008 elejére (Q1) jöttek volna - akkor még szó nem volt X3-ról -, alig pár héttel a Phenom-ok után, emiatt feltételezem, hogy a négymagos és a kétmagos tervek külön-külön, egyszerre futottak egy ideig, más felépítéssel. Most ott tartunk, hogy a négymagos és a hárommagos megoldásokról szinte mindent tudunk pro és kontra, a kétmagosról szinte semmit, olyannyira, hogy nem alaptalan a feltételezés, hogy az első dual-core CPU-k a négymagosok nagyon hibás verziói lesznek (íme az AMD elrontott marketing-je). Pedig nem hiszem, hogy úgy gondolták, hogy a 'féltenyérnyi' Phenom-magmérettel majd 'leigázzák' a desktop-világot.
Ezek fényében lesz kétmagos Q1 helyett Q2: abban a stádiumban, hogy pár hónapon belül indulnak a kétmagosok piacra, hol tart a folyamat? Mennyit is kellene mostanság tudni róluk? Szétnéztem, lehet, hogy átsiklottam valami felett, most szinte semmi információ.Elsősorban az sem világos, hogy miért csúsznak vele. (Gyártási problémák? Áttervezés? Nagyobb figyelem a szerver-vonalra? TLB-hiba? Pedig utóbbi lehet a leggyengébb érv, mert ebből nem lesz(?) többutas megoldás; kevesebb mag is van, és feltételezve, hogy a hiba tényleg nem függ közvetlenül az órajeltől; bár csak az alacsonyabb órajelű Phenom-ok kaphatók.) Mindenhol szinte ugyanazt találom (amit a PH!-hír is közölt).
Továbbá pl. sem a méret, sem a tranzisztorszám, sem a tervezett fogyasztás nem ismert eddig, a cache-méret sem biztos (és igen, lehetséges, hogy tényleg 2x1MB L2-t terveznek), sem az induló órajel.4 GHz: Ennyire nem hatott komikusnak még nyáron, és most sem adtam megvalósíthatósági tanulmányt mellé, csak spekuláció. A kétmagos K10-eket muszáj az akkorra megmaradó (és azt gondolom, a jelenlegi) K8-vonal teljesítménye fölé pozicionálni. Lehet ebben a kérdésben óvatosan fogalmazni ("Thus far, all of AMD's guidance has pointed towards a 3GHz Phenom late in the second quarter. If AMD can launch a Kuma CPU in the 3.2-3.4GHz range around the same time, it'll improve the company's competitive standing during the critical back-to-school period.", de minek? Úgy néz ki jelenleg, hogy ha a kétmagosok induló órajele 2.6-2.8 GHz-en fog tetőzni (ha az év végéig ez - 65 nm-en - emelkedik is, az sem lesz gyógyír), akkor már most el lehet kezdeni a róluk szóló teszt konklúziójának írását. Vagy 'rágjam végig a körmöm' nyáron a tesztjük olvasása alatt, hogy jobb lesz-e, mint egy mostani 6400+?
Szerintem.
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
Amik a K8-ban is voltak:
- Machine Check Architecture
- Chipkill ECC
- egy-egy scrubber az ECC-védett L1D-hez, L2-höz és DRAM-hoz
- a memória-scrubber támogatja a DRAM Scrub Redirect-etA K10-zel kapcsolatban több helyen lehet olvasni a
- HT Retry Protocol-ról
- memóriatükrözésről
- data poisoning-ról
de hiteles forrást nem találtam eddig ezek támogatásáról.Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
Mindhárom lehetőség forrása ez a 2006-os prezentáció lehet (a 22. teljes oldal). A HT Retry a BKDG szerint már támogatott, a memory mirroring lehetősége adott az unganged mode miatt/mellett (bár nem látom nyomát sem a BKDG-ben, pedig ott kellene lennie), a data poisoning meg lehetséges, hogy nem is oda, a BIOS-hoz tartozik.
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
Nem az volt eddig az elfogadott hozzáállás, hogy a cache-ek jóval keveset fogyasztanak 'magokhoz' képest?
Arról van valami infó, hogy az új, DDPM-képes Opteron-lapok hogyan fognak viszonyulni a későbbi 45 nm-es CPU-khoz?
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
válasz
#95904256
#4653
üzenetére
Olyan sok különbséget nem látok a kettő között, sőt, semmit, így ránézésre (a Core0-on jobban látszanak az L1 cache-ek és buffer-ek, talán Core1-en a mag funkcionális egységek jobban kivehetőbbek).
Hacsak nem arra gondolsz, hogy a 2x64-bit FPU két része (ha jól tévedek, a négyosztatú magon - a K8-as FPU - Data & Load/Store - Integer - Instruction/Decoding felépítésből kiindulva - a legfelső rész az) inkább 1:2, mint 1.5:2 osztást mutat.
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
válasz
#95904256
#4657
üzenetére
Az FPU-részek méretét benéztem, a keret letakarja a mag egy részét. Viszont épp készítettem ezt a képet (kicsit jobban látható invertált és kissé kiemelt képen a Shanghai mag, 10%-kal kicsinyítve a Barcelona -maghoz), amikor feltűnt valami:
A L1D - Load/Store - Data TLB és az FPU határán bal oldalon, az eredeti képen vörösen, az invertált képen kéken derengő vékony vízszintes sáv nem volt Barcelonában. Valami hasonló sejlik az invertált képen (de nem bírom kinézni, a felirat takarja) L1C - Decode- Instruction TLB és az integer egység között is ugyanúgy bal oldalon. Vajon mik lehetnek azok?
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
válasz
Raymond
#4663
üzenetére
Értem. Nagyon eltérőt mást ebben a felbontásban sem lehet találni a magokon belül, csak két másik dolgot:
- megfordították az L2 cache-eket
- a Northbridge látható része némileg eltér a korábbitólfLeSs #4664: Ezt hogy érted?
A képen csak azt akartam mutatni, hogy láthatóan a 128-bit SSE-t úgy érték el, hogy a korábbi 64 bites végrehajtókat megduplázták fizikailag (a K8-as képet innen fordítottam be 90 fokkal, és kicsinyítettem.[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
Sokadszor újragondolva a dolgot, most úgy vélem, hogy nem kellene hájp-nak nevezni azt, ami itt történt, és az AMD 'csinálta'. Mindvégig szem előtt volt a hiba leírásában, mégsem kapott elég nagy hangsúlyt:
"In this case, the MC4 status register (MSR 0000_0410) will be equal to B2000000_000B0C0F or BA000000_000B0C0F. The MC4 address register (MSR 0000_0412) will be equal to 26h."
Bár magának a hibának sok gyakorlati jelentőséget a mai napig nem tulajdonítok (»nagyon« szerencsétlen helyzet kell ahhoz, hogy a hiba hatása kézzelfogható problémát okozzon), az Opteron-ok célterületén a Machine Check Architecture nem csak egy pipa az Everest-ben a CPUID-fülön, hanem nagyon komolyan vett dolog, a Machine Check Exception-ön túl is: "Machine check errors are either recoverable or irrecoverable. Recoverable errors are those that the processor can correct and, thus, do not raise the machine check exception (#MC). However, the error is still logged in the machine check MSRs and it is the responsibility of the system software to periodically poll the machine check MSRs to determine if recoverable errors have occurred. If a recoverable error has been logged in the machine check MSRs, a second recoverable error can overwrite it." (K8 BKDG)
Úgy eladhatatlan egy server-processor, hogy (vélt vagy valós) L3-hibát jelez, le is álltak velük (pl. "Now the L2 and L3 cache have the same data, which shouldn't happen given AMD's exclusive cache hierarchy. If the line in L2 gets evicted once more, it'll be sent off to the L3 and there will be a conflict creating a L3 protocol error." [link])
Azt pedig nehéz lett volna megmagyarázni, hogy az Opteron-ok hibája egyáltalán nem jelentkezik az Phenom-okban. Még akkor is, ha a desktop OS-ek nem figyelik és loggolják folyamatosan az MCA-státuszt, csak a kivételre 'ugranak'.[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
#4887
P.H.
senior tag
Balala2007
#4880
P.H.
senior tag
válasz
Balala2007
#4880
üzenetére
Még nem néztem bele az AVX doksiba, de amit leírtál, arról ezek jutottak eszembe (csak a bekezdések elejét idézem, remélem, nem zavaró):
- ("SSE5 nem definiál uj architekturalis allapotot"...) a kérdés, az OS-gyártók (pl. a Microsoft) mennyire fog az AVX mellé állni, gondolok itt arra, mennyire fog visszamenni - Win98? WinME? Win2K? WinXP? Vista? - a patch-csel. Az SSE5 minddel használható lesz.
- ("SSE5 ortogonalis, azaz a regiszterek"...) az x86 egyre inkább arra haladt, hogy ortogonális megoldást adjon szinte minden korábbi register-specifikus megoldásra. Nem tudok indokot találni arra, miért jó visszatérni ehhez a szemlélethez.
- ("Az AVX a boviteseket a 2 vagy 3 byte-os VEX"...) az AMD elég korán elkezdte használni az 0F0Fh prefixet, az Intel a REP/REPNZ és az adatméretváltó byte-okat erőltette eddig. Szerintem ennek inkább decode-egyszerűsítési és valamilyen jövőbeli kiterjeszthetőségi okai vannak. Logikus, bár áldozattal jár.
- ("Az AVX onmagaban csak az alap float és"...) érdekes. Az általános, hétköznapi CPU-orientált média(/image)-alkalmazások inkább felszorzott integer adatokon dolgoznak, ahogy eddig láttam (bár mondjuk én jobban szeretem az fp-megközelítést). Talán az Intel minőségi okok miatt nem erőlteti az integer-t (DCT/IDCT, átméretezés, stb) a nagyobb adatmennyiségen dolgozó algoritmusoknál; kb. ott lehet sebességben így (jobb minőség mellett), mint a kisebb méretű integer-utasításokkal.
- ("Az SSE5 tartalmaz egy olyan FMA supportot, aminek az a hátránya"...) 16-os register-készletre nem hiszem, hogy célszerű alkalmazni valódi négyoperandusos műveleteket (több memóriaoperandus pedig kényszerűen megnöveli pl. az utasítás méretét).
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
válasz
#95904256
#4895
üzenetére
Azt hiszem, volt erről forrás is, de logikailag is szükségszerű: a fizikai címből eggyel több bitet használnak fel az L3 indexelésére, ekkor kijön 4 MB, és másfélszeresére növelik az asszociativitást, így jön ki a 6 MB.
A K8-as L2 esetén a fizikai címből jövő indexelő bitek számával játszottak (ennek a hibaleírásnak a 6. pontjában konkrétan le is írják ezt), az asszociativitás nem változott 256-512-1024 KB L2 esetén, a Core2-nél viszont fordítva van, azt hiszem: ahogy csökken a családok L2-mérete, annál kisebb az asszociativitás.
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
válasz
#95904256
#4897
üzenetére
Penryn: 6 MB / 24 utas
Már csak egy teszt hiányzik, hogy ez az asszociativitás-változás mennyiben befolyásolja a késleltetést náluk (sejtem, nem sokban: az asszociativitás elméletileg párhuzamos hozzáférést feltételez).
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
válasz
#95904256
#4899
üzenetére
Ha valóban ekkora (órajelekben mérhető) hatása van a késleltetésre önmagában az asszociativitásnak (és most csak maradjunk a Merom-családon belül, ott igazán érdekes a kérdés, főleg visszafelé), akkor az E1xxx-es felvetés jogos is lehet - bár én nem hiszem.
De azt se feledjük, hogy itt (Barcelona-Shanghai esetén) cache-növekedésről is beszélünk, magasabb asszociativitás mellett (meg még esetleges órajel-változásról is).
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
válasz
#95904256
#4923
üzenetére
Ezek csak találgatásoknak tűnnek megalapozott információk helyett, én azon gondolkodok inkább, hogy a találgatások között miért volt fontos kiemelni azt, hogy "- Not VLIW, still OoO superscalar architecture"
De ha meg akarnám magyarázni a dolgot, erre és erre indulnék el (amit eddig Hans de Vries legnagyobb tévedésének tartottam, máig nem tudom hova tenni).
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
válasz
#95904256
#4927
üzenetére
Feltételezve, hogy a "szerk:" részt nekem szántad:
Nem könnyű radikálisan új felépítést alkotni ("az aktuális K7-K8-K10 nagyon is jó"? volt erre egy hsz-em tavaly: "Az, hogy az AMD miért nem tudja járatni ezt az alapvető felépítést az annak „megfelelő” órajelen (szerintem egy olyan 4 GHz-ig kellene dual-core K10-nek skálázódni, hogy megoldódjanak rövidtávon az AMD problémái), ezt pontosan nem tudjuk, de lehetséges, hogy ennek okát nem a szűk értelemben vett magokon belül kell keresni." De jelen pillanatban én nem tudom, hol kellene keresni az okot.)
- branch-prediction eljárások (és amekkora megbízhatósággal rendelkeznek) nem hiszem, hogy manapság fontosabbak lennének a megfelelő prefetch-algoritmusoknál.
- OoO hatékonysága: ezen a téren SZVSZ az AMD teljesen jó úton jár, lásd pl. a VIA Isaiah-t, ahol ugyancsak egy-egy port-hoz külön ütemező (RS) járul. (Te írtad anno, hogy az Intel érzékenyebb az utasítássorrendre, mint az AMD.) De az AMD-féle egyszerű pack-stages átrendezésnek sincs tovább jövője, látszik, hogy a többiek kifinomultabb algorimusokat alkalmaznak.
- lebegőpontos végrehajtás: persze, minél gyorsabb, annál jobb. Jó kérdés, hogy min múlnak a tervezési szempontok: a VIA össze tudott hozni 2 clock-os összeadást, az Intel 3 clock-ost, az AMD 4-est. Abszolút nem tükrözik a számok az erőviszonyokat, a szükségleteket és az anyagi hátteret.
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
válasz
#95904256
#4931
üzenetére
- SZVSZ a találati arány általában messze 80-90% felett van jó ideje, a prefetch-megoldások a döntőbbek inkább, adat-megközelítésben ezek sokkal kisebb találati aránnyal rendelkezhetnek.
- Nem értem pontosan, mire gondolsz itt, a függőségek esetén. (ok, INC nincs, ECX >= 8
). A VIA és az AMD esetén jól lehet látni, milyen módon oldják meg a portok közti elosztást (~FIFO, alap -> szabályok); az Intel-nek sincs sokkal több órajelbeli (= több lépcsőjű) ideje ezt a leosztást megoldani a közös ROB/RS-sel, tehát nagyon bonyolult nem lehet (csak nem utasítássorrendbeli egyszerű "balról jobbra"?)- VIA: "Pl. duplapontos szorzással 3 órajel alatt végez, viszont csak 2 órajelenként indítható. Az osztás viszont az első órajeltől kezdve átlapolt! Ilyet sem az AMD sem az Intel nem tud..." Pedig pont neki nem kellene tudnia ilyeneket, ismerve azt, hogy hova szánja...
Ígéretesen hangzik, de ezzel én megvárnám pl. a részletes latency/throughtput értékeket tartalmazó dokumentációt.[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
válasz
#95904256
#4936
üzenetére
Ennek kivédése azért még nem radikális áttervezés: a jelenlegi AMD-microarchitecture-ban is elfér egy macroop-okat tartalmazó loop stream detector
Rive #4932: Az Anandtech ennyire slampos lenne? Úgy érzem, többet sejtet ebben a jövőre nézve.
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
Szépen hangzik, csak a megvalósítása nehéz (jelen pillanatban még), főképp az hiányzik belőle, hogy egyetlen szál mennyit profitálna ebből. Amit Hans felvázolt abban, amit #4924-ben linkeltem, pont ezt csinálná: a klasszikus decode- és környezetduplázás helyett az execution unit-okat többszörözi; viszont ezek között igen komoly kommunkációs megoldások kellenének, hogy felvegyék a versenyt a jelenlegi VE-k közti bypass network-ökkel, storeforward-dal, memóriaművelet-átrendezésekkel, stb.
Ez akkor lenne igazán ütős (és megvalósítható), ha pl. nem lehetne látni a Nehalem-ben azt a sok statically partitioned egységet.
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
Van egy dolog, ami mellett nem tudok szó nélkül elmenni (megint
): az Itanium. A sok éves tervezés alatt gyakorlatilag »mindent« megoldottak program/fordító/utasítás szinten, amit az x86 vonalon rengeteg tranzisztorral spekulálnak.
Ha ránézek a Penryn-re, gyakorlatilag mindent megoldottak szilíciumon, amit az Itanium már a fordítóprogramok szintjén megkövetel az utasításkészlete és in-order felépítése miatt; SZVSZ innen nincs tovább.
- utasítás-átrendezés és függőségkezelés vs templates & (változó méretű) instuction groups
- memóriaművelet-átrendezés vs data és control speculation utasítások
- stack engine vs stacked register files + register stack engine
- Loop Stream Detection vs register rotation
- szinte minden utasítás valamely condition register-en alapuló feltételes végrehajtása vs conditional move(?)Illetve van tovább: a x86 fordítóknak fel kell nőniük ilyen szintre; és akkor rendesen működni fog az in-order Atom és a Larabee is. Az Itaniumnak ehhez nem kellett több, mint 32 általános integer (+ kommunikációs terület), 32 FPU és 32 condition (~flags) közvetlenül elérhető register (plusz az application register-ek).
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
Az Intel Core optimalizálási gyorstalpalójának mintájára az AMD is kiadta a K10 software-fejlesztési irányelveket, videováltozatban: [link]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
válasz
Oliverda
#5155
üzenetére
Kérsz szakmai önéletrajzot?
![;]](//cdn.rios.hu/dl/s/v1.gif)
A cache-tévesztések száma a méret, asszociativitás és line-size függvényében ([link]):
Ugyanez grafikusan, 32-byte line-size mellett:
A forrásból (18-20. oldal) kiderül, hogy ezek szimulált cache-eken tesztelt adatok, 5.6 MB adatot használó programmal, sebesség itt nem releváns. Viszont úgy gondolom, ha 45 nm-en nem tudják legalább 1x200 MHz-cel megnövelni az NB-órajelét, akkor nem az L3-latency lesz a legnagyobb gondjuk.
Itt lehet a kérdés nyitja:
In general, increasing the associativity of a cache above 8 seems to have little effects for a single-threaded workload. With the introduction of hyper-threaded processors where the first level cache is shared and multi-core processors which use a shared L2 cache the situation changes. Now you basically have two programs hitting on the same cache which causes the associativity in practice to be halved (or quartered for quad-core processors). So it can be expected that, with increasing numbers of cores, the associativity of the shared caches should grow. Once this is not possible anymore (16-way set associativity is already hard) processor designers have to start using shared L3 caches and beyond, while L2 caches are potentially shared by a subset of the cores.
(Mint azóta kiderült, nem lesz közös L2-megoldás a közeljövőben. Egy kisebb összeget felteszek arra is, hogy a VIA a kétmagos Isaiah-t FSB-n keresztül - PentiumD-hez hasonlóan - fogja megvalósítani, itt kiegyensúlyozott teljesítményt fog nyújtani a 16-way exclusive L1 és L2.)Az kérdéses, hogy kényszerű döntés volt-e a 6MB/48-way, vagyis jobb lenne-e a 8MB/32-way (ha elfért volna). Hajlok arra, hogy a (nagyrészt) exclusive cache-felépítés miatt nem kényszerű döntés; Nehalem-nél 16-utas lesz az L3, viszont teljesen más (MESIF) protocol-t használ (valamint "Nehalem’s 8MB and 16 way associative L3 cache is inclusive of all lower levels of the cache hierarchy and shared between all four cores.")
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
válasz
Oliverda
#5656
üzenetére
Ezen mikroarchitekturális optimalizációkról sehol sem esett szó részletesebben eddig, pedig ezekkel dicsekedni szoktak a gyártók.
Attól félek, mintkettő igaz: die shot-on nincs lényeges változás (magban legalábbis), viszont a beharangozott funkciók egy része most, 45 nm-en fog (teljes egészében) életbe lépni, ahogy a DDR3-támogatás is a több, mint egy éves BKDG-k ellenére.
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
válasz
Oliverda
#5667
üzenetére
Nézd meg ezt a tesztet és a konklúzióját: [link]
Remélhetőleg első része egy mély analízissorozatnak, ez most Core2-n és K8-on négy játék alatt.
A K10-es újítások elméletileg pontosan azokon a területeken történtek a K8-hoz képest, ahol az lemaradt ebben (L2 a Nehalem-mel más kérdés lett), mégsem látszottak a Barcelonán annyira. A legrosszabb az, hogy míg "The Core 2's IPC is about 5-10% higher than the K8 for our set of games", a K10 sem igazán tudja ezt a helyzetet megváltoztatni, pedig jó alapokról indul:
- The K8 has 20% fewer uops per instruction than the Core 2 for our set of games.
- The K8's L1D cache is more effective, with about 20% fewer misses per instruction retired for our set of games.Ebből nekem először is az szűrődik le, hogy a memória-alrendszerrel gondok vannak a Barcelonában, amelyet a Shanghai orvosol(hat, pl. a memvezérlő prefetch-e eddig be sem volt kapcsolva?).
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
Ugyan a következő számokból nem lehet közvetlenül érdemleges következtetést levonni, de egy tendencia kirajzolódhat: négy CPU-család hibalistájából ez derül ki:
- a Merom dokumentációja már lezárt, a hibák vagy Fixed vagy No Fix állapotban vannak, a 128 hibából 84-re nincs javítás, ez 65%
- a Penryn-ek 74 ismert hibájából 62-re nem terveznek javítást, ez 83%
- a Barcelona 3 stepping-jének eddigi 42 nyilvános hibájából 10-re egyáltalán nem volt javítás ütemezve, további 23 hiba érinti mindhárom verziót, azaz a hibák 78%-a nincs javítva. (Shanghai Revision Guide még nincs.)A Nehalem-ek 77 közzétett első revíziós hibáinak csak 57%-át nem tervezik javítani, 33 hiba mellett szerepel Plan Fix. Ennek egyik oka lehet, hogy kiemelkedően sok, összesen 12 hibának van köze az újradefiniált C6 power state-hez.
dezz #5868: az említett dologról csak ezt találtam: [link] "Even Intel's weird 6 core chip is no match to Shanghai. As for Intel's copycat chip Nahelem, it won't be available until later 2009, as Intel is still struggling with some cache coherence issues in 2P configurations."
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
Valószínűleg ugyanarra gondolunk: a javított/javítandó hibák száma jelezheti, hogy a gyártó mennyit tekint valóban komoly hibának; pl. a performance counter-ekkel kapcsolatos hibákat szinte sosem javítják ([link])
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
Igazából eddig az sem volt szokásos, hogy mondjuk két, önálló L1D-vel rendelkező képződményt egy egységnek kezeljünk, valószínűleg erőteljes újradefiniálásra szorul az eddigi bevált 'core' fogalom (decode, retirement - pl. FPU-kivételkezelés -, task-váltás, performance counters terén) és még nem derült ki, hogy ez a kifejezés mit és milyen teljesítményt jelent (pluszban a HT-hez képest) a fenti 'marketing süketelésekben' ("The Bulldozer module is a concept and part of an architectural design, it is not something that the user will come in contact with.")
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
-
P.H.
senior tag
Amikor az OS két szálat ütemez a magra, azokat párhuzamosan próbálja futtatni az Intel összes HT implementációja.
Netburst HT: "Both logical processors compete for the Trace cache access each clock. If their requests come in simultaneously, the Trace cache access is granted in turns to each of them every other clock. In other words, the first one accesses the Trace cache on the first clock, the second – on the second, then the first one access Trace cache again on the third clock, etc. If one of the threads is stalled (of there are no decoded micro-operations in the Trace cache for this thread), then the second thread has the Trace cache at its full disposal." ([link])
Core I7 HT: "The instruction fetcher and decoders are shared evenly between the two threads so that each thread gets every second clock cycle." [...] "There is no way to give one thread higher priority than the other in the CPU." ([link])
Az Atomban két decoder van: "The two instruction decoders are identical." [...] "It is impossible to assign different priorities to two threads running in the same core. Thus, a low priority thread may take resources from a high priority thread running in the same core, with the unfortunate result that the high priority thread runs at only half the maximum possible speed." ([link])
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
SZVSZ ugyanaz a kategória, mint a HT.
Az viszont megbonyolíthatja a dolgokat, ha az AMD nem dob piacra majd letiltott CMT-s (azaz 1 integer core-szál/modul) darabokat.
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
Nincs könnyű helyzetben az AMD. Asztali piacon meg kell honosítania a modul fogalmat, mint értékmérőt, amit leginkább a két maghoz lehet kötni. A szerverpiacon meg ennek az ellenkezőjét kell állítania.
Mennyivel egyszerűbbek lennének az ilyen kérdések, ha a Rock is megjelent volna...[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
"AMD Family 15 processors introduce a new feature where, in some cases, a comparison or test
instruction and its associated branch instruction can be "fused" into a single micro-operation."A Sandy Bridge az ADD / SUB + Jcc utasításokat is tudja egyesíteni, bizonyos megkötésekkel ("The first instruction can have an immediate operand or a memory source operand, but not both"), nem csak a CMP / TEST + Jcc eseteket. Vajon Bulldozer-nél is lesznek korlátok?
Uop-cache úgy tűnik, nem lesz a Bulldozerben.
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
Úgy tűnik, a legtöbb integer-utasítás végrehajtási ideje marad 1 órajel, az L1-latency viszont nő, 3-ról 4 órajelre.
Új integer utasítások: T1MSCK, TZCNT, TZMSK, LSWPCB, LWPVAL.Move elimination, azaz FP-oldalon a 0 órajelű (register-file által lekezelt) register-to-register copy megvan, nem szükséges hozzá execution unit.
B.5 Amended Latency for Selected FMA Instructions
The following table shows amended latency time for selected FMA instructions, where special cases are applied in which additional latency is accumulated.
Ez a rész nem tiszta.Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
Sok helyen homályos vagy ellentmondásos, úgy tűnik, direkt, pl.:
- többször hivatkozik a 32. oldalon látható processzor-ábrára, amin igazából jelenleg semmi sem látszik
- az új integer utasítások típusa mindig FastPath Double, latency-értéke mindig NA
- There are four integer execution units per core. Two units which handle all arithmetic, logical and shift operations (EX). And two which handle address generation and simple ALU operations (AGLU). Ehhez képest az utasítástáblázatban csak a call és a lea mellett említik az AGLU-t mint végrehajtó egységet.
- "In addition, a particular integer pipe can execute two micro-ops from different macro-ops (one in the ALU and one in the AGLU) at the same time." Akkor 2 vagy 4 független execution unit van
A fentiek miatt fentartásokkal kezelve bármilyen kijelentést, a következő mondat azt jelezheti, hogy a 256 bites AVX-utasítások két 128 bites felének hatékony egyszerre indulnia/futnia, de nem kötelező: "Only 1 256-bit operation can issue per cycle, however an extra cycle can be incurred as in the case of a FastPath Double if both micro ops cannot issue together."
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
Úgy tűnik, sok(kal több) érdemi információt nem lehet levonni belőle.
Az az ábra egy sima PR-slide ábra, nem Opt. Manualba való.
Én erősnek találtam elsőre leírni, hogy jó része (főleg a microarch utáni tételes optimalizálási leírások) sima másolás a K10-es verzióból, de most nézem, úgy tűnik, más nem:
"The SOG has looked that way for the last year. The original version that I got had even more mistakes."
"They clearly did a copy/paste from a previous version, but didn't get around to making all the necessary changes."Pl. ilyenek is benne maradtak, hogy:
"The processor is capable of performing three independent 64-bit additions each clock cycle and a 64-bit multiplication every other clock cycle."
"On each cycle, the in-order front-end engine selects up to three AMD x86-64 instructions to decode from the pick window."Továbbá a latency-táblázat sem akkurátus, több rossz vagy hiányzó érték mellett sehol nem szerepel benne, hogy az AGLU-k milyen integer-utasításokat tudnak/tudnának futtatni, amelyekkel kijönne a 4 integer op/cycle/thread ütem, ha a modul csak 1 szálat futtat, így a végrehajtás szinte semmilyen csorbát nem szenvedne a K10-het képest (tippem szerint azokat, amelyeket a Netburst double-pumped ALU-i is tudtak: MOV, ADD, SUB, CMP, AND, OR, XOR, NOT, NEG, TEST; esetleg kiegésztítve shift(1?)-tel, BT reg/mem,imm-mel és az új utasítások közül párral, de ugye sem derül ki konkrétan... az sem, hogy egyáltalán tudnak-e)
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
Mondom: "Sok helyen homályos vagy ellentmondásos, úgy tűnik, direkt"
Macro-opra gondolok, nyilván bizonyos megkötések mellett (pl. 2 csak reg,reg utasítás mellett 2 reg,mem - load+op - utasítás lehet, vagy csak 1 mem,reg - load+op+store-, vagy ki tudja).
Az IPC-t retirement-en szokás mérni, ez 4 macro-op lesz globálisan. 2 thread esetén 2.0 lesz a maximum (órajelenként váltva 4 utasítás más-más szálakról, azaz egy szálra vetítve 2.0 IPC), de kérdés, hogy 1 szál esetén lehetséges-e a 4.0 IPC maximum.
Illetve az, hogy az Intel-vonalon Core2 óta meglevő 3 (megosztott, egyszerű) ALU helyett 4/thread (2 komplex + 2 egyszerű) ALU lesz-e.[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
Nem a zavarás a kérdés, hanem az önállóan, egy szálon mutatott teljesítmény. (shared) FPU esetén ezt Te is annyira egyértelműnek látod, nem értem, miért nem kérdéses neked, hogy int-oldalon, 1 core esetén mi (felezett vagy akár teljes teljesítmény?) lesz.
Mert hogyne lehetne kihasználni a 3.0 vagy 4.0 IPC-t, pl. a blogomban nem egy 2.0 IPC feletti (csak integer), és általában 1.0 feletti (akár integer téren Brazos-on vagy pedig más AMD platformon floating-point-os) kódot írok le, és ezek nem benchmark kódok, ezek így mennek ki éles felhasználásra.
Intel-eken ugye nem megy a PerfMonitor, nem tudom egyszerűen mutatni a teljesítményt, de nagyjából visszaszámolható a mutatott teljesítmény alapján (pl. amit linkeltem, az is azonos IPC-n megy egy Core2 Celeronon, 1.35 IPC-n P3-mon és 0.65 IPC-n Prescott-on).Ha én tudok csinálni ilyen kódokat, akkor az OS-ek és fordítók library-készítői biztosan tudnak. Ehhez persze kellenek a (pontos) Opt. Manualok is, és az azokból levonható következtetések..
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
válasz
Oliverda
#7655
üzenetére
"The integer scheduler can dispatch up to 4 micro-ops per cycle, one to each of the 4 pipelines. Almost all ALU operations are handled by the 2 EX pipelines, except some LEA instructions which also utilize AGU. Thus the integer core can execute only up to 2 x86 instructions per clock cycle, resulting in a maximum integer IPC of 2.0 (in units of x86 instructions). Note however this estimate does not include the computing throughput of the integer SIMD pipelines in the FPU."
vs
RWT nyitó hsz: "4 Integer ALU instructions/cycle for each core."Az, hogy ennyire eltérő következtetéseket lehet levonni ugyanabból a dokumentumból, nem lehet véletlen, inkább az író direkt szándéka; ezt anélkül mondom, hogy mit szeretnék jobban belelátni vagy igaznak vélni.
A PerfMonitort megpróbálom megint Intel-eken, korábbi próbálkozásaimkor el sem indult.
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
válasz
Oliverda
#7680
üzenetére
Hát igen, ez a baj az AMD-féle L3-mal, a 65 nm-rel nagyjából azonos feszültség kell 32 nm-en is meghajtani őket. ([link])
A két AGU (AGLU?) viszont nagyjából ugyanolyan méretű, mint a két ALU. Ez jó előjel a 4 egyszerű ALU-op/cycle/thread várakozáshoz.
Igen kicsi integer végrehajtókat sikerült összehozniuk, ha a többi részegység jelölése (Immediate value storage, Register rename, ...) helyes
Bár a 2 azonos méretű, külön integer register file jelölése eléggé furcsa (első blikkre Netburst-szaga van, ahol a 32 bites műveletek két külön órajelen 16+16 bites műveletekként hajtódtak végre; nyilván itt legalábbis 32+32 bites műveletekről lehet szó).Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
)
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
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.
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Napelem
- Computex 2024: ASRock minden mennyiségben
- A Biden-kormányt is zavarja a big tech és az adatközpontok energiaéhsége
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- 3D nyomtatás
- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
- E-roller topik
- Ubiquiti hálózati eszközök
- Politika
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs