- A Watch7-tel debütálhat a Samsung vércukormérője
- Fotók, videók mobillal
- iPhone topik
- Garmin Forerunner 165 - alapozó edzés
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Telekom mobilszolgáltatások
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Bemutatkozott a Redmi új szériája
- Oppo Find X5 Pro - megtalálták
- Bluetooth-headsetekről általában
Hirdetés
-
Rövid előzetesen a S.T.A.L.K.E.R. 2: Heart of Chornobyl
gp Továbbra is szeptemberi premierrel számolnak a fejlesztők, reméljük több halasztásra már nem kell számítanunk.
-
Lenovo Essential Wireless Combo
lo Lehet-e egy billentyűzet karcsú, elegáns és különleges? A Lenovo bebizonyította, hogy igen, de bosszantó is :)
-
Ülésezik a hardveregylet
ph Az irodai készülékek és monitorok társaságát egy ház, egy egér és egy DAC egészíti ki.
-
Mobilarena
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
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.
CIAOXbox Series X GT: Mcwolf79xy PSN ID: x_mcwolf_79_x
-
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? -
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] -
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.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
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] -
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] -
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]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
''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.) -
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
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] -
#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
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
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
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] -
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]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
Dare2Live
nagyúr
Nagyon kevésszer fordult ilyen elő a PH!forumok történelmében, hogy huzamos ideig ennyire szakmai társalgás menjen.
engem is külön örömmel tölt el, csak mivel évek óta nemmozgat mega téma max vonalakban értem azt amiröl beszéltek. (Félre ne érts ettöl még hajrá!)don't look up, don't look up, don't look up, don't look up, don't look up, don't look up, don't look up...
-
-
Raymond
félisten
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.Privat velemeny - keretik nem megkovezni...
-
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.
Ha az ember féreggé teszi saját magát, ne csodálkozzon, ha rátaposnak.
-
P.H.
senior tag
-
Rive
veterán
Leginkább kapacitásra. Mondjuk egy per-thread dedikált L1Dcache/ICache jó - és: durva - lenne
Itt=IMC.
Ui.: az a gond, hogy igazából semmi olyat nem látok, ami indokolná a K8 -> K10 nevezékváltást SZVSZ csalódás lesz a cucc, ha nem jön be még valami a képbe.
[Szerkesztve]/// Nekünk nem Mohács, de Hofi kell! /// Szíriusziak menjetek haza!!!
-
#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? -
P.H.
senior tag
Csúsztatások egy bizonyos szint alatt nem szoktak lenni, csak mese, mese vég nélkül (mint az intelligens mosópor... legiknkább a könnyebb megérthetőség miatt, mondjuk a CPU azért elég intelligens dolog) Sokszor jó, ha az ember megpróbálja lehozni ezeket a meséket is tranzisztor-szintre.
[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
Hmm, Core2 esetén fel van tüntetve egy bizonyos Internal Results Bus, a K10 esetén az ilyesmi hiányzik az ábrákról.
A végkövetkeztetésekben meg egy szó sem esik a natív 4-magosság mellett a másik legfontosabb változás, a kiemelkedő floating-point (SIMD) teljesítmény mind desktop, mind munkaállomás, mind szerver vonalon jelentette előnyről.
(#611) 7600GT: nemrég még ''lázadtál'' a technikai szöveg ellen, most meg egyenesen igényedet fejezed ki? Bár nem tudom, vállalkozik-e Raymond egy 10 oldalas, tömény technikai szöveg pár mondatba sűrítésére. -
P.H.
senior tag
Nagyon jó cikk, minimális háttérismeretek birtokában érthető (= ha tudja az ember, hogy miről beszél, akkor tudja azt is, hogy mit mond). Egy kicsit zavaró, hogy micro-opokban fogalmaz macro-opok helyett.
dezz #617: K10 esetében is van result bus (írja is, hogy nem ábrázolja, mert túl bonyolult lenne az ábra tőle), result bus nélkül az egész működésképtelen lenne (INT oldalon nincs is register-rename, csak resultbus->ROB/ICU forwarding, legalább K7 óta).
dezz #619: Sajnos az Intel visszatért a PPRO/P2/P3 complex-simple-simple... (itt most még egy -simple, 4-1-1-1 micro-op) decoder felállásához. Valahogy mindig RISC-felfogású decoder-eket akarnak tenni egy x86 elejére P6 óta (Netburst alatt az egyszem decoder szűkösségét elnyomta a trace-cache), pedig pont oda kellene CISC-felfogás. Ezek szerint három egymást követő OP reg,mem típusú utasítást Core2 3, K10 1, (de még ha nem DirectPath Double útra mennének, akkor is) legrosszabb esetben 2 órajel alatt fordítaná. Itt is van egy szűk keresztmetszete, illetve a mem tagokat Core2 1/órajel (cache lehet, hogy dual-ported, de LOAD - port2- csak egy van), K10 2/órajel szélességben hozza fel Data Cache-ből legjobb esetben, akár 2x128 bitet.
akosf #619: üresben ugyan nem járnak, de nem biztos, hogy FP munkát végeznek, lévén shared INT/FPU pipe-ok (számláló, forrás- és célcímek kezelése, branch futtatása, stb...)
Pont a macro-op cache-t említettem korábban is, a fetch/decode itt majd' a pipe felét viszi el, nem csak 2-3 órajelet/stage-t. A másik ötletem, a Hyper-Threading azért játszhatna itt, mert mostmár teljesen tiszta, hogy a pack-stage-ek után nincs vízszintes mozgás a macro-ophármasokban, minden utasítás arra a portra megy, amelyik lane-en van, főleg FPU-ban teli van gap-ekkel. Ezeket tölthetné meg másik szál, INT esetén pedig az 3 micro-op/cycle miatt nem nehezedne nagyobb nyomás (INT-ben sokkal nagyobb gondot okoznak a függőségek, mint a szélesség). A branch-ágak práhuzamos futtatása sajnos nem, megintcsak amiatt, mert nincs INT oldalon register-rename.
dezz #622: 3+2+2+2-t nem tudok kiolvasni az Optimization Guide-ból, csak 3/2+2+2-t. Mivel végig 3-széles maradt a micro-architecture (3 macro-op/sor), szerintem nincs 4 decoder, a VectorPath csak ábrázolásszinten külön oszlop (vagy a 3 DirectPath, vagy VectorPath).
akosf #623: érdekes módon az FSTORE-t az idők folyamán átnevezték FMISC-re. Mindenesetre ennek van belső ROM-táblája a betölthető konstansokhoz, ez kezeli az INT->FP és FP->INT konverziókat (fild, fist(p)), és ahogy mondod, az FSIN, FCOS, ... utasítások által generált spec. micro-opokat futtatja (lehet, hogy csak ez fér hozzá a belső, programozói szinten nem látható átmeneti (scratchpad) register-ekhez?)
IPC: majdnem mondtam, hogy próbálj egy átlapolt, nem függő FPU/INT utasítássort, de azt meg a decode limitálja 3-ra.
dezz #624: azért majd meglátjuk, 65 nm-en meddig fogják felvinni az órajelet, mennyi tartalék van benne.
akosf #625: felfüggesztődik? Nem hiszem el...
SMC: egy (a? ) másik topikban zajló események miatt pár napja multi-core/multi-processor/NUMA témába ástam bele magam. SMC természetesen lehetséges (még mindig 8086 miatt, de már nem sokáig lesz ez így), AMD-nél a MOESI-szerinti cache-probe módosítás esetén kiüríti az I-cache adott vonalát (store-jellegű probe esetén az I-cache-t is ellenőrzi system-wide), és érvényteleníti a teljes CPU-pipe-ot. Ha jól emlékszem, Netburst alatt nyomta ki a teljes instruction cache-t egy SMC.
dezz #628: DirectPath-on mennek egy 1 micro-opos utasítások (3 micro-op/órajel), DirectPath Double-re a 2 micro-oposok (1.5 micro-op/órajel, lényegében ugyanaz, mint a DirectPath Single, csak 2 órajel alatt fordít), VectorPath-ra a többi. Csak ennyi a szabály.
akosf #629: OP reg,mem már 2 micro-op Intel-nél. Most hivatkoznék megint a fenti IDCT-kódomra, sokszor elemi utasításoknál sem férnek el a konstans-ok a 8(/16) XMM-registerbe.
Igen, kb. annak felel meg, aminek leírtad. Csak AMD esetében van DirectPath Double, és sokkal több minden fér bele valamelyik DirectPath-ba, K10 esetén meg már főleg).
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.
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
Nagyon egy dologra gondoltunk. +[link]
Nemrég néztem, egx 2000 CPU ára 2-30 dollár környékén van, egy 8xxx CPU-é $2000 felett...
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
P.H.
senior tag
Hogyan tudod párhuzamosítani több utasítás elejének és végének meghatározását, ha változó hosszú utasításokról van szó? Meg kell taláni az opcode byte-ot (byte-okat, mert 486/MMX/SSEx esetén a 0Fh prefix is ott van, 3DNow4 esetén kétszer is - 0F0Fop ), - és még szó sem esett még az REPZ, REPNZ, argumentum- , vagy címhossz-befolyásoló prefixek-ről, amik SSEx - x >=2 - esetében válnak fontos tényezővé- , a ModR/M által leírt címhez tartozó azonnali érték, a SIB-byte-ot, és az adathoz tartozó azonnal érték hosszát. (és ezek is 1/2/4/8 byte hosszúak, prefixről változóan).
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
ftc
nagyúr
megvan az uj háttérképem
mit nem adnák azért ha már egy ilyen dobogna gépem belsejében...sztem Barcelona bemutató a jelnlegi Computexen...
azt ah beszereztem egy ilyet átkéne állni Vistára,vagy Linuxra...de sajna a szi,ulácio csak winen futnak...meggyorsitaná a számolást a 4 mag... -
dezz
nagyúr
-
sharKBITE
aktív tag
Ez annyira szép... de tényleg. Remélem legalább annyira bejön majd AMD-nek a Phenom, hogy kilábalnak a mostani helyzetükből, és újra odapörkölnek kicsit Intel bácsiék orra alá. De a topicos fejtegetések alapján úgy néz ki, hogy tényleg újra nyeregben lehetnek ha megjelennek a K10-ek. Mellesleg kész öröm olvasni a topicot, még akkor is, ha csak a negyedét értem a részletekbe menő fejtegetéseknek. Csak így tovább!
-
-
dezz
nagyúr
Lauch event vagy sem, azért demózták a cuccot az új Opteron 2200 személyében: [link]
Ennek a csúszásnak a forrása talán csak a DigiTimes, amely ide vonatkozó hírének hitelességét sokan megkérdőjelezték.
Tudom, a Fudzilla kicsit más súlycsoport, mint ez, vagy akár az Anandtech, mindenesetre ők kicsit mást írnak erről: [link]
Mondjuk kicsit alacsony annak a 2200-asnak az órajele (1.6 GHz), vélhetően ha lenne nagyobb, azt mutogatnák. Ha igaz a csúszás, talán ezzel függ össze...
[Szerkesztve]
Ú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 billentyűzetet vegyek?
- Adatmentés - HDD - SSD - Flash
- Milyen NAS-t vegyek?
- A Watch7-tel debütálhat a Samsung vércukormérője
- Kerékpárosok, bringások ide!
- Magga: PLEX: multimédia az egész lakásban
- Házimozi belépő szinten
- PlayStation 5
- LG 34GS95QE-B: OLED paneles, ívelt gamer monitor
- További aktív témák...
- i3 8100/ ingyen automata
- Beszámítás! Intel Core i7 6700K 4 mag 8 szál processzor garanciával hibátlan működéssel
- BESZÁMÍTÁS! ÚJ Intel Core i5 11400F / i9 11900KF / i9 11900K tálcás processzorok 27% áfás számlával
- Beszámítás! Intel Core i5 6500 4 mag 4 szál processzor garanciával hibátlan működéssel
- Beszámítás! Intel Core i3 10105 4 mag 8 szál processzor garanciával hibátlan működéssel