- Igencsak szerény méretekkel rendelkezik az Aetina Xe HPG architektúrás VGA-ja
- Miniképernyős, VIA-s Epomaker billentyűzet jött a kábelmentes szegmensbe
- Különösen rendezett beltér hozható össze a Cooler Master új házában
- A középkorra és a pokolra is gondolt az új AMD Software
- Új gyártástechnológiai útitervvel állt elő a TSMC
Hirdetés
-
Igencsak szerény méretekkel rendelkezik az Aetina Xe HPG architektúrás VGA-ja
ph Az 50 wattos modellt beágyazott rendszerekbe, MI-vel kapcsolatos munkafolyamatokhoz és edge applikációkhoz szánták.
-
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...
-
Olcsó 5G-s ajánlatot nyújt a Realme Indiának
ma Megérkezett a Realme C65 5G, az első készülék a MediaTek Dimensity 6300-zal.
-
PROHARDVER!
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
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.)
-
Raymond
félisten
Charlie a szokasos szerencsetlen forma helyett inkabb az informaciotartalomra koncenralodhatott volna.
''So what do you end up with? A massive gain in frequency. How massive? Almost 500MHz. Instead of the much touted launch parts, look for five SKUs at launch, AM2 quads at 2.6GHz, 2.7GHz and 2.9GHz, a dual at 2.7GHz and a quad on socket F at 2.8GHz.''
Referencia tablazat:
[link]
The Inq szoveg ekodolva
1) ''AM2 quads at 2.6GHz, 2.7GHz and 2.9GHz'' = Phenom X4 = 2.4Ghz + 500Mhz = 2.9Ghz
2) ''a dual at 2.7GHz'' = Athlon 64 X2 = 2.2Ghz + 500Mhz = 2.7Ghz
3) ''a quad on socket F at 2.8GHz'' = Ezt a Phenom FX-bol silabizalta ki valahogy de nem tudott fix erteket irni mert meg kerdeses lehet a TDP miatt.
SZVSZ a 2. pontnal azert nem a Phenom X2-t vette mert ott mar eleve van 2.8Ghz valtozat.Privat velemeny - keretik nem megkovezni...
-
aktív tag
Hát meglátjuk, amikor ténylegesen bejelentik (esetleg megbízhatóbb forrásból) vagy kaphatóak lesznek a szépségek
De nekem tetszene, ha alapból 2,9Ghz körül indulna a buli. Abban bizta lenne ''kráft''
Bár ahogyan néztem a hozzászólásokat nem nagyon kell félni, hogy rosz lesz a k10. -
Raymond
félisten
Az x87-nel nem nehezedik rajuk semmi nyomas. Meg mindig lenyomjak bermelyik masik x87 CPU-t a piacon. Nem volt ertelme ebbe sok penzt es energiat olni. Kulonosen hogy az x87 szorul ki a piacrol. Az MS OS-ek alatt a nativ 64bit-es aplikacioknak mar nincs hozzaferesuk az x87, MMX es 3DNow! registerekhez. Csak az SSE-k elerhetok.
Privat velemeny - keretik nem megkovezni...
-
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] -
Dare2Live
nagyúr
-
#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
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, ... ) -
Raymond
félisten
-
dezz
nagyúr
válasz #95904256 #465 üzenetére
Nem tudom, én csak Rajmond hozzászólása alapján mondtam.
(Az ugyancsak Rajmond által linkelt (#445) mag-részegység azonosítási képek, és P.H. #437-es hsz-ének alsó részén írottak alapján itt már nincs is olyan, hogy külön FPU egyég, hanem ugyanazokat az egyégeket használják, sőt ugyanarra a micro-op-ra fordítódik át.) -
#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. -
Oliverda
félisten
Conan a barbár: [link]
"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."
-
-
Raymond
félisten
válasz #95904256 #469 üzenetére
Tul fogom elni
Persze hogy ott vannak 64bit-es Windows alatt, a 32bit-es alkalmazasok hogy mukodnenek nelkuluk? A nativ 64bit-es alkalmazasokrol volt szo, ahol teljesen le akartak tiltani a hasznalatot. Az igazsag az hogy az egeszbol annyi maradt a vegere hogy kernel mode kodban tilos a hasznalata es mindenki (MS, AMD, Intel) evek ota lebeszeli a embereket a hasznalatukor es az SSE fele nyomjak oket.Privat velemeny - keretik nem megkovezni...
-
#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. -
Raymond
félisten
válasz #95904256 #473 üzenetére
Nem kell egyelore eloasnod
[link]
Itt a kernel mode info. Az egesz tiltasbol mara ennyi maradt. Az MS OS es VS megjeleneseig nyitott maradt hogy mi lesz a helyzet. Linux alatt nincs es nem is volt semmilyen lekotes. Ez csak az MS jateka volt. De az AMD64 (IA64) hasznalatanal az AMD es az Intel ajanlasa most is az SSE hasznalata. Egy pelda: [link]Privat velemeny - keretik nem megkovezni...
-
P.H.
senior tag
dezz #439: ''Miért nem jön ki a 2x-es sebesség,...?''
Számoljunk utána: K8-on mondjuk 5 egymást követő, független ADDPS/ADDPD utasítás így fut le: 0->4 (0. órajelben indul, negyedikben fejeződik be), 2->6, 4->8, 6->10, 8->12. K10-en: 0->3, 1->4, 2->5, 3->6, 4->7. Tehát K8-ön 12 órajel alatt van kész, K10-en 7 órajel alatt. Azonos órajelen 7. utasításnál lépi át a K10 a 2x-es értéket, de ilyen hosszú, egymástól nem függő utasításokból álló kódot nehéz írni.
''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.''
Lebegőpontos egységeket nem lehet csak úgy összekapcsolni, 32-64-80 biten más-más a karakterisztika és a mantissza mérete. Ezek a lehető legnagyobb sebességre kialakított számolóegységek, a lehető legegyszerűbbek. Inkább több, speciális van egymás mellett, mint kevesebb komplex, nem pár ezer tranzisztoron múlik. Van ennél hajmeresztőbb is: ''An (on-chip) ROM-based table lookup can be used to quickly produce a 14-to-15-bit precision approximation of 1/b using just one 3-cycle latency PFRCP instruction.'' Ehhez számolóegység sincs, csak egy ROM-táblázat.
dezz #442:
Az FPU-egység az MMX, SSEx és x87 utasításokat csinálja, tetszőlegesen keverve, órajelenként 0, 1, 2 vagy 3 micro-op-ot indíthat, egyet minden pipe-ba, de adott micro-op csak bizonyos pipe(-ok)ban futhat. Lebegőpontos műveletek a következők lehetnek: 1x32 bit (x87, scalar SSE), 2x32 bit (3DNow!), 4x32 bit (SSE), 1x64 bit (x87, scalar SSE2), 2x64 (SSE2), 1x80 bit (x87). Ezeket legegyszerűbb az említett háromféle számolóegységgel megvalósítani. A kép valóban nagyon sematikus.
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)
dezz #468:
Úgy néz ki, egy kis félreértés adódott. No, akkor gyorsan szaladjuk át a FPU egységen:
A DirectPath és VectorPath decoder-ek órajelenként max. 3 macro-op-ra fordítják le az utasításokat, ez a CPU műveletvégző egysége. Ez a macro-op egy vagy több micro-op-ot (pl. valamilyen elemi művelet, load, store, ...) tartalmaz, valamint egyéb információkat (ilyen egyéb információ pl. a forrás- és célregister-ek nevei, eax, ST(1) vagy XMM3 szinten).
Ezek követlenül az Instruction Control Unit-ba kerülnek, innen mennek az FPU-egységbe, majd lefutás végén ide kerülnek vissza. Az FPU egységben a Stack Map és a Register Rename lépcsőkben az ST(x) vagy XMMx formájú argumentumok leképeződnek a megfelelő registerfile-beli elemekre, tehát a micro-op-ok megkapják bemeneti és kimeneti paraméterüket (mely fizikai registereket kell olvasni és írni a 120-elemű registerfile-ban). Majd a scheduler-be kerülnek, és itt a bennük lévő micro-op-ok elindulnak a megfelelő időben a pipe-okban (FADD, FMUL vagy FSTORE).
Tehát a CPU elemi műveleti egysége a macro-op, az execution unit-oké (ALU, AGU, FADD, FMUL, FSTORE) a micro-op. Így már remélet érthető, hogy ha egy 32 bites FADD ST(2) és egy ADDSS XMM1,XMM2 ugyanazt a micro-op-ra fordul le (az FADD ugyanannak látja), de egyáltalán nem ugyanarra a macro-op-ra. És gyakorlatilag a macro-op-ok a register-átnevezési táblázok alapján fenntartják a klasszikus register-elrendezéseket, tehát továbbra is 8 MMX/x87-veremregister van, és 8 (vagy 16) XMM-register látható programozói szinten.
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
#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. ) -
Raymond
félisten
válasz #95904256 #476 üzenetére
K8 vs. Core2 SSE = 2x64bit vs. 3x128bit (2 symetrical) exec unit.
A Core2 a foldbe dongoli a K8-at (foled 128bit) SSE teren.
Elnezest hogy Anandtech-et linkelek, de itt egy oldalon szepen attekinthetoen vannak az abrak: [link]Privat velemeny - keretik nem megkovezni...
-
#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] -
Raymond
félisten
válasz #95904256 #478 üzenetére
''Tehát nem értem hogy miért hoztad fel hogy az eredmény az exec unitok száma miatt jött ki.''
Szama es tipusa. Van kulombseg a 64bit es a128bit teszteredmenyeid kozott?
''Tévedtem, az átlapolás nem úgy működik ahogy azt eddig gondoltam.''
Es mire jutottal?
Egyebkent kulon orommel tolt el hogy nem a ''CL2 DDR900-on'', ''az en tulhajtott konroom szetszedi a K10-et'' es hasonlo stilusu hsz-ek vannak itt az utolso par napbanPrivat velemeny - keretik nem megkovezni...
-
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. -
Oliverda
félisten
Hopp: [link]
Ami nem jött össze a DDR1 idejében az most talán megvalósul a DDR2-nél. Ugye a DDR500-at már nem szabványosította a JEDEC, pedig lehet hogy jól jött volna akkoriban az AMD-nek.
[Szerkesztve]"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."
-
P.H.
senior tag
Igazából most igazán nem értem, mit értesz a így superscalar végrehajtás. Fejtsd ki még egyszer pls.
''Mint ahogy az integer ALU-knál teszik is már jó ideje!'' Tudomásom szerint a Netburst volt eddig az egyetlen, amiben az ALU-k 1 órajel alatt 2 utasítást tudtak fogadni. Ezt emlékeim szerint úgy oldották meg, hogy a két egyciklusú ALU - és az ütemező (egy része) - a hivatalos magórajel kétszeresén működött.
[offoff]Karakterisztika és mantissza kifejezéseket használja az 1988-as kiadású Pethő Ádám: A ROM-BIOS és ami mögötte van (IBM PC/XT felhasználóknak és programozóknak) Az Intel 8087 koprocesszor című fejezete. Megfelelően régi? [/offoff]
akosf #476:
A K8 és a K10 elméleti végrehajtási sebességét és gyorsulását hasonlítottam össze, ahol a decode, dispatch, és a pipe-ok működése is lényegében azonos mechanizmuson alapul. Végülis a K10 a K8-hoz képest lesz kétszeres sebességű, AMD szerint.
[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
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 ˙˙˙
-
slett27
addikt
A K10-ben lesz 3DNow ? És ebből következik a következő kérdés : kihasználja-e egyáltalán vmelyik program még ?
"Ismerősöm szerint az ő Logitech Z-623-as rendszere (bizonyos esetekben) jobban szól, mert felére feltekerve is adja a mélyet, szétveri a házat a gettób@szó számokban !" by Rasiel :DDD
-
P.H.
senior tag
Lesz. Igaz, hogy a Software Optimization Guide for AMD Family 10h Processors című 280 oldalas doksiban összesen 7x szerepel a 3DNow! szó (ebből egy az ...are trademarks of... kifejezésben), de lesz benne.
[Szerkesztve]Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
#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] -
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...
-
-
#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. -
7600GT
senior tag
Lenne egy elég láma kérdésem: most vmikor szeretnék gépet fejleszteni egy core 2 duo e4300-ra mert az most elég occsó. Csakhogy olvasgattam vmennyire a totyikban és nekem kb az jött le ha ezek a k10-ek agyon alázzák a core 2-t.
A kérdés: érdemes-e most fejlesztenem vagy pedig várjam meg ezt az überbrutál K10-t?
Mégy egy kérdés(hupsz ez kettő ) :Miben különbözik a K8L a K10-től Ha naon hülyeség akkor csak annyit mondjatok h tökmás KöcikeHa az ember féreggé teszi saját magát, ne csodálkozzon, ha rátaposnak.
-
Raymond
félisten
válasz #95904256 #491 üzenetére
A harom SSE egysegbol csak ketto vegez ''komoly'' munkat. A harmadik nem. Ezt a teszt eredmenyek is alatamasztjak amik tiszta SSE teljesitmenyre mennek ki. Pl. a Sandra fraktal test. Ugyanazon az orajelen DP-ben kb. ketszer, SP-ben pedig kb. negyszer gyorsabb egy Core2 proci mint egy A64 X2 ugyanazon az orajelen. Keresek valami linket is.
Privat velemeny - keretik nem megkovezni...
-
Raymond
félisten
Ha nem egetos (megy minden programod ahogy kell) varhatsz kicsit (Q3/Q4 2007).
K8L es K10 itt a topicban (meg ugy altalaban) ugyanaz. Csak eloszor az egyik aztan a masik neven lett ismert a mediaban. Hogy a valosagban hogy voltak a belso elnevezesek az AMD-nel azt csak ok tudjak.Privat velemeny - keretik nem megkovezni...
-
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.
-
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]
Ú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.
- Újszerű - INTEL Core i5-14600KF 14mag 20 szál 5.3GHz CPU - bolti garanciával
- 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 i9-11900 Processzor - Garancia & Számla - Utolsó Darabok
- Beszámítás! Intel Core i7 7700K 4 mag 8 szál processzor garanciával hibátlan működéssel
- i3 8100/ ingyen automata