- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Milyen okostelefont vegyek?
- A Honor és a Huawei uralja a kínai mobilpiacot
- iPhone topik
- Olcsó 5G-s ajánlatot nyújt a Realme Indiának
- Samsung Galaxy A54 - türelemjáték
- Samsung Galaxy A53 5G - kevesebbet többért
- Vodafone mobilszolgáltatások
- Apple iPhone 11 - népalma
- Fotók, videók mobillal
Hirdetés
-
A Video AI lehet a One UI 6.1.1 ütőkártyája
ma Vagy hogy fogja a mesterséges intelligencia manipulálni a mozgóképeket?
-
Rossz üzlet az EV-kölcsönzés
it Küszködik az EV-kölcsönzés miatt a Hertz Global, még több EV-t adnak el.
-
VR játék lesz az Alien: Rogue Incursion
gp Az év végén érkező program PC-re, Meta Quest 3-ra és PlayStation VR2-re érkezik a tervek szerint.
-
Mobilarena
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
#412
VaniliásRönk
nagyúr
P.H.
#411
VaniliásRönk
nagyúr
-
dezz
nagyúr
''Tehát nem lehet beleírni az L3-ba, mert oda csak azok az adatok kerülnek, amik »helyhiány« miatt kerülnek ki az L1-ből.''
Az L3 már más: ''The L3 Cache, however, is not exclusive, but allows for a shared bit to be set. If a core loads data marked as shared, it will reside in the L3 cache and can be fetched by other cores as well.'' (Dailyteches szövegből, ua. bekezd., de a pdf-ben is benne van.)
Eszerint tehát a L3-on kersztül megy. De akkor hogy jön ide a crossbar? -
dezz
nagyúr
Mint írtam, az idézet ugyanabból a bekezdésből van, a #409-ben linkelt DailyTech cikkből, ami egy bizonyos AMD-s illetővel készült, német lapban lehozott interjún ([link]) alapul. De úgy tűnik, a DailyTechesek félreértették az eredeti szöveget. Ime Babelfishes fordításban az ide vonatkozó rész:
''How admits already sufficiently is, AMD introduces with the K10 a third Cachelevel. This L3 Cache together can access all cores, while they have dedicated L1 and L2 Caches. Lie if those need data in the L1 Cache, can CCUa core them directly load. This functions also, if they lie in the L1 Cache of another CCU. In this case communication runs again over the CROSS bar. If the data lie in the L2 Cache, they are gotten into the L1 Cache and deleted in the L2 Cache. If the data lie in the L3 Cache, they can be loaded directly into the L1 Cache, without a detour over the L2.
If the L1 Cache is full, the oldest data are written there again into the L2 Cache, are this also fully, into the L3 Cache etc. into main storage. In contrast to the L2 Cache data loaded by the L3 Cache are not obligatorily rejected. Assistance of a Shared bit can mark the CCU core-spreading used data, it is then also to different cores at the disposal.''
Ez már egybe cseng a doksival:
''A.5.4 L3 Cache
The AMD Family 10h processor contains an integrated L3 cache which is dynamically shared between all cores in AMD multi-core processors. The L3 cache is considered a non-inclusive victim cache architecture optimized for multi-core AMD processors. Blocks are allocated into the L3 on L2 victim/copy-backs. Requests that hit in the L3 cache can either leave the data in the L3 cache—if it is likely the data is being accessed by multiple cores—or remove the data from the L3 cache (and place it solely in the L1 cache, creating space for other L2 victim/copy-backs), if it is likely the data is only being accessed by a single core. Furthermore, the cache features bandwidth-adaptive policies that optimize latency when requested bandwidth is low, but allows scaling to higher aggregate L3 bandwidth when required (such as in a multi-core environment).''
Naszóval, akkor azt mondod, hogy a másik mag L1-éből a L2 és L3 megkerőlésével, közvetlenül a crossbaron keresztül, a kérő mag L2-jét is megkerülve, kerül az adat a kérő mag L1-ébe. (Nem lenne olyan nagy ''csoda'', tekintve hogy mint írják a L1 és L3 között is van közvetlen kapcsolat, a L2 kihagyásával.) Nos, egy másik fórumon tanakodtunk erről, és én is pont ezt vetettem fel (oly módon megfogalmazva, hogy a crossbarnak vannak közvetlen vonalai a L3/L2 fölé is), mire majdhogynem lehülyézett valaki.
De akkor mégis így van. (Kivéve, ha több mag is írja/olvassa, mert akkor a L3-ba kerül, és ott is marad.)
[Szerkesztve] -
Raymond
félisten
Itt ez a sok doksi de meg nem vilagos hogy peldaul az orajelenkent elvegezheto 64bit SSE utasitasok is megduplazodnak e vagy nem a K8-hoz kepest. Mert a 128bit megduplazodik, de volt egy GDC2007-es AMD prezentacio es abban az volt hogy a 64bit nem. A PDF-bol amit kiolvastam viszont az jon le hogy igen.
Privat velemeny - keretik nem megkovezni...
-
dezz
nagyúr
Miért nem jön ki a 2x-es sebesség (főleg, hogy 5 ciklus helyett 4 alatt megvan a 2x64 v. 4x32 bit), legalábbis egy egymás után csak SIMD utasításokat tartalmazó programrészben? Vagy úgy érted, ott kijön, csak nem lehet túl hosszan ezt csinálni, plusz ''etetni is kell'', így a gyakorlati telj. kisebb?
Apropó, ha 2x annyi lett a számoló egységek száma, miért nem szélesítették ki a scalar x87 kód superscalar végrehajtását ezekre is? Akkor az is szépen gyorsulhatott volna...
''Az lebegőpontos algoritmusok ugyanazok maradtak, csak megduplázták a számoló egységek számát.''
Persze, nem tudom, honnan vettem ezt a 128 bites (egy értéket jelentő) operandust.
''- 2 db 32 bites adder/multiplier -> 4 db 32 bites adder/multiplier
- 1db 64 bites adder/multiplier -> 2 db 64 bites adder/multiplier''
Hmm, külön vannak 32 és 64 bites egységek? Azt gondoltam volna, 64 bites operand esetén összekapcsolva működik 2 32 bites egység. Vagy ilyen esetben esetleg függetlenül működhetnek, más utasítást végrehajtva? (Nem látom ennek jelét mondjuk.)
''Ha skalár SSEx vagy x87 utasítást használsz, akkor ugyanaz a megfelelő méretű 0. sorszámú egység fog számolni, a feldolgozás sebessége azonos. Sőt, ugyanarra a micro-op-ra vetíti le őket a DirectPath decoder, csak a méret SSE esetén az utasításba van kódolva, x87 esetén pedig a FPU Control Word-ből veszi a méretet (az FLDCW tudomásom szerint sorbarendező utasítás még mindig). Csak ami skalár SSEx-ben 4/5 byte-os utasítás, az x87-ben 2 byte-os.''
Szóval, az x87 itt (illetve kb. 2 generáció óta) használhatja az összes fp regisztert? Korábban ugye volt valami olyasmi probléma, hogy kevés volt a reg, és állandóan a stackba kellett pakolgatni (nem ismerem az x86-os arch.-t ennyire, csak valaki valami ilyesmit magyarázott).
''A párhuzamosság miatt jogosak a 2x és 4x értékek x87-tel szemben, de ennyi van benne, pont olyan marketingszöveg, mint az Advanced Media Boost, ami gyakorlatilag pont ugyanezt a szélesítést jelenti a másik oldalon.''
Azért pl. a C2D is elég szépen gyorsult tőle, 4x32 bit v. 2x64 bit SIMD-ben közel kijön a 2x-es seb., azonos órajelű P-D-hez képest. (Csak mondjuk a C2D nem megy akkora órajeleken gyárilag.)
Azt hiszem, itt azért látványosabb lesz a dolog, mert megvan az órajel, sőt magasabb is a K8-nál szokásosnál.
[Szerkesztve] -
dezz
nagyúr
Visszatérve még erre:
''- 2 db 32 bites adder/multiplier -> 4 db 32 bites adder/multiplier
- 1db 64 bites adder/multiplier -> 2 db 64 bites adder/multiplier
- 1 db 80 bites adder/multiplier -> 1 db 80 bites adder/multiplier''
Nos ugye felvetettem, hogy ebben az esetben kihasználhatnák ezt az FPU kód superscalar végrehajtásában, 2+x telj. elérve (+ pl. a 2. 64 bites, ill. 2-4. 32 bites egység más-más utasítást hajthatna végre SSE-ben is), de erről nem szól a fáma. Talán itt a megoldás:![[kép]](http://images.dailytech.com/nimage/1644_slide_54.png "[kép]")
Nagyban: [link]
Ezen ugye az látható, hogy 1-1 egész - adott műveletet végző - egység lett 128 bites. 1x64 bitnél nyilván csak a fele működik...
Csak nem értem a 128 bites FADD-ot és FMUL-t, amik ugye sima FPU-s egységek.
Egyébként működhet egyszerre az összes egység? Gondolok itt kevert SSE+FPU kódra.
Ja, meg még egy dolog: ha csak 2 SSE egység van, és 4 órajel alatt végeznek, akkor effektíve 2 órajelenként lehet új műveletet indítani, nem? Közben asszem ''rájöttem'': 4-ből csak 1-ben van ide vonatkozóan használatban az egység, 1 a load, és 2 a store? Akkor már értem, mire jó a több portos cache.
akosf: Nagyszerű, de hogy lesz ebből 1.5x telj. (fp), azonos, vagy épp alacsonyabb órajelen?
[Szerkesztve] -
#95904256
törölt tag
Hali P.H.!
Épp tegnap próbáltam az alábbi kódot egy K8 és egy Core2 magon:
(64 bit vs. 128 bit SSE)
cycle:
ADDPD XMM1,XMM0
ADDPD XMM2,XMM0
ADDPD XMM3,XMM0
ADDPD XMM4,XMM0
DEC EAX
JNZ cycle
A Core2 pont kétszer volt gyorsabb.
Fogadni mernék hogy ez cache-ben prefetchelt operandusok és más utasításokkal is működik. ( Na jó, MUL esetén 5 műveletet kell overlappolni a duplázáshoz. ) -
dezz
nagyúr
''Lebegőpontos egységeket nem lehet csak úgy összekapcsolni, 32-64-80 biten más-más a karakterisztika és a mantissza mérete.''
Érdekes ez a karakterisztika kifejezés, régebben még kitevőnek hívták, plusz az előjelbit. Na szóval igen, ezt én is tudom. (Valaha még kézzel kódoltam sp fp rutint, 68k-n, az FPU-s korszak előtt, amiben a szorzást/osztást exponenciális táblázatok segítségével csináltam. Jó gyors is lett, csak az volt a bökkenő, hogy így az összeadás-kivonás jóval bonyibb, és így végül az vitte el az ide nagy részét. ) Szal természetesen úgy értettem, hogy amikor együttműködnek, máshogy kezelik az operandust.
''Aztán itt megértettem, hogy mit értesz superscalar x87 alatt. Nem rossz elképzelés, de az elvisz a MISD/MIMD irányába (Multiple Instruction, Single/Multiple Data), ez nem az asztali gépek világa. SISD/SIMD alatt órajelenként egy végrehajtó egységbe egy művelet léphet csak be. (Raymond #450)''
Hát, régebben a SIMD sem asztali dolog volt. De amúgy a MIMD és a superscalar végrehajtás két különböző dolog. Előbbi esetben eleve így MIMD-ben kell programozni (hacsak nem csinálja meg neked valami különleges fordító), utóbbinál meg a proci intézi. Mint ahogy az integer ALU-knál teszik is már jó ideje! Egyébként azt hittem, már most 2-way (vagy itt hogy írják) superscalar az x87-es végrehajtás is, és ezt lehetett volna 4-wayra szélesíteni. Ha az x87-et hanyagolják is a jövőben, a scalar SSEx végrehajtást szerintem még fogják majd superscalarosítani, mert nem várható, hogy ezentúl minden számítási kódot SIMD-ben írnak.
A #468-ban FPU alatt a korábbi x87 egységet értettem. De látom, ide sorolódik minden, ami fp.
A macro-op és micro-op-os dolgot eddig is értettem. Ugyebár a végrehajtó egységek ugyanazok, és az új, bővített regiszter-készlet is a rendelkezésükre áll. Nyilván ezért ösztönzik ezek használatára, ill. ilyen kódra való fordításra a programozókat. És Rajmund ugye valami olyasmit mondott, hogy 64 bites Win alatt már nem is támogatott a régi regiszter-készlet. -
#95904256
törölt tag
Szerintem az OS programozóknak kellene figyelmesebbnek, felkészültebbnek lenniük, és nem a CPU gyártóknak kellene kézenfogva vezetni őket. Mert egyelőre csak az x87/MMX/3DNow! ... de aztán?
Jó, persze x87/MMX/3DNow! nem létszükséglet kernel módban, de az efféle ''korlátozom a szabadságod'' szemlélet nekem nem tetszik. Ezzel nem hibát szüntetnek meg, csak a hibalehetőségeket szűkítik. Ennek viszont van elegánsabb (szoftveres) módja is...
[Szerkesztve] -
dezz
nagyúr
Ha szemrevételezed pl. a #442-ben linkelt ábrát, ill. az 1-2-vel később linkelt ''magszerkezeti'' képet, láthatod, hogy 3db ALU van, és hozzá 3db scheduler is. Így lehetséges a 4 körüli IPC. Ugyebár ez a superscalar végrehajtás, ami az általános integer műveleteket illeti.
Azt nem tudom, most mennyire működhet egy időben az FMUL és FADD egység, illetve a többi, ami még ott van. De azt feltételezem, valamennyire igen. Ezt lehetne tovább bővíteni, ha több egység lenne, pl. 2-2 FMUL és FADD. Persze a ''körítést'' is bővíteni kell hozzá némileg.
Apropó, mint a ''magszerkezeti'' képen látható, az FMUL egység az x87 és SSE2 műveletek mellett a 2x32 bites 3DNow és SSE(1) műveleteket is elvégzik, tehát itt együtt van az 1-2-4x64 bit, és a 2x32 bit műveletvégzés. (Azt nem tudom, van-e az SSE2-ben 32 bites művelet, tehát 4x32 bit.)
Karakterisztika: akkor úgy látszik, itthon már rég óta így hívják, legalábbis x86 vonalon. Én csak 68k-ban utaztam, de arról sem olvastam soha magyarul.
ps. a többit majd asszem holnap, expressz meló van
[Szerkesztve] -
Raymond
félisten
Az eddigi cikkek szerint lesz javitas par dologban amit felhoztal:
Elagazasbecsles
- 512-entry indirect predictor
- double size return stack
- tracking more branches (nem talaltam szamot)
Load/Store
''Barcelona can now re-order loads ahead of other loads, just like Core 2 can. It can also execute loads ahead of other stores, assuming that the processor knows that the two don't share the same memory address. While Intel uses a predictor to determine whether or not the store aliases with the load, AMD takes a more conservative approach. Barcelona waits until the store address is calculated before determining whether or not the load can be processed ahead of it. By doing it this way, Barcelona is never wrong and there's no chance of a mispredict penalty. AMD's designers looked at using a predictor like Intel did but found that it offered no performance improvement on its architecture. AMD can generate up to three store addresses per clock as it has three AGUs (Address Generation Units) compared to Intel's one for stores, so it would make sense that AMD has a bit more execution power to calculate a store address before moving a load ahead of it.''Privat velemeny - keretik nem megkovezni...
-
#95904256
törölt tag
Hali P.H.!
Kipróbáltam a REP MOVSB, FSTSW illetve FCOS utasításokkal is a dolgot, miszerint a VectorPath felfüggeszti a többi utasítás dekódolását. Ez nem teljesen igaz. Valóban lelassul a dekódolás, de nem áll meg.
Kipróbáltam egy X2-esen is hogy milyen IPC-t lehet elérni: 2,997 -
Rive
veterán
- a decoder-ek »mögé« tennél egy Intel-féle nagyméretű trace cache-hez hasonló macro-op cache-t tennék, levenné a L1-ről és a decoder-ekről a sokszori felesleges munkát (pl. minden ciklus-lefutás újrafordítódik). Azt ne feledjük, hogy AMD-nél a 1x-stage pipe hosszának kb. felét teszi ki a fordítás macro-op szintre.
Huh. Korántsem vagyok benne biztos, hogy ez jó ötlet. Jelenleg az AMD az alacsonyabb frekin mozgó magokat használja. Ezeken a frekiken a dekóderek elegendően jól működnek. Egy trace cache nagyon sok extra tranyót jelentene: a disszipációt nem csökkentené.
Heveny emlékeim szerint a performance counterek segedelmével ellenőrizhető, hogy a pipe hányszor fogy ki a melóból a dekóderek késlekedése miatt. Szerintem ez a szám elenyésző, és olyankor is inkább a főmemória lassúsága a valós gond. Azaz SZVSZ a sebesség sem nőne.
- az elágazásbecslés-szempontú ugrásvégrehajtás mellett az előbbi prefix-szel együttműködve alkalmaznám azt a (például IA-64-ben implementált) elágazáskezelési technikát, amelyben spekulatívan mindkét ágat elkezdi végrehajtani, majd a kiértékeléskor az hamis ág utasításait eldobja. Igencsak megnőne az eldobott utasítok száma, viszont ugyanennyivel (összességében nagyban) javulna a megtartott utasításokok mennyisége a mostanihoz képest. Az micro-architecture elbírná szerintem ezt a többletnyomást.
Láttam erre vonatkozó számítást, aszerint sajna nem sokat hoz. A SUN shadow threadje jobb. Csak ott egy pöttyet durvább a memória-architektúra. Megvalósítható, de régebbi tapasztalataim szerint sok esetben kifejezetten a memória a szűk keresztmetszet.
- az egészet megfejelném a Hyper-Threading egy olyan megvalósításával, ahogy nem teljesen szimmetrikus a szálvégrehajtás, hanem az OS-től kapott prioritás mentén lenne egy főszál és egy mellékszál, ami a főszál által nem használt execution- és retirement sávszélességet használhatná. Azonos prioritási szinten természetesen szimmetrikus lenne.
Akkor viszont nincs értelme a fentebbi mókának. A hatékony HT egyik feltétele kifejezetten az, hogy legyenek munka nélküli VE-k.
Egy HT jó lehetne, de akkor mondjuk 4 integer VE/AGU, meg még két FP VE egy megnövelt L1 mellé. A P4 azzal szúrta el, hogy az eleve lassú főmemória mellé egy nevetséges L1Dcache került. Itt a főmemória pöpec, de az L1 csak elégséges. Két szálnak kevés lenne./// Nekünk nem Mohács, de Hofi kell! /// Szíriusziak menjetek haza!!!
-
#95904256
törölt tag
Hali P.H.!
Most aztán megvagyok keveredve, a szorzó és az összeadó áramköröket illetően.
Ezek szerint a műveletet ténylegesen végrehajtó egységek is pipe-oltak vagy csak az ütemező?
Ezt úgy értem hogy gondolom a tényleges szorzás nem 1 órajel alatt hajtódik végre ( rengeteg tranzisztort igényelne ), hanem közben több részeredményből tevődik össze, így vannak ''lépések''. Ezek a részeredmények haladnak egymás után, és ezt nevezzük pipe-nak?
Vagy úgy működik a dolog hogy van egy rakás különálló szorzó illetve összeadó és az ütemező amikor talál egy éppen nem foglalt egységet valamint van mit ''belepakolni'', akkor odaadja neki az operandusokat, az kiszámolja az eredményt ( 3/5 órajel ) majd elveszi tőle? -
#95904256
törölt tag
Remek! Köszönöm.
Újabb ezernyi kérdésem lett.
Jöhet belőlük egy pár?
1, Mit jelent és miért jó az hogy az L2 Cache 16 utas?
Gondolom egyszerre 16 hozzáférési kérelem ( írás / olvasás ) irányulhat a cache vezérlőhöz, de honnan a fenéből jön össze ennyi kérelem?
2, Az AGU-k generálják a memória operandusok címeit?
Ebből az következne hogy pl. egy ADD reg,mem legalább 2 macro opból áll. Először lefut az AGU-n a memória operandus címképző macro opja, majd utána az ALU-n lefut az összeadás. Valamint a lebegőpontos/MMX egységnél az FSTORE végzi azt a munkát mint az integer résznél az AGU. Jól gondolom? -
Rive
veterán
Szerintem ezekből nem lenne észlelhető gyorsulás.
Régebben dolgoztam már perf. counterekkel, akkor még egy kínlódás volt az egész. Most, ahogy hirtelen utánakapargattam, már sokkal kultúráltabb a dolog. Szóval regisztráltam az AMD-nél és letöltöttem a vonatkozó szoftvert. Néhány nap/hét, és lesz valami hiteles kép a tényleges szűk keresztmetszetekről. Esetleg más is megpróbálhatná a dolgot.
A tényleges végrahajtás során előforduló valós szűk keresztmetszetek ismerete nélkül nem nagyon lehet megbecsülni, hogy ténylegesen mitől mehetne jobban egy proci./// Nekünk nem Mohács, de Hofi kell! /// Szíriusziak menjetek haza!!!
-
#95904256
törölt tag
Az XORPD-t nem értem inkább. Nem 2 vagy 3 SSE ALU van a Core2-ben? 2 esetén már 0.5 órajel/utasításnak kellett volna kijönni.
Nekem van egy tippem, persze lehet hogy tévedek. De...
XORPD xmm,mem -> 1 órajel / utasítás ( 8 bájtos utasítás )
XORPD xmm,xmm -> 0,5 órajel / utasítás ( 4 bájtos utasítás )
Elvileg a Core2 x86 instruction predecodere 128 biten ( 16 bájton ) kapcsolódik az instruction cache-hez. A teszt kód 16 bájra volt illesztve, mégis, nem lehet hogy a decoder nem tudott két'' XORPD xmm,mem''-et 2x8 bájtról leképezni? -
#95904256
törölt tag
Összesen 128 bájtot címezgettem, nem hiszem hogy a Data Cache lett volna a szűk keresztmetszet, de ezt csak egy hét múlva tudom letesztelni.
A ''4/8 bájtos utasítás'' alatt azt értem hogy az utasítás kódja ennyi bájtra fordult le.
szerk.: Majd kipróbálom XORPD XMM0,[DATA0] helyett XORPD XMM0,[ESI+00] formában, így kiderül hogy a data vagy decoder oldalról jött be a csökkenés.
[Szerkesztve] -
Raymond
félisten
Hah, tudtam hogy varnom kell mert te sokkal ertelmesebben le tudod irni mint amit en kiizzadtam volna magambol
Nem is beszelve a plusz inforol...
A temahoz kapcsolodik ez:
[link]
Az oldal aljan vannak prezentacios slide-ok. Masodik sor elso kep ami a leirtakat szepen es egyszeruen illusztralja. Azon PR/Marketing slide-ok kevese koze tartozik ahol nem csusztat a gyarto mert nincs miertPrivat velemeny - keretik nem megkovezni...
-
Rive
veterán
Ahogy én látom: az AMD a NetBurst ellenében azért tudott talpon maradni, mert amíg a NB egy erősen specializált architektúra, addig az AMD K7/K8 általános célú: szélesebb körben nyújt kiegyensúlyozott teljesítményt. (Igen, ez most az Intel Core indulásával eléggé megborult.)
Szerintem az AMD-nek továbbra is ehhez az irányvonalhoz kell tartania magát, ha talpon akar maradni.
SZVSZ minden egy mag megosztott erőforrásaira épülő HT erősen korlátozó tényező lenne ebből a szempontból. Hacsak a szűk keresztmetszeteket fel nem oldják valahogyan, pl. extra erőforrások beépítésével.
A másik megoldással kapcsolatban - az elágazások mindkét felének párhuzamos végrehajtása, majd az egyik szál eldobása - elvi számításról tudok, miszerint ebben a formában nagyon kevés gyorsulás várható tőle, aránytalan erőforrásigény mellett. Azt meg ne kérdezd, hogy ezt az elvi számítást hol láttam: már volt néhány éve./// Nekünk nem Mohács, de Hofi kell! /// Szíriusziak menjetek haza!!!
-
Raymond
félisten
''Első gondolatom a cikk után az volt, hogy vagy nagyon rááltak a server-piacra, vagy hamarosan több CPU-s rendszereket akarnak látni az otthonokban.''
Mindketto es ilyen sorrendben Ezt csinaljak mar a Mustang bejelentese es a K8 gyakorlatbani megjelenese ota. A szerver piacon tudjak megszorongatni az Intelt technikailag es teljesitmenyileg meg persze ott nagyobb a nyereseg kisebb eladott darabszam mellett. A technologia aztan lejon a mainstreambe is. Amit most csinalnak mar par eve az a platform ertekesitese nem csak a processzoroke. Opteron, Hyperstransport, Torrenza, Fusion es mind egybevag. 4 es 2 socket rendszerekbe siman verni fogjak az Intel megoldasokat mind teljesitmenyben mind osszfogyasztasban. A 1 socket rendszerben labdaba fog meg rugni az Intel foleg az integer teljesitmeny es az oriasi L2 cache miatt ami ezeknel a feladatoklan jol jon. Bonusz hogy most nagyon divatos a stream processing es ott megintcsak ott vannak a nyitott HT/Torrenza rendszerel (pl. Clearspeed koprocik) es jon a sajat megoldasuk ami miatt (is) az ATI-t megvettek. Ezen kivul az IBM ugyanezt hasznalja a Load Runner projektnel Opteron + CELL kombinacioval.
Sokan temetik (nem rad gondoltam) az AMD-t mert a 3DMarkXY nagyobb eredmenyt az egy Core2Duo-val de azert nem eszik olyan forron a kasatPrivat velemeny - keretik nem megkovezni...
-
P.H.
senior tag
Persze elrontottam, szóval a 2xxx CPU-k 2-300 dollárnál kezdődnek, 8xxx CPU-k pedig jóval $1000 felett. Amellett, hogy 8xxx 4/8-CPU-s rendszerekhez kell, vajon mennyivel nagyobb költség a megteremtésük (főleg a kimondottan egységesített gyártásfolyamat óta), mint egy asztali X2-nek?
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
dezz
nagyúr
Igen, már én is rájöttem erre a 3/(2+2+2)-re, miután elolvastam a vonatkozó részt (az egészet egyben még mindig nem
).
A szöveg szerint a VectorPath utasítások 3+ uOP-ból állnak (load, computation, store[, store]), és ezeket az a bizonyos uCode Engine fordítja, nem pedig a sima dekóderek. Így viszont elvileg órajelenként 1 ilyen (makro)utasítás indulhat.
Az a szövegrész, hogy K10-en már 1 uOP egy 128 bites SSE computation, vélhetően arra vonatkozik, 1 computation uOP van, tehát a loaddal, és 1-2 storral együtt 3 v. 4. -
Raymond
félisten
Az MP szeria (tobb mint 2 socket) mindig is draga volt mindket tabornal. Mondjuk az egyik elonye a Barcelona-nak platform szinten a plusz meg egy HT link. Ez benne is van az RWT cikkben.
Szerk: A koltsegek nem nagyobbak egyiknel sem (gyakorlatilag csak a merettol fugg). Csak a kereslet kicsi a ''jotallas'' a helyes mukodesre pedig szivos igy megkerik az arat. Ugyanaz a helyzet mint mondjuk a repulogep gyartoknal a kontaktok vagy mas komponensek. Sokkal tobbet fizetnek ertuk mint mondjuk egy autogyar pedig ugyanaz kapjak meg. Csak a garancia eonokkal nagyobb rajuk.
Az IBM LoadRunner persze Roadrunner akart lenni [link]
[Szerkesztve]Privat velemeny - keretik nem megkovezni...
-
dezz
nagyúr
Ja, oké. Furcsa is volt, hogy csak 3 uOP széles a uCode Engine outputja, mert store-ral együtt már akár 4 uOP lenne (K8-nál meg akár 5). (Bár több lépésben is küldhetné a uOP-okat, de ez nem lenne túl hatékony.[*]) Viszont akkor nem értem, miért emleget a szöveg ''3 or more'' uOP-ot. Hogy jön össze K10-en 3-nál több?
[*] Mondjuk DirectPath esetén is ennek kell történnie, mert 2 uOP a sima dekóderek kimeneti szélessége. Nem?
Mindenesetre, a szöveg szerint a VectorPath utasításokkal csak a uCode Engine foglalkozik. Így nem nagyon lehet 1.0 CPI alá menni SSEx kódban. (Tényleg, az x87-es utasításokat tudják kezelni a sima dekóderek - annak ellenére, hogy adott esetben ugyanarra a uOP-ra fordulnak?)
Szerk: ''vagy hamarosan több CPU-s rendszereket akarnak látni az otthonokban.''
Lásd Athlon FX, és később Phenom FX vonal (socket F esetén): 2-procis rendszerek gamingre, videofeldolgozásra, stb.
[Szerkesztve] -
dezz
nagyúr
Hmm, de hát ez nem úgy van, hogy az x86(/x87/SSEx) gépi kód a makro-kód, ill. makro-op-ok, és a dekóderek által fordított RISC kód a mikro-kód, ill. mikro-op-ok? Ezért ír a cikk is mikro-op-okat...
<1 CPI (clock per instruction): hmm, de hát ugyebár a 3 sima dekóder egyszerre mehet, és ha pl. 1 ciklusos műveletek vannak, akkor miért ne jöhetne ki az 1 alatti CPI? -
dezz
nagyúr
Huh, hát ez nagyon szép, hogy ilyen kimerítően kifejtetted. Megjegyzem, azt hiszem, jóval rövidebben is megértettem volna. De gondolom, ezt már nem is csak nekem írtad.
Viszont akkor lenne még 1-2 kérdésem. A sima (DirectPath) dekóderek kimenete 2 mikro-op széles. (Vagy itt is 2 makro-opot kellett volna írniuk esetleg?) Naszóval, ebbe beleértendő mindaz, amit írtál még az 1-2 mikro-op mellé (mármint az egy makro-opban)? Mert ugye ha nem, akkor további ciklusokba kerülne mindet továbbadni, ami ugye lehetetlenné tenné a 3.0-ás IPC-t.
A másik: akkor ugye az olyan összetett, nem dedikált egységgel egyben, hanem több lépésben végrehajtott utasítások, mint pl. sqrt, több makro-opra fordulnak (és nem pedig több mikro-opra, egy sorozatban)?
A CPI-s kérdésemre válaszolok magamnak. Szóval, mint az opt. guide-ban látható, a legtöbb ''multimédia'' utasítás is DirectPath-os, így a 3 sima dekóderen mehetnek keresztül, és a throughputjuk 2/1 vagy 3/1 is lehet (instr./clock). (Azaz, SSEx utasítások egy részénél megvan az 1.0 alatti CPI.) Amik persze VectorPath-osak, azoknál a legjobb eset az 1/1 - lenne, de inkább 1/''sok'' a rátájuk.
[Szerkesztve] -
Raymond
félisten
''...egy decode elejére vonatkozó kérdés, hogy hogyan lehet egy órajel alatt több utasítás elejét/végét meghatározni.''
Ha jol ertettem akkor a pre-decode fazisban rejlik a megoldas. A leirtak alapjan a fetch-elt 16 byte adatot mar elore megjeloli mielott meg a scan/allign es onnan a decoderbe (direct es vector path) kerulnenek. [link]
[Szerkesztve]Privat velemeny - keretik nem megkovezni...
-
dezz
nagyúr
Ha egy makro-opban az 1-2 mikro-op mellett az eredeti gépi kódú utasításra vonatkozó, ill. abból származó információk is vannak, akkor hogyan lenne lehetséges, hogy először csak a mikro-opok adódnak tovább, és csak később csatolódnak hozzájuk ezek az egyéb mezők? Mindez az információ megvan az egyes mikro-opokban is, tehát a makro-opokba rendezés végülis egy protokoll, ami arra kell, hogy segítse a reorderinget?
(Az ICU gondolom a ROB. Mit rövidítesz ICU-nak?)
Az ábrákon a Pack Buffer kimenetét 3 uOP-nak jelölik - az merült fel bennem, hogy ennek inkább 3 makro-opnak kellene lennie, nem? Nekem így lenne logikus. Máskülönben csak 1 uOP-os DirectPath (tehát nem Double) műveletekből jöhetne össze 3.0-át közelítő IPC, Double-ekből már csak max. 1, stb.
A 3.0 feletti IPC, mint már kiderült, nem lehetséges itt. Viszont az 1.0 feletti nem csak integer kóddal jöhet ki!
[Szerkesztve] -
dezz
nagyúr
''''Early decoding produces three macro-ops per cycle from either path. The outputs of both decoders are multiplexed together and passed to the next stage in the pipeline, the instruction control unit.''
Na azért! Már kezdtem megijedni, hogy itt van egy érdekes szűk keresztmetszet, amikor megláttam a képet - de aztán arra gondoltam, ez nem lehet.
Meg akkor ugye az ábra fentebbi részein 1-1 makro-opról van szó valójában, csak eltérő számú aktív mikro-opot tartalmazhatnak.
''Ez vajon [fadd][fmul][---]-ra vagy [---][fmul][---], majd [fadd][---][---]-ra fordul?''
Hát ugye vagy az van, hogy a pre-decode egység figyeli a dependenciákat, és akkor a 2. eset van, vagy az ICU/ROB, és akkor talán lehet az első is. (Szóval a ROB küldené ki őket szépen egymás után.) Egy nagyon okos register-rename által jó esetben fel lehetne oldali a dependenciát (mintha Raymond írt is volna valami ilyesmit), de itt szerintem nincs ilyen, legalábbis nem látom, ebben az elrendezésben hogyan oldanák meg azt az esetet, ha erre éppen nincs lehetőség. -
Raymond
félisten
''...de vajon az mennyi idő alatt, és hogyan végzi el a dolgát?''
Itt szovegertelmezesrol lehet sz. Az en verziom a kovetkezo:
''We find a very large block of logic with fourfold symmetry directly near the position were the 16 byte blocks of data are read and written from and to the instruction cache. We'll discuss the most likely candidate here, A fourfold incarnation of an earlier pre-decoder described in gate level detail in US Patent 6,260,134
This fourfold version can, according to the patent which describes it, pre- decode an entire line of 16 bytes in only two cycles by means of what it calls: massively parallel pre-decoding..........
..........The instruction pipeline may invoke the pre- decoding hardware in this case to initialize or correct the pre-decoding bits within only two cycles.''
En ugy ertelmezem hogy ket ciklus alatt vegez fuggetlenul attol hogy magatol tette a dolgat beolvasaskor vagy ahogy ott irva van ''something is wrong'' es soron kivul kell meghivni. Hosszabb vagy rovidebb ideig nem tarthat mert csak 16 byteos blokkal dolgozik.Privat velemeny - keretik nem megkovezni...
-
dezz
nagyúr
Hát, ha még legalább konzekvensen a µop formát használná az Intel, az jó lenne, de állítólag egyes Intel doksikban a mikro-op formát használják. Bár ez még a kisebb gond, mert mikro-opban még valamennyire hasonlítanak egymásra, már ha nincs fúzió, de a ''makro-op''-jaik teljesen mást jelentenek.
''Prescott-tól talán ezt kiküszöbölték, a latency 1 lett, kérdés, hogy mennyi maradt meg ebből a Core-családra.''
Nem tudom, viszont a P4 vonalnak kevés köze van ehhez, mert a Core2 (a Core-on keresztül) a Pentium M-re épül (ami a P2-3-on kereszül a PPro-ra). ;)
Huh, nem sajnálták a tranzisztort és a területet attól a Massively Parallel Predecodertől...
Közben egy ilyet találtam a Core 2 predecodingjáról:
''7.15 Bottlenecks in Core2
Instruction fetch and predecoding
All parts of the pipeline in the Core2 design have been improved over the PM design so that the total throughput is increased significantly. The part that has been improved the least is instruction fetch and predecoding. This part cannot always keep up with the speed of the execution units. Instruction fetch and predecoding is therefore the most likely bottleneck in CPU-intensive code.
It is important to avoid long instructions in order to optimize instruction fetch and predecoding. The optimal average instruction length is approximately 3 bytes, which can be impossible to obtain.
Instruction fetch and predecoding is not a bottleneck in a loop that fits into no more than four aligned 16-byte blocks of code. The performance of a program can therefore be improved if the innermost loop has no more than 64 bytes of code or can be split into multiple loops that have no more than 64 bytes each.'' [link]
(Van itt szó másról is és más procikról is, érdemes átnézni.)
[Szerkesztve] -
#95904256
törölt tag
Annyit megjegyeznék attól hogy az Intel CPU-k uop gyárak, nem jelenti azt hogy nem hatékonyak. Ezen uop-ok valamivel egyszerűbb szerkezetűek mint a konkurens makro-opok, így egyszerűbb vezérlő logikát igényelnek. A Core2-es 96 uop-os ROB-ja még ha szűk keresztmetszetet is jelent, azért jelentősen nem marad le a K8 72 makro-op-os ICU-jától. Ehhez hozzátenném hogy szeretnék látni egy olyan kódot ahol ez jelenti a szűk keresztmetszetet, ugyanis erősen párhuzamos (OoO) végrehajtás szűkséges hozzá. Más szóval egy ilyen limitet csak magas IPC értékű kóddal lehet elérni, ami még ritka.
-
dezz
nagyúr
Pl. ''Inside Intel Core Microarchitecture. Setting new standard for energy-efficient performance'' white paper by Ofri Wechsler.
akosf: Az egyszerűbb vezérlő logika gyorsabb végrehajtást eredményez, vagy hogy érted? Vagy tranyószám/teljesítményben?
A Core2 a Pentium M-en alapul, ami - mobil proci lévén - spórolós design volt, főleg az aktuális csíkszélességhez képest (ami asszem 90nm volt). Aztán ezt némileg kibővítették, de csak annyira, hogy gyorsabb legyen, mint a K8. Viszont így maradt benne néhány szűk keresztmetszet. (Lásd alábbi linken, mik azok, magát a ROB-ot nem látom köztük.)
A K10-nél eleve a 65nm-hez (sőt talán már a későbbi 45nm-hez [értsd: 45nm-en lesz igazán gazdaságos]) alkalmazkodtak, azaz jóval kevésbé spóroltak a tranyókkal, vonalakkal.
[Szerkesztve] -
Raymond
félisten
-
#95904256
törölt tag
Hali P.H.!
Miután jó egynéhány algoritmuson kipróbáltam a különbséget az SSE és a 3DNow! közt így nem nagyon tudnak meghatni egy harmadik fél dokumentációi alapján történő találgatások. Természetesen lehet találni olyan feladatot ahol az SSE több regiszterben tárolt adat miatt előnyben van (8x4x32bit vs. 8x2x32bit), viszont 3DNow!-ra is lehet találni olyan feladatokat amelyek a DSP jelegű utasítások révén élveznek előnyt.
A reciprokos dolgot meg próbáld ki... Igazam lesz... -
#65675776
törölt tag
Ahhoz, hogy asztali fronton nincs IA-64 azért elég sok köze van a Microsoft-nak is. Kijelentették ugyanis, hogy nem fognak kétfajta 64 bites technológiát támogatni desktop vonalon. Itt viszont az AMD előbb jött, az intel meg kénytelen volt licencelni. Ahogy az NX bit-et is.
De akkor mégis így van. (Kivéve, ha több mag is írja/olvassa, mert akkor a L3-ba kerül, és ott is marad.)
![[kép]](http://www.beer-pages.com/images/heineken-case.jpg "[kép]")
).
Ez olyan 640kB memória mindenre elég tipusú kijelentés. 
Ú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.
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- A fociról könnyedén, egy baráti társaságban
- Autós topik látogatók beszélgetős, offolós topikja
- Linux kezdőknek
- Rendkívül ütőképesnek tűnik az újragondolt Apple tv
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Milyen okostelefont vegyek?
- AMD GPU-k jövője - amit tudni vélünk
- Mini-ITX
- MotoGP & WSBK
- További aktív témák...
- Beszámítás! Intel Core i3 10105 4 mag 8 szál processzor garanciával hibátlan működéssel
- Beszámítás! Intel Core i9-11900 Processzor - Garancia & Számla - Utolsó Darabok
- Intel Core i7-11700K processzor (használt)
- i5-9600K , és i5-9400F processzor eladó!
- BESZÁMÍTÁS! ÚJ Intel Core i5 11400F / i9 11900KF / i9 11900K tálcás processzorok 27% áfás számlával