- Friss koncepciót hoz a Nothing Phone (3)
- Xiaomi 15 - kicsi telefon nagy energiával
- 200 megapixeles zoomkamerát sem kap az S26 Ultra?
- Samsung Galaxy Watch7 - kötelező kör
- One mobilszolgáltatások
- Nothing Phone (3a) és (3a) Pro - az ügyes meg sasszemű
- Samsung Galaxy S23 Ultra - non plus ultra
- Android alkalmazások - szoftver kibeszélő topik
- Xiaomi 13 - felnőni nehéz
- Motorola Edge 60 és Edge 60 Pro - és a vas?
-
Mobilarena
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
7600GT
senior tag
Köcike, de azért azt is beleszámolnám h az első hónapokban elég drágák ezek a procik sok az inkompatibilitás meg driver hiány meg anyámkínnya. Mert ha az lenne h megjelenik Q3-ban és minden azonnal fasza és mindenhez vagy minden és az ára is elérhető akkor várok csak így nemtom h érdemes-e mert azért egy 3.2GHz-s core sztem késöbb is ütni fog.
-
Raymond
titán
Arstechnica (3. es 4. oldal):
[link]
A fent linkelt Anandtech-es cikk hozzaszolasaibol:
[link]
''Core can do two SSE operations per cycle (the two symmetric units), giving it a total of 4 DP FLOPs per cycle. The third SSE unit does not handle FP ops, but instead handles shuffles and the like. ''
Erdekes hogy pont a Realworldtech-es cikk lenne a legkevesbe pontos de ugy nez ki ez van. Mert idealisabb teszt mint a Sandra-s nincs erre es az pedig igazolja a ket 128bit-es vagy negy 64bit-es operacio/mag/orajel elmeleteket. -
-
Dare2Live
félisten
-
P.H.
senior tag
A 64 bit vs x87/MMX/3DNow!-hoz annyit, hogy az ominózus kijelentés a linkelt AMD-oldalon szerepel mindkét K8 Software Optimization Guide-ban, és ebben a K10 Guide-ban is az x87 Floating-Point Optimizations fejezet elején, mégis a fejezet további részeiben az egyes tanácsoknál szerepel, hogy:
This optimization applies to:
•32-bit software
•64-bit software
Azzal meg teljesen egyetértek, hogy x87/MMX/3DNow!-nak nincs helye kernel mode kódban. Nem volt egyszerű rájönni, hogy hogyan lehet elkerülni a Windows API egyes korábbi verzióinak (9x és NT egyaránt) ilyen szintű hülyeségeit, hogy pl. egy GlobalAlloc meghívása után nem azt találom az FPU-register-ekben, mint hívás előtt, vagy hogy a window procedure nem üres FPU-stack-et kap (fsave és fninit a kötelező kezdés, frstor a kötelező befejezés).
Nem idevágó, de az meg egyenesen kiakasztó, hogy beállított DF-fel (std után) meghívott GMEM_ZEROINIT GlobalAlloc valamelyik 9x - talán W95 alatt - egyszerűen leállt védelmi hibával...
[Szerkesztve] -
#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
É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 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. -
dezz
nagyúr
3) Na, hát ezért nem hiszem, hogy az FX-nek alacsonyabban lenne a vége, mint a sima Agenának. De ha hozzáadjuk a ''2.4-2.6''-ból az alsóhoz azt a 0.5-öt, akkor is ott vagyunk a 2.9-nél. Szóval ez a Chen sem tud számolni.
akosf: ha jól vettem ki, maga az x87 egyelőre még megmarad, csak a régi regjeit veszti el.
[Szerkesztve] -
#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] -
dezz
nagyúr
1) Ez vili.
2) Bennem is felmerült, de szerintem ez nem azért 2.2 eredetileg, mert nem bírna többet, hanem mert egy középkat. procinak szánják.
Nyitott marad a kérdés, mennyit bír(na) a Kuma, ha az is többet bír? (TDP ugye mehet 120 v. 130W-ig.)
3) Hmm, az FX-eknek számottevően magasabb lenne a TDP-je, mint a megfelelő sima Agenának? De van is ott egy olyan, hogy 2.4-2.6 s.F+. +500 MHz = 2.9, szintén. (Persze lehet, hogy ez már neki ''sok'' volt.
)
#454: hát jó, de az sem ártana, ha az 1x64 bites SSE(2+) műveletek is szélesebb superscalarban hajtódhatnának végre, így a nem-vektoros kód is gyorsabb lenne.
[Szerkesztve] -
dezz
nagyúr
Az is egy ötlet volt, de a fontosabb a 4db független 64 bites x87 művelet lett volna egy időben (ha jól sejtem, most 2-t tud), amennyiben 4db 64 bites egység lenne, nem pedig 2db 128 bites. (Meg volt még ott egy kérdés a 2 vs. 1 ciklusos ütemezésről, ami némileg ugyanide kapcsolódik.)
-
dezz
nagyúr
''Csak annyit hogy gyakorlatilag a komplett x87 pipeline hianyzik a keprol.''
Izé, és ez min változtatna? Így se, úgy se mehet függetlenül az egységek 2 64 bites fele, legalábbis sima FPU (x87) kóddal, szélesítve a superscalar végrehajtást.
''Az SSE+FADD es SSE+FMUL egy-egy egyseg a ket-ket feladatra (x87 es SSE). Lasd itt: [link]''
Ja, köszi, így már világos. (Szal az FMUL, FADD x86 és SSE2+ kódhoz is ''jó'', az SSE meg főleg SSE(1) műveletekre.) -
P.H.
senior tag
Ha a 64bit SSE utasítások alatt a skalár SSEx FP-t érted, akkor azon a téren nem változott semmi. Sőt, a vektortéren kimondott kétszeres gyorsulás is idézőjeles egy picit. Összevetettem a K8-at és a K10-et (ezeket az értékeket használom port-optimalizációnál is programozáskor):
K8 esetében:
- ADDPD és ADDPS (2x64 vagy 4x32 bit): 5 órajel alatt, 2 órajelenként 1-et indítva
- ADDSD és ADDSS (1x64 vagy 1x32 bit): 4 órajel alatt, 1 órajelenként 1-et indítva
- FADD (32, 64 vagy 80 bit x87): 4 órajel alatt, 1 órajelenként 1-et indítva
- MULPD és MULPS (2x64 vagy 4x32 bit): 5 órajel alatt, 2 órajelenként 1-et indítva
- MULSD és MULSS (1x64 vagy 1x32 bit): 4 órajel alatt, 1 órajelenként 1-et indítva
- FMUL (32, 64 vagy 80 bit x87): 4 órajel alatt, órajelenként 1-et indítva
K10 esetében:
- ADDPD és ADDPS (2x64 vagy 4x32 bit): 4 órajel alatt, 1 órajelenként 1-et indítva
- ADDSD és ADDSS (1x64 vagy 1x32 bit): 4 órajel alatt, 1 órajelenként 1-et indítva
- FADD (32, 64 vagy 80 bit x87): 4 órajel alatt, 1 órajelenként 1-et indítva
- MULPD és MULPS (2x64 vagy 4x32 bit): 4 órajel alatt, 1 órajelenként 1-et indítva
- MULSD és MULSS (1x64 vagy 1x32 bit): 4 órajel alatt, 1 órajelenként 1-et indítva
- FMUL (32, 64 vagy 80 bit x87): 4 órajel alatt, órajelenként 1-et indítva
Eddig vektoros SSE-nél 2 micro-op-ra fordult az utasítás, amik egymási órajelekben léptek be a pipe-ba (DirectPath Double és 2 órajelenkénti programutasítás-szintű indítás) és az alsó 64 bites fél már a 4. órajel után elérhető volt. (Note: The low half of the result is available one cycle earlier than listed.). Most a decode és a port-issue sávszélesség lett kétszeres.
Ami jelentősebb változás, hogy egyidőben 2 helyett 3 MOVAPS/MOVAPD (128 bites adatmozgatás) indulhat el, a 128 bites logikai műveleteket az FADD is végezheti már az FMUL mellett, és csökkent a latency-jük is, valamint a shuffle utasítások végre nem VectorPath-on fordulnak, és az FADD is végezheti őket. Sőt, úgy néz ki, hogy minden, eddig FMUL általá végzett nem szorzásjellegű műveletet megkaphat az FADD pipe is.
dezz:
Az lebegőpontos algoritmusok ugyanazok maradtak, csak megduplázták a számoló egységek számát. Az FADD és az FMUL pipe így változott szélességében (az MMX-hez szükséges 8 és 16 bites egységeket nem sorolom):
- 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
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.
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.
[Szerkesztve] -
dezz
nagyúr
''80bit-es FP osidok ota van x87-ben.
Aham, értem, oké.
Viszont itt ez a 64 bit/128 bit dolog elvileg csak az SSE-re vonatkozik, ami viszont nem tud ilyet, és tudtommal annak külön regiszterei vannak (64/128 bitesek). (Ezt a korábban erről elhangzottakkal kapcsolatban jegyzem meg.)
Az x87 FPU kód tehát elvileg nem gyorsabb, viszont valahol írják a doksiban (vagy a GDC2007-esben), hogy ha SSE-s kódra fordítunk, ekkor persze egy operandussal, akkor 64 bit esetén 2x-esére, 128 bit esetén 4x-esére gyorsul a végrehajtás. (Mondjuk x87-en nincs is 128 bites operandus, de gondolom, úgy értették, ahhoz képest, mintha 64 bites műveletekből raknánk össze.)
[Szerkesztve] -
dezz
nagyúr
Hú, ez micsoda egy oldal...
Remélem, a K10-zel is foglalkoznak majd egy kicsit.
Még egy szó a cache-kerülésről: végülis mindig átmegy rajtuk (már ami a logikai blokkjukat illeti) az adat, tehát rákerül a bemeneti vonalaikra, csak beíródás/kiolvasódás nélkül rögtön rákerül a kimeneti vonalakra is. (Ami az elektronikai megvalósítást illeti.)
Ja, meg a #424-ben kimaradt: '' ''Egyébként szerintem x86-on nincs extended prec. FP.''
'' -- A 80 bites fp-t hívják extended precisionnek, amiről úgy tudom, nincs x86-on.
Egyébként én úgy tudom, csak az SSE(2-3) lett egyidejű 128 bites, az FPU nem sokat változott. Vagy mégis?
[Szerkesztve] -
P.H.
senior tag
Thx, ezzel még nem találkoztam.
A sejtésem onnan származott, hogy K7 óta azoknak az utasításoknak, amik az XMM-register-eknek csak egyik 64 bites (vagy alsó vagy felső) felén dolgoznak, az Intel CPU-khoz képest igen kis késleltetésük van, és DirectPath-on (nem is Double-on) keresztül dekódolódnak (viszont a 80 bit-es x87-adatoknak jó lenne egy egységnek lennie). Intel-eknek ilyen esetekben mindig kell egy plusz MMX_SHIFT micro-op is. -
dezz
nagyúr
Mint az előzőből láthatod, már megtettem.
Meg megnéztem a forrást is.
(Még szerencse, hogy több, mint 5 perccel utánam írtál, még egyesek azt gondolnák a szerkesztés miatt, hogy utánad rittyentettem össze a szöveget, volt már rá legalábbis egy eset. Mármint hogy rám fogták. )
#429: igen, ezt a részt dobtam be a Babelfish szájába, mert sajnos a német nem az erősségem.
[Szerkesztve] -
dezz
nagyúr
Átnéztem, de egyelőre nem találtam magyarázatot a következőre.
Van itt egy ilyen: AMD Talks Details on K10 [link]
Van benne egy ilyen rész:
''K10 will introduce a shared L3 cache while the individual cores have dedicated L1 and L2 caches. As long as requested data lies in L1, it can be directly loaded. This also works if the data lies in the L1 cache of another core, in which case the communication works via the crossbar switch.''
Van valami elképzelésed, miért és hogyan mehet ez a crossbar-on, amikor az elvileg a L3 ''alatt'' van (memóriához közelebb), és nem magán a L3-on keresztül, ami shared a magok között? -
mcwolf79
veterán
''AMD predicts slow transition to K8L
by Justin Mann on February 22, 2007, 6:04 PM | (5)
In a bit of sad news for AMD fans, Hector Ruiz, Chief Executive for the company, has stated that K8L will not take off this year. K8L is the future answer to Core, and represents a significant change in architecture that could vastly improve the performance of AMD processors. That is something sorely needed right now, with the Core and its variants again and again winning the performance battle. However, AMD instead will continue to push their existing architecture for a while yet.
That doesn't mean they aren't going ahead with their plans for launches – just that propagation and adoption aren't going to be anything impressive. AMD is estimating it will be around 9 months to transition their desktop products to the new technology, whereas with Intel it was around 6 months to transition to Core. Given the blazing success of the Core as it stands and these figures, it could easily be early 2008 before we see them make a comeback.''
Most nincs időm fordítani,meló van ezerrel.
CIAO
)
Remélem, a K10-zel is foglalkoznak majd egy kicsit.
'' -- A 80 bites fp-t hívják extended precisionnek, amiről úgy tudom, nincs x86-on.
Ú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.
- Friss koncepciót hoz a Nothing Phone (3)
- ASZTALI GÉP / ALKATRÉSZ beárazás
- Eredeti játékok OFF topik
- Xiaomi 15 - kicsi telefon nagy energiával
- Külföldi rendelések: boltok, fizetés, postázás
- Windows 10
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Linux kezdőknek
- 200 megapixeles zoomkamerát sem kap az S26 Ultra?
- Kerékpárosok, bringások ide!
- További aktív témák...
- Intel Core i9-14900KF 24-Core 3.2GHz LGA1700 Box (BX8071514900KF) Processzor! BeszámítOK
- Ritkaság! Csere-Beszámítás! Intel I9 13900KS Processzor!
- Ryzen 7 8700G /// Új, csak kipróbált // Számlával és Garanciával!
- AMD Ryzen 7 5700X3D - BOX - Új, 3 év garancia - Eladó!
- Intel ES Core i5-3470 4-Core 3.2GHz LGA1155
- Telefon felvásárlás!! Samsung Galaxy A22/Samsung Galaxy A23/Samsung Galaxy A25/Samsung Galaxy A05s
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7700X 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Eladó szép állapotban levő Apple iPhone 8 64GB fekete / ÚJ KIJELZŐ / ÚJ AKKU / 12 hónap jótállás
- ÁRGARANCIA! Épített KomPhone Ryzen 5 7600X 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- ÁRGARANCIA!Épített KomPhone i5 14600KF 32/64GB RAM RTX 5060 Ti 16GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest