- Fotók, videók mobillal
- Xiaomi 15 - kicsi telefon nagy energiával
- Android alkalmazások - szoftver kibeszélő topik
- Magisk
- Okosóra és okoskiegészítő topik
- Sony Xperia 1 V - kizárólag igényeseknek
- Samsung Galaxy S25 - végre van kicsi!
- Google Pixel 8a - kis telefon kis késéssel
- Milyen okostelefont vegyek?
- Redmi Note 10S - egy a sok közül
-
Mobilarena
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Nem erre gondoltam. A gyártástechnológia továbbra is lényeges még ha a generációváltás egyre kisebb előnyt jelent és ehhez képest egyre költségesebb. Ami az én szememet csípi, hogy a nanométer elé odaírunk egy számot, de az valójában nem jelent semmit. Csak azért nem kódnév alapján utalunk a gyártástechnológiára, mert marketingeszköz az egész és a vásárlók nem értenek meg a több oldalas leírást, amivel pontosan jellemezhető az adott gyártástechnológia.
Ha pontosan akarjuk ezt elemezni, akkor még az egyes lapkákhoz is szükséges lenne egy teljes leírás a fizikai dizájnról, és az alkalmazott dens library-ről. Ezek nélkül az a szám a nanométer előtt nem jelent semmit.
-
Na pont erre gondoltam, hogy ha a gyártástechnológia fejlesztése egyre kevésbé éri meg, akkor a microarchitektúra megtervezésére kell jobban odafigyelni. Viszont mikor már ez utóbbinak fejlesztése is korlátokba ütközik a teljesítménynél (lásd haswell, ahol minimális volt a növekedés), új architektúrára van szükség. Ez utóbbinál viszont korlátozó az eltérő ISA, így az Intel az AVX kiterjesztéssel próbálkozik (ahogy eddig is ment az MMX, SSE), ami úgymond egy köztes út, megtartva a kompatibilitást, míg az AMD radikálisabb megoldásban keresi a jövőt, és GPU-val házasítja a "fix" CPU-t.
-
dezz
nagyúr
Nos, erre gondolok:
És ezekre (koherens memória + egyesített címtér + compute context switch + pre-emption). Ha a scheduling hw-es is lesz, előbb-utóbb kell, hogy legyen valami beleszólása az OS-nek (erőforrások prioritizálása az alkalmazások között, valamiféle visszajelzés a user felé, mi is történik, stb.).
Mindenesetre, itt maguk az applikációk indítgatnak majd compute-szálakat... Célszerűen úgy, hogy 1-1 szoftverszál 1-1 hw-es compute-szálat kezel. Így végtére is az OS kezeli ezeket a sw+hw compute-szálakat. (Bár nem kötelező ez a felállás.)
(Egyébként nem árt majd tudni, hogy egyszerre mennyit is érdemes.)
FPU: szerintem 1db GCN CU is potensebb, mint a meglévő FPU: 256-way vs. 512-way + külön scalar egység. Persze más utasítás-kódokat használ, de nyilván módosításra kerülne.
(#11375) lee56: Az igazán teljesítményigényes szoftvereket folyamatosan frissítik (kevés kivétellel)... A sok CPU mag támogatása régóta alap pl. a 3D renderereknél. Már a GPGPU-sítás is beindult.
APU vs. 8-magos CPU: lehet választani, attól függően, hogy az adott program, amit mindenképpen használni akarunk (melóra), mit támogat.
-
dezz
nagyúr
Nos a 11. oldalon egy meglehetősen elnyújtott görbét láthatunk, főleg frekiben felfelé. A 3,3 GHz-nél lévő csúcshoz képest, 4 GHz-en még csak minimális csökkenést szenved el a hatékonyság.
Amúgy az még mindig nem derült ki, hogy ez az összfogyasztás mekkora részét teszi ki.
-
Abu85
HÁZIGAZDA
Nem tudom mekkora. Egyelőre az van, amit a média leírt az IDF-ről, aszerint ez egy dedikált cache, és nem az LLC része. Aztán lehet, hogy az Intel előadásán hangzott el ez rosszul. Az Intel nem fogalmaz pontosan a diákon sem, szóval itt tartunk.
Meg kell várni a részletesebb logikai rajzot a felmerült kérdések megválaszolására. Esetleg ha lesz nem photoshoppolt die kép, akkor abból sok dolog kiderülhet. Ami van az bevallottan át van formálva, hogy ne lehessen belőle "olvasni".
Nekem egyelőre ez van:
-
Abu85
HÁZIGAZDA
Az Intel LLC-nek hívja hivatalosan a nagy közös cache-t. Erre megy a CPU-magokban az L2 és fölött ez L1. Az IGP-nél L3 ami a ROP mellett van, L2 papíron nem létezik, de lényegében a texture cache, míg az L1 az LDS, de ezt az Intel Shared Local Memory-nak hívja, persze Local Dara Share-ról van szó.
Úgy tudom, hogy az IGP-n belüli L3 késleltetése meglehetősen magas, de ez egy GPU-ban nyilván nem számít. Úgyis elfedik ezt a shaderek.
Semmi gond ezzel az Ivy-ben, nem lépnek vissza. Az IGP az L3 cache-en keresztül van összeköttetésben az LLC-vel. Tulajdonképpen az történt, hogy az SB IGP-jében a ROP mellett nem volt gyorsítótár, így a legközelebbi az LLC volt. Most elvileg kapott egy dedikált L3-at, amibe a shaderek is írhatnak, de az LLC-t továbbra is képes úgy kezelni az Ivy, ahogy a Sandy. Carmack-nek nem kell aggódnia ebből a szempontból.
Az egész szimpla kényszer, de ettől csak jobb lesz a rendszer. Ha letiltottad az LLC írási jogát az IGP-nek, akkor az nem tett jót az SB teljesítményének. Nem omlott össze, de érezhetően visszaesett a sebesség. Most ez nem lesz annyira érezhető, esetenként semmit sem fog számítani. -
dezz
nagyúr
Azzal a 80%-os szabállyal kapcsolatban. Igen, a front-end nem erősebb, csakhogy más eset egy 2-way front-end 2-way végrehajtással (pl. Bobcat), mint a BD esete, azaz 4-way, komoly front-end 2x2-way végrehajtással...
Amúgy érdekes lenne K10.5 (leginkább Athlon II) vs. Bobcat összehasonlítást végezni a tekintetben, hogy különféle programok milyen IPC-vel futnak.
Gondolom, erre gondolsz. Nos, azt eddig észre sem vettem.
Szerintem érdemes lenne áttenni a Logoutra. (A főbb dolgokat napi blogbejegyzésként, a többit azokhoz kommentként, ilyesmi.)Mindenesetre, ha nem csak a saját kódjaidat nézegeted, láthatod, amiről szó volt.
Nem mondtam én semmi rosszat a HT-ről (félretéve most az ismert korlátait), csak azt, hogy ott tud hatékonyan működni, ahol nem túl jó a kihasználtság, azaz nem "túlzottan" optimális a kód. Ebben ugye nincs semmi meglepő.
"Az IPC szigorúan véve az órajelenként végrehajtott, befejezett utasítások száma, ami egyszerű esetben vagy 0 vagy a felépítés szélessége."
"the average number of instructions executed for each clock cycle.", "The number of instructions executed per clock is not a constant for a given processor; it depends on how the particular software being run interacts with the processor" [link]Ezen kívül beszélhetünk még a peak IPC-ről egy adott proci esetén.
"Nem szigorúan véve pedig az órajelenként befejezett utasítások számának átlaga egy időszakban (pl. 50 ms)"
Látod, tudod te.
Csak a "nem szigorúan" nem stimmel.Na szóval, nem úgy értettem, hogy pl. nagyon kevés kódban van ilyen egyátalán, vagy hogy a proci naponta csak párszor találkozik vele. De nem is minden 2. vagy 3. ciklusban, miközben a többiben nem csinál semmit, és így jönne ki mondjuk egy 1.0-ás átlag. Szerintem átlagos kódnál keveset számít bele az átlagba, így a 2-way végrehajtás révén nem fog sokat zuhanni a BD átlag IPC-je.
-
dezz
nagyúr
Nem tudom, ez miért lenne így... Talán gyenge frontendű procikra igaz.
(#9803): Természetesen reordering után értettem, és nem szám szerűen, hanem átlagban.
Tesztelj csak le pár programot (egyszálasan futtatva, ha lehet) a PerfMonitorral... Pl. CineBenchek 0,8-as átlaggal futnak. Nem számolós programok 1,0. És ez nem mp-es átlag, hanem 1/50 mp.
Az Intel mostanában nagyon nem erőlteti a "túlzott" optimalizációt, mert az HT-val nem hogy gyorsabban, hanem lassabban fut, ami nem olyan jó színben tünteti fel az i7-eseket az olcsóbb i5-ösökkel szemben, és úgy általában a HyperThreadinget.
Hakuoro: Lehet, hogy amúgy jobb lesz, csak FP-ben nem annyira. (Legalábbis újrafordítás nélkül.)
-
Oliverda
titán
Gyártástechnológiai sajátosság.
Még a memória intenzívebb cuccoknál is keveset hoz AMD-nél az 50%-kal magasabb órajelű L3, ezért szerintem nem is erőltetik az órajelének egekbe emelését. Nyilván annak is vannak előnyei (egyszerűbben gyártható, alacsonyabb fogyasztás), hogy elég egy olyan L3, aminek nem kell túl magas órajeleket tudnia.
-
Oliverda
titán
Bár még általános iskolában lehetett, de azóta sem változott meg a képlet:
TRitON: A fenti képlet neked is szól. A többit passzolom, de a TDP biztosan nem változik. 125 és 95 wattosak lesznek ezek a processzorok is.
hibavissza: 18ért már van 4 gigás 2000MHz-es kit, 28-ért pedig már 8 gigás 1866os.
-
dezz
nagyúr
Dehogy nem, kérdéses. Főleg, hogy korábban azt írták egy hivatalos blogbejegyzésben, hogy egyszálas végrehajtásban is jobb lesz, mint a K10. Ez még lehetne az órajel jelentős emelkedése által, de állítólag IPC-ben is jobb lesz... Csak hát így nem tudom, hogyan.
Tudnak, ha akarnak, de manapság nem nagyon foglalkoznak vele. Amit a C fordító kinyom...
-
dezz
nagyúr
Erre írtam, hogy a manual szerint 1-1 INT mag max. 4 micro-op-ot fogad, így a 4.0 IPC csak egyszerűbb, 1 micro-op-os utasítások sorából jöhet ki, a többinél 1 szál esetén is max. 2.0 lesz a IPC.
Valószínűleg nem úgy oldották meg, hogy modulonként 2 szál számottevően, az inteles HT-nál jobban zavarja egymást... (Már ami az INT kódol illeti, mert ugye a 256-bites SIMD kódok esetén ez szükségszerűen bekövetkezik.)
Amúgy van olyan hétköznapi kód, ahol a futási idő jelentős részében megközelítődik a 3.0-ás, ill. az SB-nél 4.0-ás IPC? Korábban nézegettem programokat ilyen real-time teljesítményváltozókijelző monitorral, de alig-alig ment 1.0 fölé. (Bár ez egy átlag, nem tudom, mi a két szélső érték.)
-
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 vanA 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."
-
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. -
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.
-
Oliverda
titán
Az úgy nem lesz jó mert akkor a nem túl tájékozott júzer tuti a 8 core + 8 thread CPU-t fogja megvenni. Tehát szerintem a "thread" megjelölés marketing szempontból nem lenne túl szerencsés. Vagy ha véletlenül mindkét gyártó áttérne erre a formára akkor megint 16 thread vs. 8 thread lenne a felállás. Így szerintem marad a "core". Nem rosszabb mint a 3200+ ami valójában csak 2000MHz-en üzemelt.
-
Oliverda
titán
Na de ki tudja hogy az a die shot hanyadik rev.? Valószínűleg C0 és C2 lesz az ami piacra kerül majd végül AM2+ és Socket F foglalattal. Az AM3 lehet hogy már egy újabb stepping lesz.
32-ről 48 utasra növelték az L3 asszociativitását, ez már egy változás a K10-hez képest. Nem tudom hogy ennek például mennyire kellene látszódjon egy die shot-on.
Bluegene: 140W-ig mehetnek el max. a fogyasztással. Ez az első C2 steppinggel szvsz max. olyan 3.2GHz-ig lehet még jó. Persze később jönnek majd újabb steppingek is és arról is szó volt hogy idővel bevezetik a High-k/metal Gates techonlógiát is.
-
-
#95904256
törölt tag
- 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.
Itt nem csak a találati arányra gondoltam. Pl. ha az AMD processzor (K7-K8-K10) belefut egy ugró utasításba az minimum +1 órajel végrehajtási időt jelent, ha ténylegesen ugrani is kell akkor még több is lehet. A Core2-nél ez legtöbbször 0(!) órajel ( Jcc near ).
- 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.
Itt sem csak pusztán sorba/átrendezésre gondoltam, hanem pl. a ICU bővítésére. Abban meg nem vagyok biztos hogy a külön-külön ütemező "gyorsabb" feldolgozást jelent. Szerintem Inkább csak tranzisztor spórolás. Pl. a címzésből adódó függőségek ( ADD ESI,ECX + FADD Q[ESI] ) így is lekezelendőek. A kétszer nagyobb, de közös puffer a több tranzisztorért cserébe integer illetve float-point intenzív kódnál hatékonyabb lehet. Már pedig az a ritkább eset hogy egyszerre mindkét reorder unit töltve van...
- 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.
Az csúcsteljesítményű processzoroknál természetesen a sebesség a lényeg. Egyébként a VIA Isaiah leírását olvasgatva van egy-két érdekes dolog a lebegőpontos részben. 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...
szerk.: A VIA Isaiah-ra már nagyon kíváncsi vagyok. Érdekelne hogy mennyi részt kell majd a doksiból másképp értelmezni.
-
#95904256
törölt tag
A Kentsfield-nél ( 4MB / 16 utas ) 14 órajel a késleltetés.
A Penryn-nél ( 6MB / 24 utas ) 15 órajel.Ebből akár az is kisülhet hogy azonos órajelen egy E1xxx Celeron a 11(?) órajeles késleltetésével 35%-kal gyorsabban is futtathat bizonyos alkalmazásokat mint a Penryn.
Persze ritka az efféle alkalmazás ( pl. különböző feladvány megoldó programok ( sakk, sudoku, maze solverek ) ), inkább a cache mérete a domináns.
-
-
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.
-
fLeSs
nagyúr
Sztem a felvevőpiacnak most két baja lehet, az egyik, hogy hibás a proci, és várják az új steppinget. A másik az, hogy még új a proci, és ezért aránytalan áron adják az Intel Quadhoz képest. Az elsőre nem számíthatott az AMD sem, a második viszont csak rajtuk múlik.
#3906 szerkre: adtak ki BIOS-patchet, amivel elég komolyan csökken a teljesítmény, így a proci ár/teljesítmény hányadosa tovább romlik...
izé, ezt az MS javítást még nem is láttam, ergo fel sem raktam a gépemre...
-
fLeSs
nagyúr
"#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.)"
Nyilván arra apelláltak, hogy a hibás K10-eket fogják eladni letiltott magokkal.
De ehhez az kell, hogy termeljék a négymagosokat, ami még csak most kezdődött el, szóval nincs miből kétmagost csinálni, majd 1-2 Q múlva.
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. A kétmagos K10 tervezésének (ha volt is) a négymagos tervezésével együtt kellett haladnia, tehát csakis a négymagos után készülhettek el a terveivel. Tehát ha van kétmagos K10, akkor annak a gyártása a négymagos után kezdődhetett volna meg, elvégre a K10 lényege a natív négy mag, amivel nem késhettek tovább, prioritást élvezett mindenek felett. Szóval ha van natív kétmagos K10, akkor annak a közeljövőben kell bemutatkoznia, mintha láttam volna már olyan roadmapet, amin szerepelt ilyen, persze az lehetett négymagos K10 is rossz magokkal és letiltott L3-mal. -
Raymond
titán
Azt hiszem azert mert nem szamitottak a felbukkano problemakra. Egy uj chip most eleg sok penzbe/idobe/forrasokba kerulne. De azert tenyleg csinalhattak volna egy ketmagos verzion L3 nelkul es 1MB/mag cache-el
Olyan drasztikus layout valtoztatasokat nem hozna magaval. Nem meregettem Photoshop-al, de durva becsles szerint az NB elferne komolyabb (mint a K8 Brisbane-nel) valtozasok nekul ha a 4 HT linkbol harmat kivesznek. Persze ez nem segit azon hogy meg mindig penzbe es idobe kerul a maszkok legyartasa, a tape-ot es a teszteles.
-
fLeSs
nagyúr
Az AMD elkúrta, nem kicsit, nagyon.
Szóval, a K10 mint tudjuk egy önnálló fejlesztés, és ahogy tudjuk, nem futott mellette semmilyen második fejlesztés, aminek mostanában már látszatja lehetne.
Amit akarok mondani az az, hogy most csak két architektúrájuk van, a K8 és a K10, ezekkel kell variálniuk.
Szerintem ezt te is tudod, de azért leírom, hogy egy új, K10 alapú, de natívan csak kétmagos procinak a piacra dobása nem úgy müxik, hogy hopp, most akkor félbevágjuk a K10-et, aztán ott a kétmagos proci, gyártsuk ezerrel. Az egy teljesen új design, az első tranzisztotról az utolsóig újra kell tervezni a tervezőasztalon, aminek a megtervezésére ha el is kezdték vmikor a közelmúltban, kell 1-2-3-4 év, aztán meg kell tervezni hozzá a maszkokat, stb, aztán tape-out, próbagyártás, gyártás beindítása, gyártás felfuttatása és ekkor léphetnek vele piacra. Nyilván a tervezés gyorsabban halad, ha az alapjául szolgáló architektúrát már egyszer megtervezték és ismerik, de a maradék lépések még így is sokáig tartanak ahhoz, hogy hipp-hopp megjelenjenek egy ilyen procival.
Erről ennyit.
A gyártástechnológiai váltások sem úgy működnek, hogy egy meglévő pl. 90 nm-en gyártott architektúrát lekicsinyítenek 65 nm-re. mindent újra kell tervezni, ezért az alacsonyabb csíkszélességű termék fejlesztésének bőven együtt kell haladnia az első verzióval.
Gondolom hallottál róla, hogy az Intel Penrynes csapata USA és Izrael (Core fejlesztése) között állandóan ide-oda ingázott, pont emiatt.4 GHz: ez sem így müxik, de sztem te tudod ezeket, ne írj sületlenségeket.
esetleg ha az új "elméleti" kétmagos K10 futószalagját meghisszabbítanák, akkor fel lehetne tornázni 4 GHz-re, de a futószalag meghosszabbítása miatt már komplett újratervezésre van szükség (nagyobb regiszterkészlet, pontosabb elágazásbecslés, hatékonyabb RS és ROB), -
#95904256
törölt tag
Szerintem is rég piacon kellene lenniük egy működőképes, 128 bites (SSE), kétmagos megoldással. Ha jól sejtem ez az a terület ami miatt a leginkább lemaradtak az Inteltől.
Mikor ezt hónapokkal ezelőtt feszegettem, olyasmi kép állt össze hogy amennyi energiát csak lehet, a natív négymagos megoldásba ölnek. Gondolom a kétmagos verziót még nehezebb összehozniuk mint pl. a B3 steppinget. De csak idő kérdése és meglesz...
-
Raymond
titán
-
Raymond
titán
Ugy latszik megis egy mas problemarol van szo mint a 254-ben:
Erratum degrades Phenom 9500, 9600 performance
AMD spokesman Phil Hughes told us the TLB issue has been designated errata number 298. When questioned about when AMD would update its technical documentation to include the erratum, Saucier said the person responsible for the updates is "on vacation," although he expects an update "by the end of the year."
Van ott a cikkben meg par erdekes info. Peldaul ez:
"We don't yet have a BIOS with the workaround to test, but we've already discovered that our Phenom review overstates the performance of the 2.3GHz Phenom. We tested at a 2.3GHz core clock with a 2.0GHz north bridge clock, because AMD told us those speeds were representative of the Phenom 9600. Our production samples of the Phenom 9500 and 9600, however, have north bridge clocks of 1.8GHz. Because the L3 cache runs at the speed of the north bridge, this clock plays a noteworthy role in overall Phenom performance. We've already confirmed lower scores in some benchmarks."
-
Raymond
titán
Lehet valami ujabb is (a doksi septemberi), de nem valoszinu. Ezert kicsit nevetseges kicsit az a szinjatek amit ezzel a TLB hibaval is eljatszottak. Hogy teljesen varatlanul erte oket es epp a Phenom launch elott egy nappal derult ra feny. Majd meg jonnek reszletek kesobb amikor mar ugyis mindegy lesz
-
dezz
nagyúr
Az újabb verziós Family 0Fh CPU driverekben van Family 10h támogatás is, ha erre gondolsz.
Raymond: Fura, hogy az összes AMD procit támogató alaplap BIOS-ának UI-ja, és úgy látszik a BIOS-ok leprogramozását segítő doksi is úgy készül, mintha a külső órajel 200 MHz-től eltérő beállítása általi tuning nem létezne. Az UI-val kapcsolatban gondolok itt a 200 MHz-es alapon megadott ram-órajelekre, szorzó/osztó helyett (ami mellé kiírná az aktuális külső clock frekiből számolt órajelet). Csoda, hogy a HT-nél szorzó van megadva, nem órajel szintén.
-
Raymond
titán
Hiaba olvasom nem talalok semmit. Hova tovabb annal jobban arra hajlok hogy tulbonyolitottuk. A BIOS guide szerint az NB minden power plane-t tartalmaz es minden kulon-kulon alligathato. Tehat azert nem talalni semmi bovebb infot a guideban mert nincs mit talalni. A mem frekvencia egyszeruen a F2x[1, 0]94 MemClkFreq beallitassal tortenik, a lehetseges ertekek pedig a 185. oldalon vannak leirva. DDR2 max 1066 (533) Mhz, DDR3 pedig max 1600 (800) Mhz. Mindenhol ahol a MemClkFreq beallitasa vagy valtoztatasa szerepel csak annyi van hogy beallitja es kesz. Vagy az SPD adatok szerint vagy egy custom ertekre. Sehol egy szamolasi formula vagy mas egyeb.
-
Raymond
titán
A registereket es az initializationt vegigkovettem en is, de sajnos a DRAM training-nel leall a dolog. Ott max annyi az informacio hogy 400Mhz a ref amivel dolgozik es a visszajelzesek szerint allitja be a vegso frekvenciat. De tobb reszlet nincs.
A "2.5.1 ACPI Power State Transitions" sajnalatos hianyaig is eljutottam, pedig az volna az igazi
Valami oknal fogva hianyzik.NB orajelek:
Ez eleg erdekes tema. Mostansag felbukkant par tablazat ahol dupla orajelet jelolnek meg az NB-nek. Peldaul a 2Ghz-es Phenomnal azt irjak 3.6Ghz. Az viszont gyanus hogy ez az ertek pont a duplaja a 2Ghz-es Barcelona-ban talalhato 1.8Ghz NB-nek. Inkabb arra hajlok hogy a 3.6Ghz egy marketing szam es a 1.8-as HT link-re hasznaljak "aggregalt" jelzo kenyelmes kihagyasaval de kesobb ha kell bemagyarazhatosagaval. Mondjuk a teszt eredmenyekbol itelve mindegy hogy az 1.8 vagy 3.6 a valos NB orajel -
dokar
addikt
mivel 55W APC = 68W TDP -> ez is nagyon jó egy 4 magos procinak
de miért is sok? az intel 45nm-es négymagosai többet fogyasztanak. arról nem is beszélve, hogy AMD's ACP = Intel's TDP.
továbbá ha a régebbi AMD procikhoz hasonlítod, akkor számolhatsz 68W-al, de ez se sok 4 mag miatt. -
dezz
nagyúr
"(POPCNT lesz Intel-nél is, SSE4.2-ben)."
Az AMD marketingesei nagyon nincsenek a toppon, hogy ezt nem soroltatták az SSE4A-ba...
Úgy mégiscsak 25%-kal több utasítást tartalmazna, másrészt olyasmit, ami Intelnél csak az SSE4.2-ben lesz (Nehalemben?). (#2852) akosf: "Szerencsére az AMD féle SSE5 már tartalmazni fog 5 utasítást az Intel féle SSE4-ből, ami valójában csak kétféle utasítás. ;)"
Tudtommal jóval többet, beleértve az SSSE3-at is:
szerk: hm, .png nem jelenik meg?
cikk(#2854) fLeSs: Valószínűleg ennek, és az SSSE3 át nem vételének - egyéb hiányzó "alkatrészek" hiánya mellett - az az oka, hogy a K10-ben nem 1-1 128 bites FADD/FMUL/FMISC egység van, hanem 2-2 64 bites párosítva. Így fel tudnak dolgozni 2x64 bitet (pl. 1-1 double-prec., vagy 2-2 single-prec. FP adatot) egy időben, de 128 bitet egyben kezelni nem: pl. operandusokat cserélni az alsó és felső 64 bit között, mit amit pl. a shuffle utasítások csinálnak, vagy dot productot képezni, stb.
(#2855) Oliverda: Hát én nem értek egyet azzal a hsz-szel, legalábbis nagy részével. (Talán olvasd el a reagálásomat is.) Pl. Larrabee és TeraScale ide v. oda, CPU vonalon is halad tovább az Intel, és valószínű létrehoz valami hasonlót, mint az SSE5, csak azért se kompatibiliset. Az átvétel meg meg sem fordul a fejükben. Lásd x64 esete...
(Vagy a HT, miről még szó volt ott.) Csak most az MS sem igazán tudja kikényszeríteni, mert egy OS nem nagyon használja ezt. (Bár talán 1-2 dolgot mégis.)(#2859) Raymond: Mit készít elő az Intel az SSE4-gyel, amikor az nagyrészt integer műveleteket tartalmaz? Minden bizonnyal a Larrabeenek ugyancsak egy teljesen új, több operandusos FP SIMD kiterjeszése lesz.
-
-
#95904256
törölt tag
Való igaz, az AMD féle SSE4a és az SSE4 utasításhalmazok metszete nulla elemet számlál. Szerencsére az AMD féle SSE5 már tartalmazni fog 5 utasítást az Intel féle SSE4-ből, ami valójában csak kétféle utasítás. ;)
[ 66 0F 38 17 .. ] PTEST
[ 66 0F 3A 08/09/0A/0B .. ] ROUNDxxMókás lesz ez így...
szerk.: El is felejtettem megemlíteni hogy míg a POPCNT az Intelnél az SSE4 része, addig az AMD-nél nem része az SSE4a-nak, viszont tartalmazni fogja a K10-es...
-
FireGL
aktív tag
-
robyeger
addikt
Csak találtál valamit
2001-es ábrák 2002-es szövegkörnyezetben, és ki tudja utólag módosítottak-e a szövegen. Furcsállom, hogy annak idején a laborok hogy nem figyeltek fel egy ''több magos architektúrára'', persze a kezdetekkor szerintem szó sem volt ''System Request Interface''(SRI)-ről, de ha az AMD 2004-ben azt állítja, hogy mindig is ott volt, [link] legyen, biztos csak én vagyok ilyen szkeptikus, bocs
Azaz érzésem ezekkel a felületes prezentációkkal sokra nem fogunk jutni, hogy pontosabban megértsük, mi is az a processzor szorzó a K8-ban, miért nem képes az 1magos AM2 proci kiaknázni egy dupla csatornás DDR2-800Mhz ramokat?
MOESI: Valahogy az SG-nél se értették: ''Különösebben mélyreható részleteket egyelőre nem árult el erről az AMD, tehát egyelőre az sem tiszta például, hogy szükség esetén hogyan jut el az adat az egyik mag gyorsítótárából a másikéba.''
Szóval csak 2verzió lehetséges vagy hardveres vagy szoftveres a hiányosság. Ha abból indulunk ki, hogy az SRI-n keresztül össze vannak kötve közvetlenül a gyorsítótárak, akkor kizárásos alapon csak szoftveres bibi lehet.
Másodsorban ha pedig azt vesszük hogy alapórajelen közlekednek az adatok az SRQ és az L2 cache között, akkor nem adódik nagy sebesség különbség, hogy átnyulik-e a másik mag gyorsítótárába vagy lemegy inkább a memóriához. A gyakorlati tapasztalatok nem változnak olyanok, amilyenek , 1x csak megtudjuk a részleteket. -
dezz
nagyúr
Bocs, hogy csak most reagálok.
''A processzorok összes HyperTransport linkje szinkron módban működik, a HyperTransport I/O Link Specification-ban leírt módon (ez feltételezi, hogy aszinkron módot is tudnak, bár nem ismerem az adott specifikációt).''
Nem feltételezi. Ne zavarjon meg a ''mode'', nem ide vonatkozik, hanem általánosságban a lehetséges működési módokra. Az ilyen megfogalmazás azt szokta jelenteni, hogy ez ezt tudja.
''Ezen leírt szinkron mód elengedhetetlen feltétele, hogy az összes link esetén mind az adó, mind a vevő vonalak azonos óraegységeken alapuljanak.''
Szerintem hasznosabb lenne itt egy szó szerinti fordítás, tehát vonalak órajelei, és azonos időalapból létrehozott.
''(Mivel a korábbiak - pl. ''Processors can be configured with link frequencies from up to two link frequency groups.'' - alapján feltételezhetően a koherens és a nemkoherens linkek eltérő frekvencián működhetnek egy CPU-n belül).''
Nem vagyok benne biztos, hogy a fenti mondattal erre utaltak, mivel az teljesen nyilvánvaló, hogy egyforma frekvencián kell működniük - ennél sokkal fontosabb itt, hogy egyforma fázisban is legyenek, amit egy közös alap-órajel tud biztosítani.
''Ha egy link két végén lévő eszközöknél két különböző órajelgenerátor állítja elő a közös frekvenciát, akkor a következő követelményeknek kell eleget tenniük:''
Nem frekvenciát, hanem órajelet! Nem mindegy. Továbbá nincs helye itt a közös szónak, csak közel áll egymáshoz a kettő.
''1. Mindkét órajelgenerátor azonos forráson alapul -> azonos frekvencia feltétel? (Ez itt a sejtésem szerint a fenti bináris értékekre utal, amelyek szabványosak, bármilyen alapból legyenek előállítva. Vagy emellett egyben az egyetlen közös alapórajelre meglétére is utal, mely mindkét eszköznek egyik adott bemeneti jele kell legyen? Utóbbi léte leegyszerűsíti a helyzetet.)''
Itt ugyanaz a helyzet, mint feljebb. Nem szabad az órajel és a frekvencia szavakat szabadon keverni. A frekvencia-beli egyezés nyilvánvalóság, itt az azonos fázis a lényeg, azaz az azonos referencia-órajel. (Tehát az utóbbi eset.)
''2. Spread spectrum (erre mi a helyes magyar kifejezés? Kiszélesített? Vagy nem szigorú határú?)''
Szórt spektrumú. A frekvencia átlaga egyforma, de kis eltéréssel folyamatosan váltakozó. (Így nem egy adott frekvencián ad le nagy energiát elektromágnesesen, hanem szétszórva kicsit.)
''órajelezés már csak akkor engedélyezhető, miután (ha egyáltalán) a két órajelgenerátor esetleges eltérő üteme már összehangolttá válik.''
Nem egészen erről van szó. A szórt spektrumú órajelezés alapfrekvenciától való eltérései szinkronizáltak, vagy hogy kevésbé legyen zavaró a megfogalmazás: egyeztetettek.
'' -> azonos fázis feltétel?''
Természetesen.
(#1495) robyeger: A #1499-esben kiderült az igazság, de azért megkérdezném: szerinted mégis mi a csuda lett volna ott az a CPU0 és CPU1? Honnan/hová vezettek volna azok a vonalak?
hunnylander: ''A K8 leszerepel a Conroe ellen, még magasabb órajelen is.'' Én ott csak azt látom, hogy azonos órajelen (3GHz) a C2D kb. 30%-kal jobb. Az meg nem csoda, hogy 2x-4x annyi ''CPU''-val (maggal) jóval gyorsabb valami.
[Szerkesztve] -
robyeger
addikt
-Az hogy a processzor milyen mikrokódokra bontja szét a komplex x86 utasításokat lényegében szoftveres, ezt szokták hiba esetén patch-elni alaplapi BIOS frissítésekben és esetenként változtatni egy új stepping megalkotásakor. Ha az AMD azóta nem volt képes megoldani, az X2 magok közvetlen kommunikációját, akkor nagy valószínűséggel nem szoftveres problémáról van szó.
[link]
Hova jutottunk, több magot képzelni a Hammer-be
Biztos a hypertransport is 3maghoz kapcsolódik azért számozták be 0,1,2-vel 
Vagy a CPU 0 ugyan fizikálisan nincs ott, de be van tervezve, ezért kapott 0 sorszámot Ez még a kopasznak is hajmeresztő! Az általad említett prezentációban érdekes módon az osztott memóriavezérlőt se ábrázolják/említik, talán azért mert akkor még azt se tudták mi fán terem. Számos cikk született a Hammer megalkotásának idején, mutassál már egy hivatalosat is, amiben a hammer és a multicore szó szerepel! Az igaz, hogy több processzoros rendszerről van szó és annak is tervezték, de több magról akkoriban szó sem volt. Még1x a fenti ábrából szeretnék X2-st látni!
Ha valakinek sikerül magáról levetnie márkarajongását, egyszerű logikával rájöhetne, hogy pl. 2Ghz K8-esetén, ha SRQ felől is 16GB/sec sávszéllel lehetne elérni az L2 cache-t, akkor nem lenne szükség L3 cache-re és dupla buszszélességre.
[Szerkesztve] -
P.H.
senior tag
Most vettem észre, hogy nekem lementve a linkelt .PDF 2005 októberi verziója (rev. 3.28) van, viszont a link egy 2003-asra mutat, amiben még nincs benne az említett záró megjegyzés:
''Note: The processor’s HyperTransport links operate in Synchronous (Sync) mode as described in the HyperTransport I/O Link Specification. Sync mode operation requires the transmit and receive clocks for all links to be derived from the same time base. If different clock generators are used to drive the reference clock to the devices on both sides of the link, then the following requirements must be satisfied to ensure proper link operation:
1. All clock generators must use the same reference clock source.
2. Spread spectrum clocking must not be enabled in any of the clock generators unless the frequency deviations are synchronized between the outputs of all clock generators.''
És nincs benne a 12.4 szakasz sem:
''The BIOS should determine the set of frequencies that a processor is capable of for every HyperTransport™ link connected to the processor. Each frequency in the set must be defined by the corresponding link frequency capability bit in the LnkFreqCap field, Function 0, Offsets 88h, A8h, C8h, and it must be equal to or less than the maximum frequency values specified in the processor data sheets.
If a HyperTransport™ link is non-coherent, then the BIOS should initialize the HyperTransport™ link frequency (Link field, Function 0, Offsets 88h, A8h, C8h) with the highest value from the set of frequencies of which the processor is capable and which is less than or equal to the maximum frequency values specified in the chipset data sheets, and the maximum frequency supported by the platform.
If a HyperTransport™ link is coherent, then the BIOS should initialize the HyperTransport™ link frequencies (Link field, Function 0, Offsets 88h, A8h, C8h) of both processors with the highest common frequency value from the sets of frequencies of which each processor is capable that is less than or equal to the maximum frequency supported by the platform.'' -
robyeger
addikt
Abba úgy látom egyet értünk, hogy a kutya az SRQ és L2 cache környékén van elásva. Én nem hiszem, hogy csak szoftveres akadálya lenne, hogy a magok gyorsítótárai közvetlenül kommunikáljanak, mondjuk a MOESI protokoll lenne a hibás. Szerintem egyszerűen ugyan az motiválta az AMDt, mint az Intelt, akkortájt ''hogy lehet minél gyorsabban összeilleszteni két magot''. Ennek legegyszerűbb módja, ha magok közvetlenül kommunikációját kizárjuk. pedig régen azt hittem az L1 cachek képesek gyors adatcserére a magok között, ha már az L2 lassucska
, hiszen az AMD a magok között magórajeles kommunikációval reklámozza X2 procijait. Viszont a memória sávszél benchmárkokban szó nincs magok közötti kommunikációról, egyszerűen a két mag függetlenül egymástól hoz fel adatokat a memóriából, itt kibukik, hogy maga az L2<->mem átvitel lassabb, mint 6.4GB/sec. Én nem akarom átrajzolni a K8-as ''metszeti'' ábrákat, de ha nem az SRQ-nál van a processzor szorzó, akkor mond meg te hogy hol van?? -
dezz
nagyúr
Látom, nem vagy a tömör fogalmazás híve. ;) De én nem szeretném ezt most hozzád hasonlóan a legapróbb részletekre kiterjedően kifejteni.
Viszont nem egészen értem, melyik rész nem egyértelmű a számodra. Na mindegy, majd valahogy összejön.
Arra gondolok, hogy pl. az aritmetikai művelet+memória(/cache)-művelet típusú utasítások K8/K10 esetén jó esetben egy makro-op-ot eredményeznek, miközben Core2-n ez általában 2 különálló mikro-op lesz.
Nos, korábban volt ugye szó a két architektúra szélességéről, és a kiindulóul szolgáló cikkben 3 vs. 4 ''egységnyi'' szélesség szerepelt. Csak - mint ugyancsak szó volt róla - a cikkíró mindkettőnél egyformának tekintette ezt az ''egységet'', mikro-op-nak írva mindkét helyen. Pedig AMD-nél valójában makro-op-ról van szó, ami 2 mikro-op-ot tartalmazhat, pl. magában foglalhatja a fenti műveletekhez szükséges 2 mikro-op-ot. Ezáltal, mikro-op-ban mérve 6 vs. 5-ös szélességről beszélhetünk, az AMD javára. És ez valódi effektív érték, mivel fenti típusú utasítások jó esetben tényleg ''megvannak'' 1 makro-op-ból.
#1450: Hmm, ha jól értem, ha módosítva volt az adat, legalább akkor valamilyen közvetlenebb úton olvassák ki a procik egymástól, nem? Nos, milyen úton?
Raymond+Rive: Erm, igen, legalább nekem utána kellett volna jobban nézni, ha nem vagyok benne biztos. Csak túl egyértelműnek tűnt, mivel valahogy összekevertem a szót a kauzalitással.
AMD Power: Nézd csak meg most a kommenteket, van ott a végén 1-2 érdekes. ;)
[Szerkesztve] -
#95904256
törölt tag
Igazából olyasmire gondoltam pl. hogy fut egy modulo képző program (több százezer bit hosszú adatokkal) és egy bizonyos tartományban ( pl. ami 4Gbiten (512MB-on) ábrázolható ) a modulo eredményeket 1-1 bit bebillentésével jelzi illetve érzékeli hogy már volt ilyen eredmény ( pl. BTS utasítás ). Ilyenkor párhuzamosan futhatna több modulo-képzés egy közös bittáblával, ami OS szinten osztott memóriaterület...
Viszont ez a cache-vonalért történű küzdelem is érdekes. Honnan tudja egyik-másik CPU hogy a másik CPU mely memóriacímeket birtokolja? Minden egyes memóriaírásnál lekérdezi pl. a HyperTransport-ton keresztül hogy az adott vonal foglalt-e már egy másik CPU által? Ez egy 8 CPU-s rendszerben erősen visszafoghatja a memória írási sebességet...
Vagy van ennél jobb megoldás? -
robyeger
addikt
Tényleg pedig olvastam a cikket. Majd megpróbálok levelezni orosz barátunkkal, de talán van más is akit érdekel a mondandóm, ezért megosztanám
Szeretem a K8-at, mindig tud új meglepetéssel szolgálni , ezért kezdem a:
2. Akár hogy akarom fordítani tényleg azt jelenti hogy a magok a memória ''buszon'' keresztül kommunikálnak. Eddig azt hittem, hogy az AMD-nél a két K8-as magot az SRQ-nál illesztették(kapcsolták) össze és csak azért csináltak osztott memória vezérlőt, mert a K8 csak 1db 128bites memória csatornát tud használni, és megosztva a vezérlőt a magok függetlenül tudnak egymástól kommunikálni a memó felé, amúgy nem lenne lehetséges, egymásra kellene várniuk. Utána olvastam a MOESI protokollnak és úgy néz ki igaza lesz orosz barátunknak. Amit kihámoztam, hogy a valóságban a két magot kizárólag a memóriavezérlőnél(IMC) illesztették össze, akkor pedig nem lehet egy időben 1magnak, a memóriával és a másik maggal is kommunikálni. Szerintem ez csak késleltetésben jobb a PentiumD megvalósításhoz képest integrált volta miatt, módszerében viszont ugyan olyan primitív. K10-nél már 2x64bitet fognak használni, így 2db független kommunikáció lesz lehetséges.
1. X-bit labs már a Hammer-nél se nagyon ecsetelte a processzor szorzót, sajnos most se tette meg. Hiszen a IMC magórajelen működik és az XBAR-on is olyan sebességgel szaladgálnak az adatok, pont ezért lassúnak nem lehetne nevezni, csak ha útközben ott van az SRQ - L2 cache páros, ahol a szorzó miatt szenvedi el a nagyobb késleltetést.
[Szerkesztve] -
FireGL
aktív tag
''(mert ebben a cikkben szó nincs arról, hogy változott volna a kettő közti busz órajele)''
Több helyen szó volt róla, hogy a K10 a DDR2 1066MHz memóriákat is szabványosan fogja kezelni. Ezt pedig 200MHz-es órajel miatt nem stimmel. Mivel írták, hogy az AM2-vel is visszafelé kompatibilis lesz, lehet itt fog 200-on menni. Ha az 1066MHz-es memória sebességből következtetek akkor az AM2+ az órajelben is lehet hogy hoz változást. -
robyeger
addikt
Hali! Csinos összefoglaló, grat
De két dolgot kritizálnék, amiről már régebben eszme cserét is folytattunk:
1. ''Az L2 cache exkluzív szervezésű: nem található meg ugyanaz az adat az L1-ben és az L2-ben egyidőben. A két szint 2 db egyirányú buszon cserél adatot, az egyiken fogad, a másikon küld. K8 esetén mindkét adatút 64 bites, így 8 órajel szükséges egy 64 byte-os egység cseréjéhez '',
-szóval ide nyugodtan oda lehet írni, hogy ez alapórajel, hátha valaki azt hiszi, hogy magórajel, ezért is látszódnak magas késleltetések.
2. ''Látható, hogy az L3-cache jelentős hatással van a magok közti kommunikáció sebességére. Amint korábban kiderült, a korábbi Athlon64 processzorok magjai a memóriabuszon keresztül cserélnek adatokat, nagyban lassítva a közösen módosított adatok cseréjé'',
-nem tudom te mit nevezel memóriabusznak?, de itt nem megy le az adat a memóriavezérlőhöz, sőt még az XBAR-on se halad át, a magok az SRQ keresztül kommunikálnak, maga a szorzás (processzor szorzó) is ezen egységben történik.
[Szerkesztve] -
dezz
nagyúr
Kösz a kimerítő leírást. De még nem derültek ki a következők:
1. Pl. az ADDPD xmmreg1, xmmreg2 (mem) utasításban mi a ''(mem)''?
- Ha ez memória-hozzáférést takar (ami persze jobb esetben valamelyik cache-ben végződik), akkor AGU-s indítás ide vagy oda, az LSU is meg van dolgoztatva, tehát egy macro-op-ból megvan az egész! (Így tehát egy Inteles micro-op inkább egy AMD-s micro-opra hajaz, semmint egy egész AMD-s macro-opra - tehát a ''3 vs. 4 szélesség'' helytelen, és ez inkább 6 vs. 5 szélesség!)
2. Ha az FPU-s memória-műveletet is az AGU és az LSU végzi el, mit csinál az FSTORE? (Nyilván mást, mert láthatóan nem utasítható egy macro-op load/store/load-store micro-opjával, külön macro-opot igényel, ha más FPU-beli alegységgel is van ''dolgunk'' egy utasításban.)
Andre1234: Milyen dátumról van szó? A japán demózásról? Az előző sem volt túl informatív, csak egy screenshot jött ki, ami igazolta a 3 GHz-t, meg hogy szépen futott pár játék, fps nélkül.
[Szerkesztve] -
#95904256
törölt tag
Épp ma kezdtem el irogatni egy kis programocskát amivel letesztelhető pár utasítás latency értéke. Ugyanis készülök a K10/Penryn megjelenésre.
Na, de visszatérve az FPU esetében említett +6 órajeles késleltetésre, azt kell mondjam hogy az meglehetősen jól el van rejtve, ugyanis a cím az integer regiszterekből generálódik, a CPU meg elég jól képes előre látni. Ezért a tényleges futásidő szempontjából ez már nevezhető ideális esetnek. Egyébként van valami információd arra vonatkozóan hogy kb.milyen gyakran fordulnak elő a nem idális esetek? Ráadásul ezen eseteknél sem mindig a +6 órajel késleltetés érzékelhető. -
dezz
nagyúr
''#1316: így értendő (L1-hozzáférés +2 cycle latency, az FMISC/FSTORE az egyoperandusú nem-integer műveleteket - konvertálás, ilyesmi - hajtja végre):
ADDPD xmmreg1, xmmreg2 DirectPath Single FADD 4 1/1
ADDPD xmmreg1, mem DirectPath Single FADD 6 1/1
ADDPS xmmreg1, xmmreg2 DirectPath Single FADD 4 1/1
ADDPS xmmreg1, mem DirectPath Single FADD 6 1/1''
Ezt most nem egészen értem.
''A memóriahozzáférést természetesen az AGU-k végzik, kiteszik a result bus-ra az eredményt. 3 result bus van összesen, az operation micro-op ott kapja el az eredményt, ahova ment (integer vagy FPU egység)''
Ahamm. Eddig azt hittem, az AGU-k, azaz az Address Generation Unitok a nevüknek megfelelően memóriacímeket számolnak (pl. indexelésnél), és magát a műveletet egy LSU hajtja végre.
ps. előnyösebb lenne nem keverni egy válaszban jelzés nélkül mások szövegeit a címzettével.
#1320: Hát, ebből most nem igazán tudom kibogózni, hogy a válasz igen vagy nem. Vagy néha igen, néha nem?
7600GT: Fusion = a CPU és egy GPU közelebbi viszonyba hozása. Korábban úgy volt, hogy eleve egy chipre lesznek integrálva, de mivel ez egyelőre technikailag problémás (az AMD CPU-i SOI technológiához tervezettek, az ATI féle GPU-k meg nem, és az aktuális vonalszélesség is eltér), első körben a Torrenza platform keretében egy 2-foglalatos lapon az egyik foglalatba megy majd egy GPU, PCIe busz helyett a közvetlenebb HT buszon kommunikálva. A következő verzió meg az lesz, hogy egy tokba teszik őket, de 2 külön lapkán lesznek azon belül. Aztán majd úgy 2 év múlva jön az egy lapkára integrált változat.
A Fusionnek kétféle célja van:
- A feltörekvőben lévő GPGPU (General-Purpose computation on GPUs) alkalmazások gyorsítása - desktop/munkaállomás/szerver frontokon. Ekkor nem mint videovezérlő lesz kihasználva, hanem mint nagy mennyiségű számítást multiparallel elvégző egység. A GPGPU módszerről bővebben itt: [link]
- Költségcsökkentés - entry level desktop/laptop/egyéb mobil eszközök terén, mint integrált videovezérlő. (Igazából nem tudom, ez így miért jobb, mint ha a szokásos módon a chipsetbe lenne integrálva.) -
dezz
nagyúr
Hmm, én csak azt figyeltem, hogy az ''FPU Pipes'' oszlopban mely egységek szerepeltek. Az x86/stb. asm-et nem ismerem. Tehát, az xmmreg2 (mem) egy regiszter-tartalommal indexelt memóriahozzáférés, vagy ilyesmi? Ahamm! Most már kezd a helyére kerülni a dolog. Már csak azt nem értem, hogy ilyenkor mi végzi el a memóriahozzáférést? Azt hittem, ahhoz az LSU is kell.
[Szerkesztve] -
dezz
nagyúr
Így már talán érthető. Az nem számít bele a latencybe, hogy egy-egy dekóder kimenete - a doksi Figure 8-a szerint legalábbis - 1 macro-op széles, így egy Double-nek 2 órajel alatt kellene elhagynia?
Jól értem, te azt mondod, hogy egy macro-op load/store/load-store micro-op-ja nem az LSU-nak szól, hanem csak egy AGU-nak? És tehát egy külön macro-op utasítja az LSU-t? Hát, ezzel kicsit ellentmond a Table 1-ben olvasható definíció:
''A single macro-op may specify—at most—one integer or floating-point operation and''
(Nem beszélve a folytatásról:
''one of the following operations:
• Load
• Store
• Load and store to the same address'')
Szal, egy Load-Store Unitos műveletet nem neveznék integer vagy floating-point operationnak, hanem sokkal inkább egy load/store/load-store operationnak.
A másik dolog, hogy az FPU-ban nincs külön AGU, így nem tudom, itt kinek szólna a load/store/load-store micro-op, ha nem az FSTORE egységnek... De az ciklusszámokból úgy tűnik, mégsem így van a dolog. Talán az FPU is az integer pipeline AGU-it használja, így az fp-s célzatú macro-op-ok load/store/load-store micro-op-jai az integer pipeline-on mennek keresztül?
szerk: ja, közben még írtál, azokat most olvasom.
[Szerkesztve] -
-
P.H.
senior tag
Arra, hogy ilyen összecsapott lett a kódértelmezés, egyetlen mentségem, hogy már a [MOD] után született
XOR(/PS/PD)-t meg tényleg hagyjuk ki belőle, P2 óta tudja, hogy nem függ az előző értéktől.
És ez nem tárol eredményt, mindig ugyanonnan olvas (= nem függ a ciklusváltozótól sem a forrás-, sem a céladat címe)
[Szerkesztve] -
#95904256
törölt tag
Hali P.H.!
Ez engem is érdekel. Ugyanis többször próbáltam már különféle kódokat optimalizálni a különféle manual-ok alapján, mégis irgalmatlanul nehéz az IPC = 1,5-ös értéket megközelíteni. Sőt, sokszor 0,8-0,9 környéki értékek jönnek ki, a vTune-nal is.
Mondjuk az rendben van hogy ezek nem milliószor ciklusban végrehajtott kódok, meg nem is férnek be a ROB-ba ( ICU-ba ). De akkor is... kíváncsi vagyok a K10 féle retirement keresztmetszet növekedésre. -
#95904256
törölt tag
Hm... ha a retirement-en bukott el egy kód sebessége a K8-on, akkor tényleg érdekes lesz a helyzet a K10-nél.
Egyébként a keresztmetszeti bővülésnél nem összeadással hanem szorszással jött ki a négyszeres elméleti érték. ( Ha nem változik semmi akkor is kétszeres gyorsulás jönne ki (1+1=2), egyszeres érték helyett (1*1=1). )
A memory access reordering pedig valóban egy olyan elem ami elősegíti a nagyobb teljesítmény elérését, azonban ezzel nem lehet úgy számolni hogy pusztán rátevődik a gyorsulásra. Egyes esetekben ez összejön, de valahol szükséges is ennek az eljárásnak a megléte hogy ne a memória címzés sorrendje fogja vissza a gyorsabb végrehajtást.
[Szerkesztve] -
#95904256
törölt tag
Igen, elméletileg lehetséges. Ezért írtam hogy talán kimutatható lesz a dolog.
Azonban itt vannak az általad is említett szűk keresztmetszetek. Ha minden ilyen ponton duplájára vagy háromszorosára növeljük a szélességet, akkor ez maximálisan épp két-háromszorosára növelheti a teljesítmény. Ezért csak úgy érhető el a három feletti érték ha az utasítások végrehajtási és lappangási idejeit is csökkentik illetve átlapolják. A K8-hoz képest a végrehajtási idők alig csökkentek. Ilyen téren jelentős változást csak a 128 bites SSE feldolgozás tud felmutatni.
Pl. ha azt veszem hogy a decode-sávszélesség a duplájára nőt és az SSE végrehajtás is kétszer gyorsabb, akkor elméletileg négyszeresére nő a teljesítmény. Azonban a decode-sávszélesség mint szűk keresztmetszet ritkán jelentkezett a K8 esetében, így nehéz lesz kiaknázni a dupla kapacitásban rejlő lehetőséget. Ebből következik hogy nehéz lesz megközelíteni az elméleti négyszeres teljesítményt, a decode-sávszélesség oldalról nézve a dolgot.
szerk.: Itt a decode-sávszélességet épp nem mint szűk keresztmetszeti problémaként hoztam fel, de talán érzékelteti hogy ha valamit duplázok az nem jelenti automatikusan a kétszeres növekményt.
[Szerkesztve] -
Raymond
titán
A ket adat (orajel es TDP) egyutt lehangolo. Nem arrol van szo hogy mennyit fogyaszt magaban vagy hogy mennyit fogyaszt az Intel-hez kepest hanem hogy mit lehet kiolvasni a lekozolt modellek parametereibol.
1) A launch modelleknel max 2Ghz-es jon ki az is kis mennyisegben.
2) A 2.5Ghz-s aminel az adatok szerint nem is lesz gyorsabb mostantol szamolva majd egy evig (Q2 2008) csak a fesz emelessel erheto el. Sot mar a 2.4Ghz-nek is kell a fesz emeles. Ezert az ugras a 2.3->2.4 TDP-je kozt
3) A kilatasok Q2 2008-ra sem tanuskodnak valami vilagrengeto gyartasi ujitastol. A 2.4-es lemegy a 95W kategoriaba, de a 2.6-os meg mindig a 120W marad. Egy komolyabb tweak-nel nem 100Mhz kene hogy legyen a gyorsulas.
Mar regebben kitargyaltuk itt hogy az altalanos alkalmazasokban az IPC javulas nem lesz szamottevo az SSE2 128bit fogja hozni a leglatvanyosabb gyorsulast. Meg ha a K8-hoz kepest javitanak is az altalanos sebessegen a piac ma mar mashol tart. Ezert szomoruak a szamok. -
Raymond
titán
PD930 (3Ghz) WXP32bit:
Fast_SSE2__:___690 409 545 = 219 ms
Fast_SSE___:___934 399 785 = 312 ms
Fast_x87___:_1 247 955 570 = 406 ms
Slow_SSE2__:___591 240 315 = 187 ms
Slow_SSE___:_1 295 072 460 = 412 ms
Slow_x87___:_1 506 025 343 = 500 ms
Sajnos a K7-es gepemben bedoglott a trafo (leglabbis remelem hogy csak az) -
dezz
nagyúr
1. Nahh, a K10 nem menekülhet majd a teszjeink elől!
2. Hát ez jó, hogy a K8 x87-ben gyorsabb, mint SSE/SSE2-ben.
Nem egészen értem a következőket:
3. Ha x87, akkor miért ''MMX''?
4. Mi van, ha semmi sincs bejelölve?
5. Miért kell az elsőnek bejelölve lennie az SSE-khez?
6. Bug, hogy ki lehet kapcsolni úgy az MMX-et, hogy az SSE2 bejelölve marad?
7. Úgy látom, ezek a ''Fast'' és ''Slow'' elnevezések nem a legszerencsésebb. Tekintve, hogy ''Slow'' SSE2 nagyrészt ugyanaz, mint a ''Fast'' SSE2, csak ugye még ki is marad 1-2 dolog. (Miért ''Slow'', ha kevesebb eleve művelet?) A Fast és Slow SSE meg két eléggé különböző rutinok.
Szóval, ha nem haragszol, ezeket a jelöléseket és elnevezéseket lehetne intuitívebbre is venni. Persze ez a program nem egy tesztprogramnak készült, így nem ez volt az elsődleges szempont. Ha ha van kedved, átalakíthatnád esetleg egy kicsit a GUI-t. Pl. lehetne 6db radiobutton, melyek közül csak egyet lehet választani, majd benyomni a ''Run'' gombot, vagy ilyesmi. A radiobuttonok mellett meg ott lenne egy rövid felsorolás, hogy milyen utasításokat használ. Na, mit szólsz? -
#95904256
törölt tag
-
A kisebbeknek meg létkérdés hogy a nem olcsó dizájnjaikat addig finomítsák amég lehet, adott technológiai szinten.
. Akkor mégiscsak tekercsekből van egy szívlapátnyi 
és ezeket kapcsolgatja.
Szerintem érdemes lenne áttenni a Logoutra. (A főbb dolgokat napi blogbejegyzésként, a többit azokhoz kommentként, ilyesmi.)
Csak a "nem szigorúan" nem stimmel.
Úgy mégiscsak 25%-kal több utasítást tartalmazna, másrészt olyasmit, ami Intelnél csak az SSE4.2-ben lesz (Nehalemben?). 
Vagy a CPU 0 ugyan fizikálisan nincs ott, de be van tervezve, ezért kapott 0 sorszámot 
Új hozzászólás Aktív témák
Hirdetés
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Az ide nem illő hozzászólások topikja:[link]
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva.
- BESZÁMÍTÁS! MSI B450M R 5 5600X 32GB DDR4 512GB SSD RTX 3060 12GB Rampage SHIVA Corsair 650W
- Bomba ár! Dell Latitude 5400 - i5-8GEN I 16GB I 512SSD I 14" HD I HDMI I Cam I W11 I Gari!
- IKEA Format lámpák eladóak (Egyben kedvezménnyel vihető!)
- Telefon felvásárlás!! iPhone 15/iPhone 15 Plus/iPhone 15 Pro/iPhone 15 Pro Max
- Samsung Galaxy A40 64GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest