- Amlogic S905, S912 processzoros készülékek
- Projektor topic
- 3D nyomtatás
- Azonnali processzoros kérdések órája
- Milyen billentyűzetet vegyek?
- Házimozi haladó szinten
- Melyik hordozható audiolejátszót (DAP, MP3, stb.) vegyem?
- ThinkPad (NEM IdeaPad)
- Hálózati kábelek és szerelésük
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
- gban: Ingyen kellene, de tegnapra
- Szevam: Érzelmi magabiztosság/biztonság - miért megyünk sokan külföldre valójában?
- bb0t: Gyilkos szénhidrátok, avagy hogyan fogytam önsanyargatás nélkül 16 kg-ot
Hirdetés
-
Az Apple megszerezné a klubvilágbajnokság közvetítési jogait
ph A vállalat ezért irgalmatlan pénzt fizetne a FIFA-nak, és ezzel rajzolná át az online streaming platformok háborújában a frontvonalakat.
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
-
iPaden is vége az App Store monopóliumának
ma Ősztől lehet alternatív alkalmazásboltból telepíteni az EU tagállamaiban.
-
PROHARDVER!
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
#95904256
törölt tag
Meddig kell még várni az új AMD arhitektúrára?
Mi a legutóbbi ígéret? Már szívesen izzítanám...
Ott vagyunk már?
Ott vagyunk már?
Ott vagyunk már? -
#95904256
törölt tag
Mutatnátok egy olyan integer utasításokat tartalmazó forráskódot amelyik egy Core2-n gyorsabban fut mint egy K8-as magon azonos órajelek mellett?
-
#95904256
törölt tag
Megjegyezném hogy a P4D-ről a C2D SSE végrehajtása nem csak a 128 bites engine miatt gyorsult jelentősen.
Lássuk pár SSE2 utasítás késleltetési / ütemezési idejét:
MOVAPD xmm,xmm: 7 / 1 ---> 1 / 0,33
ADDPD xmm,xmm: 5 / 2 ---> 3 / 1
MULPD xmm,xmm: 7 / 2 ---> 5 / 1
elméleti sebességnövekmények:
Adatpakolászás: 7*1/1/0,33 = x 21,0
Összeadás: 5*2/3/1 = x 3,33
Szorzás: 7*2/5/1 = x 2,8
A K10-re visszakanyarodva, az alábbiakra számíthatunk:
MOVAPD xmm,xmm: 1 / 0,33
ADDPD xmm,xmm: 4 / 1
MULPD xmm,xmm: 4 / 1
Ez versenyben van a Core2-vel. -
#95904256
törölt tag
Hm... Az hogy MMX és 3DNow! kiszorul és helyett csak SSE utasítások lesznek, az rendben. De hogy az x87 kiszorul, az szívszorító.
Pár nagyon jó dolog elveszne...
1, bővített pontosság (80 bit)
- ugye ezzel 32 biten is lehetett 64 bites integer szorzást, osztást csinálni...
(szerk.: az INTEL CPU-k eleve az FPU-t használják integer osztáshoz, így jóval gyorsabb is az AMD CPU-knál)
- jól jött amikor dupla pontossággal nem mentek a dolgok...
2, egyszerű X^Y számítás lehetősége (F2XM1)
- mert eddig nem csak szögletes volt...
3, maradékképzés
- ez pótolható, közel azonos végrehajtási idővel
4, szögfüggvények
- ezeket eddig 80 bit pontossággal tudta a proci...
(mondjuk a sinust olyan 50 bit pontosságig gyorsabban lehet SSE2-vel produkálni, de ez felett már gyorsan nő a szükséges look-up tábla méret vagy a szükséges órajelek száma)
5, logaritmus
- kár érte...
[Szerkesztve] -
#95904256
törölt tag
dezz: Úgy érted hogy az FPU regiszterek ''dedikáltsága'' vagy a temporary regiszterek szűnnek meg?
Ha ez előbbi, akkor hurrá! Sikerült átdolgozniuk (egyszerűsíteniük) az egész egységet. Ez kisebb késleltetéseket, kisebb fogyasztást jelenthet.
Ha az utóbbi, akkor: Megspórolnak pár ezer tranzisztort, viszont a ''speciális'' műveleteket lelassítják. ( szögfüggvények, maradékképzés, logaritmus, ... ) -
#95904256
törölt tag
Hali Raymond!
Szerintem megrázó lesz amit mondok.
Tökéletesen működik az összes FPU/MMX/3DNow! utasítás 64 bites Windows alatt, méghozzá mindenféle hókusz-pókusz nélkül. Ezt már csak azért is mondom mert nap mint nap használom. Egyébként furcsa lenne hogy egy OS leakarná tiltani a processzor egyes utasításait. Na jó, vannak privilegizált utasítások... De pl. eddig sosem volt szükségem arra hogy MSR tartalmat módosítsak. -
#95904256
törölt tag
Én csak azt mondom hogy nyűgös leszek ha előkell ásnom a FPU emulátoraimat...
Legutóbb egy 386SX-en használtam efféle cuccot... Úgy tizenegynéhány éve...
Erről a letiltásos históriáról hol lehet bővebben olvasni?
Natív 64 bites módban egyedül a PUSHA/POPA páros nem működik. -
#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. ) -
#95904256
törölt tag
Akkor valamit nem értek vagy valamit te értettél félre.
Szerintem az általam felhozott programrészlet azért fut pont kétszer lassabban K8-on mert az kénytelen 2 macro-opra bontani mindegyik utasítást, míg a Core2 csak 1 macro-opra bontja. Ha jól sejtem 1 db SSE egység esetén is ugyanezt a különbséget tapasztalnám. Ez abból jön hogy a fenti programrészletben 4 db 4 órajel késleltetésű utasítás szerepel. Vagyis az átlapolás tökéletesen működik 1 db SSE egység esetén is.
Tehát nem értem hogy miért hoztad fel hogy az eredmény az exec unitok száma miatt jött ki.
szerk.: Tévedtem, az átlapolás nem úgy működik ahogy azt eddig gondoltam.
[Szerkesztve] -
#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] -
-
#95904256
törölt tag
válasz #95904256 #490 üzenetére
Eddig ennyit sikerült találnom:
The Core microarchitecture also substantially improves on the floating point and SSE capabilities of its predecessors. Although Core’s 3 SSE units are not fully symmetric, the differences are relatively minor (shifting and multiplication resources).
Vagyis majdnem minden a három azonos. -
#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 -
#95904256
törölt tag
Hali Rive!
Kipróbáltam egy X2-esen is hogy milyen IPC-t lehet elérni: 2,997
Ezt hogyan? Per-core? Csodálkoznék...
Mit használsz? Utasításszám, vagy a performance-counterek?
Egyszerűen végrehajtottam rögzített mennyiségű utasítást (n) és a timestamp countert felhasználva megmértem hogy mennyi órajelre volt szüksége (t). Ebből számoltam ki az IPC értékét ( x = n/t ). Természetesen egy magon futott le az egész.
A mérés után megnéztem a K8 arhitektúra sematikus rajzát, ami alátámasztotta a fenti értéket. 3 párhuzamos utasításdekóder van benne.
Természetesen egyszerű utasításokat használtam ( FADD,FMUL,MOV,DEC,JNZ ).
[Szerkesztve] -
#95904256
törölt tag
Hali Raymond!
Az ''ars technica'' cikk valóban érdekes, de első neki futásra kicsit gyanúsak voltak azok a kifejezések hogy: I'm guessing; I'm currently assuming; I'm suspect, ...
Szóval kicsit megmozgattam a Core2 lebegőpontos SSE műveleteket végző egységeit.
100.000 (8x12.500) műveletet végrehajtva az alábbi idők jöttek ki:
ADDPD reg0-7,mem -> 1,1 órajel / utasítás
DIVPD reg0-7,mem -> 31,1 órajel / utasítás (itt már jelentős a várakozás)
MULPD reg0-7,mem -> 1,1 órajel / utasítás (na, ezt hogy csinálta?!)
XORPD reg0-7,mem -> 1,1 órajel / utasítás
SQRTPD reg0-7,mem -> 57,2 órajel / utasítás
Gondolom az 1,1 órajelből az 0,1 azért jött be mert nem volt egy 9. regiszter a további latency time átlapoláshoz. Ha egy ADDPD 3 órajelig tart, és 1 órajeles átlag jött ki akkor hány DP (64 bit) összeadó dolgozott egyszerre? 6...
A MULPD-s mérést többször is átnéztem. Hibátlan eredménynek tűnik. Viszont ez azt jelentené hogy egyszerre 10 DP szorzó egységnek kellett működött. Ez szerintetek lehetséges? Tényleg ilyen ''FPU monster'' a Core2? -
#95904256
törölt tag
válasz #95904256 #525 üzenetére
Core2:
ADDPD reg0-7,mem -> 1,1 órajel / utasítás
DIVPD reg0-7,mem -> 31,1 órajel / utasítás
MULPD reg0-7,mem -> 1,1 órajel / utasítás
XORPD reg0-7,mem -> 1,1 órajel / utasítás
SQRTPD reg0-7,mem -> 57,2 órajel / utasítás
K8:
ADDPD reg0-7,mem -> 2,1 órajel / utasítás -> 2 db 64 bites összeadó (FADD,FMISC?)
DIVPD reg0-7,mem -> 34,1 órajel / utasítás -> 1 db 64 bites osztó (FMISC)
MULPD reg0-7,mem -> 2,1 órajel / utasítás -> 2 db 64 bites szorzó (FMUL,FMISC?)
XORPD reg0-7,mem -> 2,1 órajel / utasítás -> 2 db 64 bites logika (ALU)
SQRTPD reg0-7,mem -> 48,1 órajel / utasítás -> 1 db 64 bites gyökvonó (FMISC)
Szóval a K8 is veri a Core2-t, gyökvonásban. -
#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? -
#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] -
#95904256
törölt tag
Szia dezz!
Említetted hogy az AMD 30-40%-os FP (SSE2+) előnyt mond a K10-re a Core2-vel szemben, holott a műveletvégzők mennyisége azonos. Ez egyben azt is jelenti hogy a Core2 műveletvégzői az idő legalább 30-40%-ban ''üresben'' járnak. Már pedig az eddigi eredmények alapján úgy tűnik, az Intel mérnökei nem végeztek ilyen ''csapnivaló'' munkát.
A K10 így látatlanban csak hajszálnyival tűnik gyorsabbnak. Nem látok benne olyan csodát ami indokolná hogy könnyűszerrel ''lelépje'' a konkurens arhitektúrát.
P.H.
Szerintem a CPU hatékonyságát jelentősen növelné az is ha nem kellene minden egyes utasítást minden egyes végrehajtás előtt újra és újra micro/macro opokra dekódolni. Ezzel legalább 2-3 lépcsővel csökkenne a pipeline hossza az ismételt végrehajtásoknál.
[Szerkesztve] -
#95904256
törölt tag
Szerintem összeszedted az összes olyan különbséget amiért a K10 egy hajszálnyival képes a Core2-re ráverni. Talán a 256 bites I-cache ami egy kicsit talányos. Akárhogy is nézegetem, az a Core2 nagyon eltaláltatott. Csak egy-két extrém eset az amiben a K8 utoléri (megelőzi). Amennyire a Core2 eltér a NetBurst-től, a K10 annyira hasonlít a K8-ra. Olyan mint egy nagytestvér. Meglátjuk mi lesz belőle.
Az FMISC valószínűleg a VectorPath-os FP utasítások miatt ''egyéb'' dolgokat jelöli.
Pl. sinus, cosinus, integer műveletek, ...
A K8-ból IPC=3,000-t lehetett kicsikarni, nem többet. Egyébként kíváncsi vagyok hogy szerinted hogyan lehet elérni nagyobb értéket. -
#95904256
törölt tag
Hali dezz!
A K8-on az FDIV az FMUL-on keresztül hajtódik végre méghozzá úgy hogy azon az egységen minden felfüggesztődik ( tapasztalat hogy nem lehet átlapolni az osztással párhuzamos szorzásokat, de lehet hogy még az előjelváltás (FCHS, FABS) sem működik ).
Na jó, kipróbálok még pár vectorpath+directpath kombinációt egy jobb IPC érték eléréséhez ( hátha... ), de szerintem amit microcode enginnek vélsz az nem más mint az utasítások kezdőcímét meghatározó/tároló egység. Ugyanis nem piskóta dolog megmondani egyszerre 16 bájton hogy hol kezdődnek utasítások. Ugye ez kell ahhoz hogy egyszerre több utasítás dekódolásának lehessen nekikezdeni. Tkp. akkor lehetsz biztos a második, harmadik, stb. utasítások kezdőcímében mikor az elsőnek ( előzőnek ) a hosszát is sikerült meghatározni. Gondolom egy ömódosító kód ( SMC ) elég jól megtudja bolondítani a dolgokat. -
-
-
#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.
-
#95904256
törölt tag
Dezz, néha becsinálok azon amit az AMD mond. Ez a majd ''45nm-en lesz gazdaságos'' dolog is egy kicsit fura. Meg az is hogy a Brisbane magos processzorok gyorsítótára azért lassabb mert így majd nagyobbat lehet gyártni. Na jó, de melyik Brisbane magos prociba tudom utólag belerakni a nagyobb gyorsítótárat? Gondolom a 65nm-es processzorhoz meg majd zsugorítót fognak árusítani...
Az hogy egy vezérlés egyszerűbb vagy bonyolultabb, nem lényeges a számunkra ha ugyanazt a teljesítményt nyújtja. Viszont ami egyszerűbb, azt könnyebb fejleszteni. -
#95904256
törölt tag
Kicsit off-topic leszek, de találtam egy X-bit labs tesztet az AMD 4x4 és az Intel V8 platformok összehasonlításáról: [link]
-
#95904256
törölt tag
Egyelőre csak találgathatunk a harmadszintű gyorsítótárral kapcsolatban. Ha azt veszem figyelembe hogy a K10 felépítése erősen hasonlít a K8-éra, ami nem volt különösebben érzékeny a L2 cache méretére, valamint az L3 várhatóan lassabb hozzáférést biztosít mint az L2, akkor azt mondhatnám hogy nem okozhat jelentős lassulást a hiánya. Ha azonban megnézzük hogy az L2 mérete a K10-nél is csak 512kB magonként, ráadásul ezek a magok éhesebbek ( gyorsabb működés, szélesebb adatutak ), akkor igenis nagy szükség lehet az L3-ra...
-
#95904256
törölt tag
Nem ma kezdődött a Computex? Sőt, ha jól sejtem akkor már javában AMD Barcelona demók mennek... Mit hallani???
-
#95904256
törölt tag
Megtudnátok mondani hogy az SSE2-es regisztereknél az FPU-n belül is csak 52 bites a mantissza vagy nagyobb a kerekítések miatt? Ha nagyobb akkor melyik CPU-nál mennyivel? Vagy erre is kitér az IEEE754 vagy egyéb standard?
-
#95904256
törölt tag
válasz VaniliásRönk #802 üzenetére
Ha nem így lenne akkor most egyik AMD prociban sem lenne SSE utasításkészlet.
-
#95904256
törölt tag
válasz VaniliásRönk #804 üzenetére
A 3DNow!-hoz annyit hozzátennék hogy még nem pusztult ki. Sőt ugyanaz az algoritmus 3DNow!-ra optimalizáltan legalább olyan gyorsan fut a jelenleg kapható AMD processzorokon mintha SSE-re lenne optimalizálva. Ráadásul a reciprokszámítás még egy bittel pontosabb is... ;-)
-
#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... -
#95904256
törölt tag
Ismerős dokumentáció. A végrehajtási időket nézegetve valóban úgy tűnik hogy az 1 darab 128 bites SSE művelet ( amit a processzor 2 darab 64 bites műveletként hajt végre ) azonos futásidőt produkál 2 darab különálló 64 bites 3DNow! művelettel. Azonban a 3DNow! kód ( ahol már program szinten két önálló utasítás van ) mérhetően gyorsabban fut le. A különbség nem drasztikus, csak néhány százalék.
Utána néztem a dokumentációkban reciprokos dolognak is.
3DNow! PFRCP pontossága: 14 bit
( AMD 21928 3DNow! Technology Manual )
Bár nekem néha csak 13 bites pontosságot sikerült kimérnem.
SSE RCPPS/RCPSS pontossága: |relativ.hiba| < 1,5*2^-12
( Intel 25366718 IA-32 Instruction Set )
Ez meg bizony csak 11-12 bitnyi pontosságot garantál.
Megjegyzés: Az AMD processzorok SSE reciprokképzés estén NEM a 3DNow! pontosságot hozzák. -
#95904256
törölt tag
A Transmeta mostanában abból él hogy a Longrun2 technológiáját és egyébb ''energy-efficient'' megoldásokat próbál eladni. Ha jól tudom akkor az Efficeon processzort megvették tőle és még gyártják valahol Tajvan környékén, különféle beágyazott rendszerekhez. A Linux guru Linus Torvalds-tól meg békében elváltak, miután éveken keresztül 100 millió dolláros veszteségeket produkált a cég. Azóta talán nyereségesek, de valami minimális árbevétellel.
szerk: A honlapjukon olyasmi szerepel hogy a cég vagyona kb. 26 millió dollár és folytatják az adóság törlesztését...
[Szerkesztve] -
#95904256
törölt tag
Múltkor említettétek hogy sikerült az AMD-nek majd 500MHz-zel növelni a K10-es magok frekvenciáit. Szerintem ez összefüggésben lehet a CPU és a memórivazérlő feszültség ellátásának szétbontásával. Lehet hogy ez okoz némi csúszást a megjelenésben? Gondolom az AMD erősen érdekelt abban hogy kifogástalan, mindent legyűrő processzor kerüljön piacra, különben nem fogja tudni visszaszerezni az elmúlt hónapokban elvesztett piaci részesedését.
-
#95904256
törölt tag
Reciprok letesztelve, tessék megkapaszkodni !!!
Teszthez használt CPU-k:
AMD X2 3600+ Windsor (1800@2400MHz)
Intel E4300 Allendale (1800@3200MHz)
Mérés:
31 bites prímszámok reciprokképzése
AMD 3DNow!, PFRCP 32 bit <-> FIDIV 80 bit
AMD SSE, RCPSS 32 bit <-> FIDIV 80 bit
Intel SSE, RCPSS 32 bit <-> FIDIV 80 bit
Mérés beállítások:
FPU, SSE: Kerekítés a legközelebbi egészhez, egyenlőség esetén pároshoz.
FPU: extended ( 80 bites ) pontosság
Eredmény:
Az esetek túlnyomó többségében mindhárom eredmény eltér egymástól.
Példa:
IEEE734 formátumú reciprok eredmények n=3 -ra.
AMD 3DNow!: 3EAAAA00 ( = 0,33332825 )
AMD SSE: 3EAAA800 ( = 0,3331299 )
Intel SSE: 3EAAA000 ( = 0,33325195 )
Hogy mindhárom eredmény eltért, nos ez erősen meglepett. Ezért a keresést kiterjesztettem az összes 31 bites pozitív egész számra. Ekkor jött a még nagyobb meglepetés, ugyanis a legnagyobb hibát az n=1 eset produkálta!
Maximális eltérések:
AMD 3DNow! : 0,00003051758 ( hiba = 1/32767 -> épp nincs meg a 14 bit )
AMD SSE: 0,000244140625 ( hiba = 2 ^ -12 -> 11 bit mindig jó)
Intel SSE: 0,000244140625 ( hiba = 2 ^ -12 -> 11 bit mindig jó)
Megjegyzés:
Az AMD SSE eredmények mikor eltértek az Intel eredményektől, mindig pontosabbak voltak.
Szerk.: A Newton-Raphson iteráció használható SSE esetén is, csak akkor manuálisan kell leprogramozni. Nem igényel több regisztert, csak eggyel több memória műveletet. Xb=Xa*(2-N*Xa), ahol Xa az N reciprok közelítő értéke. Ez egy körben megduplázza a hasznos bitek számát. Ami azt jelenti hogy az SSE 11 bites pontosságát nem lehet egy körben 24 bites mantissza méretre ( single precision ) interpolálni.
[Szerkesztve] -
#95904256
törölt tag
Valószínű hogy az Intel is look-up ol, csak spórolósabban. A 14 bites mantisszához elég egy 16kB-os ROM, illetve a kitevőhöz kell még egy 128 bájtos. Az SSE esetén elég 4kB/128. Egy iterátor áramkörnek legalább 1-2 szorzásra lenne szüksége, ami még ha egy ciklusos is ( 12 bites szorzó ) nem lenne gyorsabb a ROM-os megoldásnál, valamint helyet sem spórolna.
Az AMD illetve Intel eredmények közti különbség is a look-up tábla méretéből adódhat. Az RCPxS-nél a mantissza 24 bitjéből az alsó 12-ő törlődik, viszont az AMD-nek megvan a lehetősége hogy az utolsó megmaradó bitet kerekítse.
Ú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.
- Amlogic S905, S912 processzoros készülékek
- Milyen légkondit a lakásba?
- Sorozatok
- Anime filmek és sorozatok
- Projektor topic
- 3D nyomtatás
- ubyegon2: Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- Azonnali processzoros kérdések órája
- Motorola Edge 30 Neo - wake up, Jr...
- Samsung Galaxy S21 FE 5G - utóirat
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest