- Szinte csak formaság: bemutatkozott a Pixel 6 és Pixel 6 Pro
- Mobil flották
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Vékonyabb lett, jobb kamerát kapott, de az akku maradt a régi: itt a Fold7
- One mobilszolgáltatások
- Megjött a Honor szuperakkumulátoros mobilja
- Milyen okostelefont vegyek?
- Telekom mobilszolgáltatások
- Realme GT 2 Pro - papírforma
- Xiaomi Smart Band 10 - a hetedik napon megpihen
-
Mobilarena
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
Michell
tag
válasz
#95904256
#1950
üzenetére
Üdv! Piaci siker és tuningpotenciál.
''Tuti hogy nem''
Én egy kicsit másként látom. Az ugyan igaz, hogy az emberek nagy része nem tuningol, viszont annak a rétegnek a véleményét aki ért, vagy érteni vél a számítógépekhez, jelentősen befolyásolja a tuningpotenciál - főleg az utóbbiakét.
Ha pedig XY megkérdezi a szomszédot, a szervizest, az akárkit, hogy milyen gépet vegyen, máris megvan a piaci hatás.
Nézd meg az általános véleményt a hasonló fórumokon. Az AMD fanokon kívül - és tisztelet a valóban tárgyilagos kivételeknek - a többség a Core2 a király szinten nyilatkozott már akkor amikor az éppen hogy csak megjelent, és a fő érv a tuningolhatóság volt. Hiszen alapórajeleken azért messze nem volt akkora az AMD X2-k lemaradása mint amekkora vacakként leírták rögtön. -
ftc
nagyúr
válasz
#95904256
#1941
üzenetére
L3 nélküli csak Phenomban lesz viszont az 2 magosnál....
Nekem a K10 úgy néz ki mint egy foltozott K9(nem AM2-re s X2-re gondolok) amit a fiók méllyére dobtak. K10 nek 1 éve a aicon kellene lennie csak ugye a mem vezérlőt ők nem DDR2 s DDR3-ra tervezték hanem FBD-re vagy XDR-e már nem tudom pontosan s ahoz újrakeleltt tervezni lényegében a magot is
Lehet hülyén fog hangozni amit írok, de
elkéne szakadni a K7,K8 vonalátül AMD-nek...valami újjat alkotni
Gondolok itt egy oylan speciális dolgokra, hogy
lenne egy központi elosztó(ala router) és lennének kisebb magok bizonyos műveletekre..igaz akkor az már nem x86-s architektúra lenne.Mert 4 mag natívan elég komoly kihívás és még nem beszéltünk a 8 magos CPU-ról ha majd valamelyik őrült arra vetemedig, hogy nativan.
Sztem kezd kimúlni az x86-s architektúra .Kellene egy kis inováció ebbe a piacba.Az nem megoldás, hogy duplázunk mindenből... -
ftc
nagyúr
válasz
#95904256
#1933
üzenetére
Megoldhatták volna ez tény. DE mi az egyszerübb elektronikai szempontból? Megtervezni egy belső átvitelt vagy egy osztott cache-t ? Sztem a 2. lehetőség sokkalta nehezebb a mag belsejében.
IMC egy kényes kérdés... ugye elméletileg benne van DDR3 támogatása is ha jól emlékszem.Kitudja mire gyúrtak rá illetve mennyit sikerült javítaniuk A64 X2-k IMC-hez képest.
Mondjuk én AMD helyében hagytam volna L3-t(ez majd kiderül mennyit is jelent majd jönnek L3 nélküli változatok is). Inkább azzal keleltt volna kezdeni valamit, hogy a CPU és a ram közötti átvitel méggyorsabb legyen. -
ftc
nagyúr
válasz
#95904256
#1929
üzenetére
Mi késztette az AMD-t hogy beáldozzák a gyors memóriahozzáférést a gyors magközi kommunikációért?
Mivel ugye AMD nem az asztali frontra gyúrt rá...
Van egy 4 vagy több magra írt alaklmazásod. Legyen az egy szimulációs program. Mindegyik mag számol. Ha az egyik egy oylan részhez ér aminél már szüksége van a másik maghoz akkor sokkal célszerübb amgon belül egoldani az átvitelt mint időt veszteni ki/beirásal. Szervereknél virtualizációnál még elmegy. Asztali CPU-nál hááát kitudja.
Szétkelleen választani a szerver paicot az asztalitól AMD-nél -
Raymond
titán
válasz
#95904256
#1901
üzenetére
Hat nekem ugy tunik az IMC-s elony nagyon el fog tunni par het mulva. Ha nezted a teszteket mit vegez az uj cache hierarchia a kesleltetessel akkor ott latszik annak az elonynek lottek. Masik hogy az uj Intel chipszetben dual 1600Mhz FSB lesz igy az is csak akkor lesz elony az AMD-nel ha az IMC-t feltornazzak normalis sebessegre a mostani 1600-1800Mhz-rol.
Ami marad az a HT kapcsolat a tobbutas rendszerekbe, de az is inkabb a 4S-nel fog elojonni. -
Rive
veterán
válasz
#95904256
#1870
üzenetére
Szerintem nem az IMC a legnagyobb előnye az AMD-nek az Intel-lel szemben, hanem a szuper gyors HT busz.
Mindkettő. Az IMC biztosítja az alacsony memóriakésleltetést (kevesebb munkával magasabb IPC). A HT biztosítja a jól skálázódó többprocesszoros interconnectet. Együtt pedig prociszámmal arányos szumma memóriasávszélességet adnak. -
robyeger
addikt
válasz
#95904256
#1794
üzenetére
-Azt hogy pl. egy SSE utasítás miként terheli a magokat (milyen mikroutasítások sorozataként hajtja végre a proci) nem tudod befolyásolni, hiába DOS alatt futatod az x86-os utasításaid.
-A magasabb órajel azért kell, hogy a különböző alapórajel és szorzó beállítások között markánsabb transzfer teljesítmény különbség képződjön. Látványos különbségek kellenének, hogy a ''vakok'' számára is tagadhatatlan legyen
-
robyeger
addikt
válasz
#95904256
#1789
üzenetére
Hali! Őszintén szólva majdnem a lehető legrosszabb választás ez a proci a teszt szempontjából, először is 2magos és mi 1magra, tehát 1db L2 cache-re szeretnénk vizsgálódni, hiába az affinitás álíthatósága a win alkalmazásokra, sok összetett utasításnál a proci szuverén joga meghatározni a feladatok kiosztását, pl. ezért BIOS szinten se tiltható le a másik mag, másodsorban a 2Ghz elég kevés. A teszt szemponjából az a legjobb, ha minél magasabb az órajel, ezért AM2-nél az Orleans magos 2.4Ghz-es Athlon64 3800+ tünik jó választásnak.
De hangsúlyozom miattam nem kell 1magos procit venned
Mindenkinek: Egyenlőre úgy néz ki nem lesz időm a topic-okat olvasni, ezért ha valaki nyilvános hsz-t intéz hozzám, kérem, hogy a hsz link-jét privát üzenetben is küldje el részemre, előre is köszönöm! -
Zé_Mester
őstag
válasz
#95904256
#1762
üzenetére
hali
bocsa hogy idefirkálok, csak egy röpke kérdés
próbáltam végigolvasni az összes hozzászólást, de nekem olyan némelyik mintha héberül lenne. ennyire nem értek a procikhoz, úgyhogy ebbe a részébe nem is akarok belerondítani.
kérsésem : eldöntöttem hogy eladom a nemrég megbett Core2Duo-s gépemet és összegyúrok egy ilyen K10-es rendszerre.
azt szeretném megtudni hogy ebből mikorra lehet egy gépet összerakni? az OK hogy szept.10-én debütál a Barcelona, de alaplap mikorra lesz hozzá?
kérdésem még hogy az első procik 4 magosak lesznek??? és árba kb mennyi lenne majd? (tudom hogy most még minden homályos, meg tényleg nincs semmi infó,de úgy kb mégis)
és ugye amik most fognak megjelenni procik azok ugye nem a szerver oldalra jelennek meg??? mert valahol olvastam ilyet , hogy először azok fognak
válaszodat előre is köszönöm
(ha esetleg más is tud ezzel kapcs. valamit, az is érdekel !!!
[Szerkesztve] -
dezz
nagyúr
válasz
#95904256
#1757
üzenetére
''Na, ne bosszants...''
Ezt én is szeretném kérni tőled.
''A SIMD utasításoknak csak egy része lebegőpontos, amelyeket ugyanaz az FPU hajt végre mint amelyik az x87 utasításokat. A másik része meg nem lebegőpontos és ezeket nem az FPU hajtja végre. Pl. ez utóbbiak közé tartozik az SSSE3 és az SSE4 utasítások.''
Úgy tűnik, te Intelben gondolkodsz, én meg AMD-ben... AMD-nél ezeket is az FPU (= a közösen ''FPU''-nak címkézet részek) csinálja. Nos én meg ezeket ajánlom a figyelmedbe: [link], [link]
Amúgy, oké, az SSSE3 full integer, azonban az SSE4-ben van pár utasítás, ami alapvetően FP-s kódban is felhasználható.
''Ezt a hozzászólást olvastad? : [link]''
Ez a kérdés ''nem volt szép'' - hát persze, hogy olvastam. Miért nem inkább azt írod, hogy pl. ''nyilván valamilyen oknál fogva túlnyomórészt azokat a dolgokat használta a teszt, amit a K10 csinál jobban, és tartózkodott azoktól, amit a Core uarch.''? Bár ez nem valószínű, mivel nyilván valami ipari tesztet futtattak, másra magasról tenne mindenki.
''ps: A megszólítottat azért írom oda és emelem ki vastagon mert olvashatóbbá teszi a szöveget. Az általad használt megoldás nehezebben átlátható, legalábbis nekem biztosan. Feltételezem másnak is.''
Akkor szerinted miért ez a bevett gyakorlat itt a PH-n?
[Szerkesztve] -
dezz
nagyúr
válasz
#95904256
#1749
üzenetére
''Kellett volna?''
Hát már hogy ne kellett volna, ha - természetesen - minden lényegeset fel akarsz sorolni...?
''Egyébként nem hiszem hogy ezektől kapna szárnyra a Penryn FPU-ja.''
Hát már hogy ne, ha egyszer így bizonyos műveletek gyorsabban elvégezhetők?
''Ugyanis az FPU-ról volt szó...''
Igen, és? Most beszéltük meg, hogy a SIMD is az FPU-hoz tartozik.
''Ennek már elég nehéz meghatározni az FPU-ra gyakorolt teljesítményét.
Szerinted mennyire jelentős? Egyébként nem említettem a beépített memóriavezérlőt sem.''
Éppen most írtam le, hogy nem tudom, ez mennyit számít, de az AMD az FPU-val kapcsolatban emlegette, és hogy ezért írtam ide.
''Igen, arra. Ennél egyértelműbb kapcsolatot nem is lehetne találni.''
Oké, csak nem voltam benne biztos, ezért megkérdeztem.
''Vagy te miben mérenéd az utasítások végrehajtási sebességét?''
Az egyes utasítások végrehajtási idejét nyilván ebben. Mondjuk nem csak ez számít.
''Aki akarja futtassa csak ezt a tesztet és gyönyörködjön benne hogy 50%-kal gyorsabb a K10. Szerintem még mindig feladat függő hogy mikor melyik CPU szerepel jobban. Vagy úgy gondolod hogy ezt az 50%-ot minden másban is hozni fogja?''
Szerinted ha így gondolnám, miért emeltem ki minden esetben, hogy ebben a tesztben?
Akkor a kérdés kicsit szájbarágósabban: hogy lehetne akár 1 (spec-féleség, de nem túl spéci
) tesztben 50%-kal gyorsabb FP műveletekben a K10, ha valójában lassabb FP műveletekben?
ps. a megszólított (boldos) kiemelése csak akkor szükséges, ha másnak is válaszolsz egy hsz-en belül. Az OFF tag használatát meg érdemes lenne meghagyni az OFF dolgoknak...
[Szerkesztve] -
dezz
nagyúr
válasz
#95904256
#1747
üzenetére
Hmm, akkor miért nem említetted a Penrynnél az SSE4-et? Illetve a már Core2-nél is meglévő SSSE3-at (pl. shuffle-k).
Vagy K10-nél a 256 bites elérésű L1i-t (bár nem tudom, ez mennyit számít - de gondolom, nem véletlenül csinálták, és emlegetik elsősorban az FPU-val kapcsolatban).
''A legtöbb SIMD utasítás lassabb K10-en mint Core2-ön.''
Ezt mire alapozod? Az utasítások latency értékeinek összehasonlítására?
Mindenesetre, nem tudom, ez hogy lehetne, ha egyszer a Core2 jóval kevesebb, mint 2x olyan gyors, mint a K8, miközben a K10 kb. 2x gyosabb lesz SIMD-ben, mint a K8. Meg ugye itt van ez a bizonyos teszt, amiben 50%-kal gyorsabb azonos órajelen a K10, mint a Core2 - ez mitől lehet akkor? (A natív 4-magosság és a L3 önmagában nem igazán lenne elég ahhoz, hogy a lassabból másfélszer gyorsabbat csináljon [kivéve, ha befér az egész kód+adatok a cache-ekbe, de a specFP-kre, és társaikra ez nem jellemző].)
[Szerkesztve] -
dezz
nagyúr
válasz
#95904256
#1733
üzenetére
Ez kifelejtettem. Már most ki lehet próbálni, mennyit számít a HT: nyomjatok egy tesztet úgy, hogy visszaveszitek a HT szorzóját. 800MHz vs. 1000 MHz még kb. semmit sem számít.
#1739: Gondolom, itt az x87 kódra gonolsz (régi v. új regiszterekkel), mert a SIMD kód végrehajtása is az FPU dolga.
Nos, szerintem 1-szálas x87-ben kb. egálban lesznek, vagy akár a Core még gyorsabb is lesz ebben (az állítólagos SuperPI és Cinebench eredményeket nézve). Többszálas esetben viszont a natív design és a közös L3 sokat dobhat a dolgokon K10-nél.
SIMD-ben jóval gyorsabb lesz a K10, mint a Core2, viszont nagy kérdés, hogy alakul a K10 vs. Penryn eset. Ugyan SSE3-ig itt is gyorsabb lesz a K10, azoban SSE4 használatánál már esetenként szépen elhúzhat a Penryn.
[Szerkesztve] -
dezz
nagyúr
válasz
#95904256
#1720
üzenetére
Tegyük hozzá, a kitevő ''biased'', és a mantissza helyett itt ''significand'' van (vagy legalábbis itt annak hívják).
1.5 16-Bit Floating-Point Data Type
SSE5 introduces a new 16-bit floating-point data type and two instructions (CVTPS2PH and CVTPH2PS) to convert 16-bit floating-point values to and from single-precision format.
The 16-bit floating-point data type, shown in Figure 1-4 on page 8, includes a 1-bit sign, a 5-bit exponent with a bias of 15 and a 10-bit significand. The integer bit is implied, making a total of 11 bits in the significand. The value of the integer bit can be inferred from the number encoding. Table 1-10 on page 8 shows the floating-point encodings of supported numbers and non-numbers. -
dezz
nagyúr
válasz
#95904256
#1712
üzenetére
Na ebben igazad van, jobban megnézve (amit időközben én is megtettem
) tényleg ott van az a ''2nd unit'' is. Akkor tehát arról van szó, hogy a sárga keretből ezt véletlenül kihagyták.
#1713: Lehetséges. Bár fura, hogy nem egy-egy nagy, 128 bites egység van, hanem 2x 2db 64 bites...
Csak azt nem tudom, hogy valósítják így meg a shuffle-ket. Bár arra a Core2-ben is külön egységek vannak, de itt ilyenek nincsenek...
[Szerkesztve] -
-
dezz
nagyúr
válasz
#95904256
#1705
üzenetére
Neeem! Nézd meg te is figyelmesebben!
Szerk: Akár a sárga keretes magnál is ott lehetne ez a felirat, mivel ott is ott van, a kereten kívül.
#1706: Tudtommal azonos órajelen számottevően gyorsabb a Core2 x87-ben is, lásd pl. SuperPI eredmények, és más x87 alapú programok.
[Szerkesztve] -
dezz
nagyúr
válasz
#95904256
#1702
üzenetére
Mitől ennyivel gyorsabb a Core2 x87-ben? Annak is csak 1 FMUL/FDIV és 1 FADD egysége van. Azok hatékonysága ennyivel jobb?
Viszont, van itt az FPU-val kapcsolatban valami érdekesség a K10-ben: nem csak az eredeti FPU lett némileg nagyobb (a 128 bitesre bővítés miatt), hanem minden maghoz tartozik egy 2. FPU blokk is! (Nincs kéznél a die fotó linkje, de gondolom, megvan a kép neked is, vagy valamelyik korábbi hsz-ben megtalálható.) Nem lehet, hogy az valami ''titkos fegyver'', amit csak újrafordítás által lehet kihasználni?
[Szerkesztve] -
Zoli329
addikt
válasz
#95904256
#1627
üzenetére
Én csak arra akartam rámutatni, hogy az Intel ezen kódot is gyorsabban tudja futtatni. És nyilván nemcsak SuperPi-nél van így. Én tudom, hogy régi program meg stb nade akkoris. Ha ebben nem lett gyorsabb valószínű sokminden másban sem. Persze még nem hivatalos szóval bármi lehet..
-
robyeger
addikt
válasz
#95904256
#1566
üzenetére
Hali! Igen jól érted milyen tesztekre gondolok. Az alapórajel növelésével az adatelőkészítés(adatbeáramlás) növekszik, magyarán a memóriából gyorsabban érhetők el az adatok, ergo ha nem növeljük a magórajelet a műveletetvégző teljesítménye nem fog növekedni.
Az SRQ(SRI)-t én úgy képzelem el(úgy következtetek), hogy külön buszokkal kapcsolódik az L1 cache-hez és az L2 cache-hez és egyik magórajelen másik alapórajelen működik. Az SRQ egy folyamatvezérlő, kapocs az XBAR(HTT és IMC) és a gyorsítótárak között, ezek különböző órajeleit szorozgatja igazítja egymáshoz. Azt se tudom pl., hogy programozás technikailag leválásztható-e az L2, tehát lehet-e közvetlen L1 és memória közötti kapcsolatot létesíteni az L2 kihagyásával vagy ez x86 utasítás szinten lehetetlen? Hátha te tudod, én 32biten felhagytam az assembly-vel. Nekem jóval több kérdésem van, mint válaszom, de azt látom hogy nem állnak össze a részletek, hiányosak az ismereteink
[Szerkesztve] -
Raymond
titán
válasz
#95904256
#1575
üzenetére
[link]
X6800 vs. QX6800 = 2568 vs. 4039
Az egyel feljebb linkelt progival kiszamolhatod mekkora ertek kene CPU score-nak hogy meglegyen a 30K-s eredmeny a mostani csucstarto tulhajtott 2900XT Crossfire kartyakkal:
14316
Nagyon valoszinutlen hogy majdnem 2x gyorsabb lenne egy leghutott Barcelona mint a lefagyasztott 5.1-es C2Q. Raadasul a demo rendszer kartyai alig vannak tulhajtva.
[Szerkesztve] -
robyeger
addikt
válasz
#95904256
#1535
üzenetére
Ha az én tesztemre gondolsz ahhoz a 2magos procik nem ideálisak, mert nem tudod letiltani az egyik magot, és nem fogod tudni szétválasztani a programok alatt mennyi terhelés éri az egyik és a másik L2 cache-t. Összeadódva pedig egyértelmű, hogy erősebbek. 2magos procit még a szűz win is kihasználhatja valamilyen mértékben, hiába futtatnál rajta pl. WinRAR-t multithreading tiltással. Én miattam ne vegyél 1magos procit, mert nem éri meg
-
dezz
nagyúr
válasz
#95904256
#1535
üzenetére
Itt láthatod a választékot: [link]
Ki kellene okoskodni, egy ilyen teszthez melyik lenne a legideálisabb X2-ből.
Ha úgyanúgy egy 2GHz-es, egy 3800+-os kell neked, Manchester, Toledo, vagy Windsor. Az elsőt már nem ajánlom. Húzás szempontból a Windsor-ok a legjobbak (ezen belül is minnél nagyobb, annál jobb). Ha még egyátalán kapható 3800+-os, mert 90nm-esekből már csak min. 4200+-ost szállít a cég.
A 65nm-es Brisbane-ek kevésbé húzhatók, de persze kevesebbet is fogyasztanak. 2GHz-es nincs belőlük.
(AM2-n az 1066-os DDR2 ramok hivatalos támogatása lenne a s.939 + DDR500-nak megfelelő dolog, de ilyen itt nincs, majd a K10 fogja azokat hivatalosan támogatni.)
[Szerkesztve] -
robyeger
addikt
válasz
#95904256
#1516
üzenetére
két legszembetünőbb példa:
-kell egy 1magos AM2 proci lehetőleg 2Ghz felett, mert 2Ghz-nél képes 1mag közel a dual 400Mhz-es ram kihasználására, akár hogy növelnék az alapórajelét. pl:
AM2 3800+ (Orleans) és dual 800Mhz-es ram, össze lehet hasonlítani a 200x12 és a(240x10 vagy 266x9 vagy 300x8) a HTT és a memória sebességét megpróbálni minél közelebb a gyári értéken tartani. / Lehet single és dual 800-as ram felállással is tesztelni és viszgálni a kettő közötti teljesítménykülönbséget.
-a legjobb példa a DDR500-as támogatású Venice magok: tehát 3200+ venice-nél 200x10 a proci és 500Mhz-en a memória 5x200 a HTT összehasonlítva 250x8 a procinak szintén 500Mhz a ramnak és 4x250 a HTT-nek. Azért ideális, mert itt minden Mhz-re pontosan azonos HTT és a ram freki is, kivéve a alapórajel és a szorzó, vagy másik a 3800+ venice 208x12, memória 500< felett, HTT 208x5 összehasonlítva 250x10 a procinak memória 500Mhz-en a HTT 4x250-n. Hiába gyorsabb a ram és a HTT valamivel, akkor is a magasabb CPU alapórajelű fog győzni teljesítményben.
Persze ez X2-re is vonatkozik csak ott 1magra kell vetíteni, tehát ha egy programod ki tudja használni mindkét magot, akkor a dual 800-as vagy DDR1-nél a 500Mhz-es ramokat is ki tudja használni.
Nem nehéz észrevenni hogy azonos magórajeleken is teljesítmény növelő hatása lehet az alapórajel növelésének, ebből pedig az következik, hogy a prociban van ami alapórajelen megy van ami magórajelen közte pedig a szorzó. Egyesek viszont azt állítják minden magórajelen megy a prociban és lényegtelen az alapórajel értéke csak a magórajel a meghatározó.
[Szerkesztve] -
dokar
addikt
-
slett27
addikt
válasz
#95904256
#1523
üzenetére
Éppen mostanában teszteltem (mindig csinálok screenshot-ot).
1. konfig : E2160 + 8800GTS 320MB + 2x1GB DDR2 800MHz 3DMark06 : 7422 pötty
2. konfig : A64 5200+ 8800GTS 320 + 2x1GB DDR2 800MHz 3DMark06 : 8680 pötty
Ugye csak a proci változott, igaz nem nagy változás pontosan 17% a végeredményben.
(E2160 1583 CPU pont, A64 X2 5200+ 2024 CPU pont itt részeredmény szinten 28%)
A cikknél 2,5GHz -> 3.0GHz 20% túlhajtás. 23000 pötty >>> 30000 pötty ez 30% !!!.
Vmit kihagytak a cikkből.
Vagy nem ''ismeri'' még a 3DMark06 a 4 magos AMD-t.
-
-
Rive
veterán
válasz
#95904256
#1482
üzenetére
pl. a karórákban lévő kvarckristály pusztán időalapot szolgáltat, mégis kvázi-szinkronban van a többi karórával
Bocs, ez hülyeség. A szinkron az adott szakterületen nem csak (nagyjából) azonos frekvenciát, hanem kifejezetten azonos frekvenciát és fix fázist (!) jelent.
Gondolom, azért van órajelre szüksége mert különféle áramköröket kell szinkronozni vele.
Lásd forrás-szinkron, aka SST, Source-Synchronous Transfer. Máshogy ma már nem is nagyon működik. -
dezz
nagyúr
válasz
#95904256
#1482
üzenetére
Pl. a következő okokból kell órajel a HT-nek is (még ha ez szinkronban is van az alapórajellel): 1. ez magasabb frekiként ''sűrűbb'', mint az alapórajel, így az ehhez kötött műveletek gyorsabban követhetik egymást, nem kell bevárni az alapórajel éleit. (Pl. az Intel FSB-je - miközben QDR-es - az alapórajelhez igazodik, tehát pl. a csomagok kezdete vagy az adatirányváltások.) 2. Ilyen frekiknél (főleg, hogy DDR az adatátvitel) nem is lenne teljesen biztonságos, ha minden végponton egy-egy PLL-lel külön-külön állítanának elő az alapórajelből ilyen magas órajelet, és így fogadnák a ''biteket''. (Bár Intelnél végülis ez történik, de ott csak két, viszonylag közeli végpont van [miközben a HT mindenféle egzotikus elrendezést megenged], és a végső data rate is kb. fele akkora.)
Azt is tudni kell, hogy a HT (full duplex) 16 bites (asszem bizonyos esetekben lehet 4x8 is, de most mindegy), viszont DDR-es, így 64 bit átvitele (egy irányba) 2 ütem.
Szerintem a HT portokon kívül semmi sem osztozik a HT busz órajelében. (Mivel akkor eléggé vissza lehetne venni a proci teljesítményét a HT szorzó alacsonyra állításával.)
''Pedig a RAM is az alapórajelről megy, nem?''
(A mag-szorzó közbeiktatásával.) És?
[Szerkesztve] -
P.H.
senior tag
válasz
#95904256
#1482
üzenetére
Ezen a területen sokkal jártasabb vagy nálam, szerintem ezáltal [link] (BIOS and Kernel Developer's Guide for AMD Athlon 64 and AMD Opteron Processors) lehet legjobban rálátni.
Ebből is a következő rövid szakaszok érdekesek:
3.3.13 LDTi Frequency/Revision Registers
12.4 HyperTransport™ Link Frequency Selection
Az első alatt felsorolt bitértékek nem tűnnek sem osztónak, sem szorzónak (bár attól még lehetnek):
''Processors with multiple HyperTransport™ links are capable of operating the links at different frequencies. There are three supported link frequency groups:
800 MHz, 400 MHz, 200 MHz
1000 MHz
600 MHz
Processors can be configured with link frequencies from up to two link frequency groups.
0000b = 200 MHz
0001b = reserved
0010b = 400 MHz
0011b = reserved
0100b = 600 MHz
0101b = 800 MHz
0110b = 1000 MHz
0111b = reserved
1000–1110b = reserved
1111b = 100 MHz''
És a 3.3.13. záró megjegyzése sejtetni engedi, hogy az összekötött eszközöknek lehet saját órajelgenerátoruk.
[Szerkesztve] -
-
P.H.
senior tag
válasz
#95904256
#1461
üzenetére
Azt kell ilyenkor nagyon mérlegelni, hogy egy-egy, a közös adatterülethez való hozzáférésre mennyi, azt nem érintő önálló számítási művelet jut, mert ha sok, akkor hatékony lesz az az eset is, amit írsz (pl. ismert előre, hogy egy-egy tartományra jutó számítási feladat hossza órajelekben vagy percekben/órákban mérhető).
''Honnan tudja egyik-másik CPU hogy a másik CPU mely memóriacímeket birtokolja?''
Ez a cikk [link], amit korábban linkeltem, egy elég jó kezdeti betekintést ad ebbe a világba. (Amit a link mellett írtam, ''Az alján látható, hogy többek között az Intel által használt MESI cache-protocol és az AMD által használt MOESI eltér skálázhatóságban, utóbbi mellett több magot lehet összerakni, mint előbbinél, ezért használja ezt az AMD.'' esetében ''magot'' helyett talán inkább ''CPU-t'' kellett volna írnom, bár ez sem igaz, a node kifejezés az igazi, mert Kentsfield esetén a 2x2 mag 2 node, a négymagos K10 pedig 1 node. A two vs three hop jelentéstartalma és -eltérése, és sok egyéb dolog pedig pl. innen [link] kiolvasható konkrét teljesítményadatok találhatók benne, de nem a riválisokkal összehasonlítva, hanem arra vonatkozólag, hogyan viselkedik egy többmagos-többprocesszoros Opteron-rendszer különböző körülmények között).
De amit felvetettél, jogos (pl. a cikkből, a legegyszerűbb megközelítésben):
''When a processor reads or writes a cache line, it must broadcast a snoop request to all other processors in the system to ensure that it gets the most recent valid cache line. When a processor wishes to write to a cache line, it must first broadcast an invalidate snoop, which tells other processors to evict that cache line. In both cases, the processor must wait to receive responses from all other processors before proceeding.''
[Szerkesztve] -
P.H.
senior tag
válasz
#95904256
#1458
üzenetére
Mi történik? Felhasználói program esetén jól a programozó körmére néznek,
hogy miért csinált ilyen jellegű kódot (hacsak nem kifejezetten HyperThreading-szerű felépítésre és osztott L1 D-cache-re írta a programot), már csak a felesleges adatvándorlások miatt is. Vagy hogy legalább miért nincsenek a közös adatot módosító részek levédve legalább pl. OS-szintű critical section-ben.
Kernel-szinten elkerülhetetlenek az ilyen események (pl. pont a critical section-okat kezelő mutex-ek, vagy egyéb semaphorok, event-ek esetében), akkor a hardware megoldja, ahogy tudja.
Pl. AMD esetében:
''Deadlocks can occur when multiple processors fight for the ownership of the same cache-line. They do so for instance if they both want to write to the same line. A cache-line is generally loaded as soon as possible in case of a cache-miss. This will cause the cache-line to be invalidated in other caches in case of a store. Two processors get in a deadlock if they keep invalidating each others cache-lines before they are able to finish the stores.
An example given is the case where two processor try to complete a store which is to an unaligned address so that part of the store data goes to cache line A1 and part of the store data goes to cache line A2. Unaligned stores of this type are typically split into two stores by the hardware. An exponential back-off mechanism is provided to handle this kind of deadlock situations. A back-off time is introduced when the memory access remains unsuccessful before retrying to become owner of the cache-line again. This time grows exponentially after each unsuccessful try until one of the processors finally succeeds.''
[Szerkesztve] -
Rive
veterán
válasz
#95904256
#1458
üzenetére
A cache-koherencia egy veszettül húzós témakör, és eléggé durván be tudja határolni a MP rendszerek teljesítményét. A szakirodalma is elég nagy. Ha a neten rákeresel, hogy 'cache coherency', akkor sokmindent találhatsz, én már jóideje nem foglalkozom szorosan a témával.
A megoldások természetesen olyanok, hogy elviekben képesek lekezelni az 'egyszerre' érkező kéréseket. A gyakorlatban ez nagyon sok idő, úgyhogy a programozók (kernel-bűvészek) egyik fontos feladata, hogy minél kevesebb osztottan használt memóriaterület legyen. -
dezz
nagyúr
válasz
#95904256
#1425
üzenetére
Miféle újabb per? Hiszen az már legalább egy éve megy...
(Ennek egyik monentuma volt nemrég, hogy az Intel ''véletlenül'' a backupokból is törölt bizonyos ide vonatkozó, bizonyítékként bekérni akart emaileket.) Itt Európában maga az EU indított pert az Intel ellen. A japán esetről is említést tesz, aholis a japán kornány fogta perbe az Intelt, mely per az Intel elmarasztalásával végződött, és alá kellett írniuk egy megállapodást, miszerint távol tartják magukat a versenyellenes magatartástól - azonban Ruiz szerint nem hagytak fel velük teljesen ott sem.
Egyébként azt állítja, már megoldották a problémákat. Ennek eredménye állítólag a B2-es revizió, ami már elkészült, azonban csak most kezdik gyártani, és hónapok múlva lesz belőle termék. Addig is marad a B0 revizió, ami működik, de csak alacsonyabb órajelen a kívánatosnál. (A B1 állítólag már magasabb órajelet bírt, de nem működött tökéletesen, így ''kuka''.)
Gyuri27: Hát... Ott van 11 oldal, minden oldalon egy v. több újdonság, melyek mindegyike igényelne 1-2-3 sort, még rövid leíráshoz is. -
-
FireGL
aktív tag
válasz
#95904256
#1404
üzenetére
''Az Z-RAM technológia első licencelője az AMD volt, még 2006 elején, de konkrét elképzelésekről azóta sem hallani a vállalat felől. Legkorábban az évtized vége felé jelenhetnek meg a SRAM-ot legalább részben (például a harmadszintű gyorsítótárnál) felváltó Z-RAM gyorsítótárral tervezett processzorok. A cache sűrűségének növelésére az IBM saját eDRAM (beágyazott DRAM) technológiát fejleszt, mely lehetővé tenné a logikával egy szilíciumlapkára integrálást, és hatalmas, a SRAM-hoz képest háromszor nagyobb tárak integrálását -- a vállalat 24-48 megabájtról beszélt 45 nanométeres csíkszélességű eljáráson.''
[link]
Majd kiderül, hogy ténylegesen van benne Z-RAM vagy sem.
Tripla gyorsítótár, dupla teljesítmény - jön az IBM processzorba ágyazott DRAM-ja [link]
''A vállalat az új eDRAM kereskedelmi alkalmazását a 45 nanométeres csíkszélességű gyártástechnológiára tervezi. Az IBM termékei mellett a közös félvezetőgyártási eljárás következtében az AMD, a Sony és a Toshiba processzoraiban is megjelenhet eDRAM.''
[Szerkesztve] -
ftc
nagyúr
válasz
#95904256
#1404
üzenetére
jó lenne látni egy 65nm-s X2-t is .Mert gyártása olcsobb mint SRAM. Akkor raknák L1,L2,L3 is
Ezt csak annak a fényében kérdeztem, hogy Hynix is megvette a technológiát memoriagyártáshoz![;]](//cdn.rios.hu/dl/s/v1.gif)
és AMD oldaláról nem nagyon nyilatkoztak, hogy hol lesz használva.
[link]
Egyik hszből:
zram works good at 1.2v with 0.003mA
A következő hír... K10-n már túlmutat mit is akar AMD
[link] -
dezz
nagyúr
válasz
#95904256
#1396
üzenetére
Ezek nem az Agena ellenfelei, mivel az Agena a Phenom FX-ek és X4-ek alapja, a cikk meg Xeonokról szól. A desktop Penrynek csak 2008 tavaszán jönnek.
A #1372-essel kapcsolatban figyelmedbe ajánlom az utolsó mondatot: ''It's not clear at press time whether the delays of Barcelonas are to do with technology problems, or whether the multinationals are getting preferential treatment over the channel.''
Gyuri27: Nem tudják előre, milyen lesz a kihozatal, amitől a végleges órajel-kategóriák függenek.
laci666: Ez nem festegetés, hanem potenciális veszély. Aki meg azt mondja, az Intel nem hagyná, mert akkor azt meg a feldarabolás veszélye felyegetné, annak elmondanám, hogy az ''egyéb x86 processzor gyártói részesedés'' nem 1%, hanem kb. 10. -
slett27
addikt
válasz
#95904256
#1372
üzenetére
Kiszivárogtak tesztek (ftc linkelte) most megismétlem :
[link] ahol is egy 1,6GHz-es Barcelona és egy 2,4GHz Xeon-t mértek össze Cinebench-el. Az is kilett tárgyalva hogy nem mérvadó ez a teszt, mert inkább a frekvencia számít neki. De kiindulópontnak jó.
K10 1,6GHz (814 pont)
Xeon 2,4GHz (1274 pont)
Egy kis matek : ha a K10 1,6GHz-en csinál 814 pontot, akkor 2,4GHz-en mennyit csinál(na) = kb 2,4x814/1,6 = 1221. Tehát ebbőél lehet következtetni, ha majd lesz 2,4GHz-es K10, akkor pont a Xeon-al van pariban (legalábbis e teszt szerint. Ami szintén nem elég, mert mire kint lesz a 2,4GHz-es K10, addigra a Xeon sztem 3,4GHz körül fog szaladgálni. Lépéselőnyben ismét az Intel.
Lehet jobb lenne ha IBM felvásárolná az AMD-t többre jutna.... -
Balala2007
tag
válasz
#95904256
#1353
üzenetére
Instruction latency meresre az EVEREST nem jo? (Jobbclick alul a statusz soron --> CPU Debug --> Instruction Latency Dump). Nez egy par spec. esetet is, es viszonylag pontosnak is. Ez itt pl. egy Yonah:
Ui: hoppa, ez igy eleg csunyan nez ki, inkabb kiveszem, de az EVEREST-ben megtekintheto
[Szerkesztve] -
#1358
Komplikato
veterán
#95904256
#1356
-
-
-
P.H.
senior tag
válasz
#95904256
#1311
üzenetére
Elnézést kell kérjek a #1288-as és részben a #1286 hsz miatt, hagyd figyelmen kívül, semmi értelme nincs, utólag olvasva. Így jár az, aki az ajtóból fordul vissza válaszolni (és a végtelen ciklusok mindig nagyon zavarnak). Sorry.
Az IPC 5 eléréséhez először azzal próbálkoznék, hogy a MOVQ helyett egy integer load-ot tennék a kódba, bár a throuhput-on ez elméletileg nem változtat:
''In general, instructions with load operations that execute in the integer ALU units require two more clock cycles than the corresponding register-to-register flavor of the same instruction. Throughput of these instructions with load operation remains the same with the register-to-register flavor of the instructions.
Floating-point, MMX technology, Streaming SIMD Extensions and Streaming SIMD
Extension 2 instructions with load operations require 6 more clocks in latency than the register-only version of the instructions, but throughput remains the same.''
Bár arra sem rémlik pontos adat, hogy a macro-op fusion egy órajel alatt történik-e.
Az XCHG EAX,EBX probléma szerintem egyszerűen feloldható, és máris itt a példa a 2 micro-opos Double-re: ezt úgy is meg lehet valósítani, a micro-opok először (egyszerre, még az ICU-ban) kiolvassák az EAX és EBX értékét, majd az execution unit-ba kerülve kiírják azt EBX-be illetve EAX-ba. Így teljesen függetlenek egymástól, akár egyszerre ''futhatnak le'' valamelyik két ALU-ban (a futás is képletes, mert igazából nem csinál semmit, csak mindkettő a megadott célra kiírja a forrásadatát, változtatás nélkül), ezért a latency 1 érték. Single-ben nem lehet megoldani, mert mindkét micro-op ALU-ba kerül, egy macro-opban pedig egy ALU-AGU micro-op páros kerülhet, amelyek függőségi viszonyban is vannak egymással, vagy legalábbi fix a lefutási sorrendjük (mint egyes esetben a Double-ok micro-opjainál is, de ebben nem vagyok biztos. A PUSH azért lehetett Single, mert ott a SUB ESP,04 műveletet a decode fázis ''végzi'', pontosabban a stack-engine, tehát belül az már csak egy egyszerű store. Mint ahogy a POP is egy egyszerű load, így talán könnyebben magyarázható a LEAVE és a CALL is).
[Szerkesztve] -
dezz
nagyúr
válasz
#95904256
#1308
üzenetére
''A mostani x86-os processzorok több száz különböző utasítást ismernek, ezek közül egy pár utasítás végrehajtási ideje ( késleltetése ) valóban csökkent. A baj az hogy leginkább nem azoké amelyek a leggyakrabban fordulnak elő, ugyanis azokat már eddig is elég jól megcsinálták.''
Kifelejted a 2 lépéses 64 bites -> 1 lépéses 128 bites végrehajtás általi gyorsulást, ami elég sok utasítást érint. Persze csak vektorkódnál, de ma már sok programot így írnak.
''Például nagyon gyakori hogy két számot össze kell adnia a processzornak, azonban a fent említett regiszter-cserélés nagyon ritka a mostani programokban. Bár ez utóbbit is lehetne gyakrabban használni, de ahhoz még okosabb fordító programokra lenne szükség.''
Ha jól tudom, a regiszter-rename által erre ma már nincs akkora szükség.
''Igazából a legfájóbb pont hogy a K10-es továbbra is csak 4 órajel alatt fog tudni összeadni két lebegőpontos számot, míg a Core2-eseknek 3 órajel kell. Ezt csak kis részben kompenzálja hogy a dupla-pontos szorzásban viszont épp fordított ( 4:5 ) az arány.''
Mint direkt ADD utasítás igen, de ha ''embedded'' a dolog, mint pl. FCMP, FMAX, FMIN, stb., akkor sokszor megvan 2 órajel alatt. Meg ugye nem csak ez számít, hanem a throughput is. -
dezz
nagyúr
válasz
#95904256
#1305
üzenetére
''Szerintem a DirectPath Double kódolású utasítások két, időben egymás után létrejövő makroOP-ra fordulnak le.''
Igen, tudom, hogy elvileg így van. ;)
''Természetesen a második oszlopban, ahová szintén utasításokat írtam ott több a kombinációs lehetőség mint a rögzített x86 utasításkészletben, mert ezek tulajdonképpen 1-2 mikroOP-ot jelentenek. Vagyis egy DirectPath Double 2\3\4 mikroOP-ra fordulhat le, míg a DirectPath Single csak 1\2-re. Ezekből persze egyik-másik mikroOP végrehajtási ideje több órajelet is kitehet.''
Írnál 1-1 konkrét példát 2 mikroOP-os Single-re, és 2-3 mikroOP-os Double-re? Úgy értem, hogy pontosan mi történik.
''Egyedüli kivétel a fent említett XCHG reg,reg utasítás, ami megcáfolhatja ezt a dolgot. Ugyanis ez a K8-ban még 2 órajeles VectorPath utasítás volt, viszont a K10-ben már csak 1 órajel késleltetésű DirectPath Double utasítás. Ez meg hogy lehet?''
Hát erről (is) beszélek. (Meg arról, hogy miért kell Double-nek lennie mindennek, ami két egységet dolgoztat, miközben ezek elvileg 1-1 mikroOP formájában egy mikroOP-ba kerülhetnének.) Az is érdekes lehet, hogy sok Double-nek 1/1 a throughputja. Bár 2/1-es v. 3/1-es nincs, de ez nem is csoda, hiszen két egységet foglalkoztat.
Gerr'y: mi is szeretnénk tudni a válaszokat ezekre a kérdésekre. Én azt gondolom, jópár dologban jobb lesz - azonos órajelen. Kérdés persze, milyen órajelek lesznek. Az ár meg valószínű attól fog függeni, hogy teljesít...
Andre1234: Én nem végeztem ilyen összehasonlítást, de azt ugye tudjuk, hogy a 128 bites utasítások (2-way 64 bit v. 4-way 32 bit SIMD) utasítások végrehajtási ideje alaposan csökkent, hiszen nem két 64 bites lépésben történik meg. És úgy tudom, ezen felül is gyorsult sok utasítás, plusz több utasítás mehet párhuzamosan. -
Andre1234
aktív tag
válasz
#95904256
#1305
üzenetére
szia..
[link]
''Ugyanis ez a K8-ban még 2 órajeles VectorPath utasítás volt, viszont a K10-ben már csak 1 órajel késleltetésű DirectPath Double utasítás. Ez meg hogy lehet?''
Lehet hogy nagyon leegyszerűsítem a kérdést (de ez csak is azért van mert ezen a talajon ez én ismereteim konvergál a nullához)
Akkor megvalósult lényegében utasítás késleltetési idejenek csökkentése? -
dezz
nagyúr
válasz
#95904256
#1298
üzenetére
Persze, hogy végső soron az IPC számít, de éppen ennek próbálunk utána járni (a teljesség igénye nélkül
).
A linkelt ábrán az látható, hogy AMD-nél a Pack Bufferből egyszerre 3 ''uop'' mehet tovább. És eléggé nem mindegy, hogy ez (AMD-féle) makroOP, vagy mikroOP, mivel 1 makroOP = 1 v. 2 mikroOP (DirectPath esetén, amikoris 1 utasítás = 1 makroOP). Tehát, max. IPC = 3 utasítás, akkor is, ha 2 mikroOP-os művelet (ugye memória-művelet), és akkor is, ha csak 1.
Ezzel szemben Intelnél az IPC 4 csak a 4 egyszerűbb, vagy 3 egyszrűbb (1 mikroOP-os) + 1 összetettebb (fúzióval 1 mikroOP-ossá tehető) utasításoknál lehet. Más esetekben 3, vagy épp csak 2. (Azon igen ritka esetekben lehet talán 5, ha az első 2 feltétel valamelyike teljesül, plusz egy makroOP fúzió is bejátszik, ha ezek egyszerre is működhetnek. Illetve azt nem tudom, különböző utasítások mikroOP-jai fúzionálhatók-e mikroOP fúzióval.)
Persze a legkorrektebb egy minden utasításra, plusz azok átlagos kódokbeli előfordulási arányára számolt IPC összehasonlítás lenne.
[Szerkesztve] -
dezz
nagyúr
válasz
#95904256
#1293
üzenetére
''A 4/5 mikroOP bizony jelenthet 4/5 utasítást is a Core2 esetében, ugyanis az utasítások jelentős részénél 1 utasítás = 1 mikroOP megfeleltetés áll fenn, ha nincs memória hivatozású operandus.''
Hát, kíváncsi lennék P.H. véleményére, mekkora részük.
''Na, ez lehet hogy egy kicsit homályos nekem.''
Melyik része?
Intelnél: x86/stb. utasítások = makroOP, ezek közvetlenül mikroOP-okra fordulnak.
AMD-nél: a x86/stb. utastások először makroOP-okra fordulnak, melyek 1-2db mikroOP-ot tartalmaznak.
Az ábrán, és a cikkben ez utóbbi dolog figyelmen kívül lett hagyva.
''De a Decode csatornákon keletkező 1/2 mikroOP az csak 1 utasítást jelent, nem 1/2-őt. Vagy tévedek?
Nem tévedsz, de én nem is mondtam mást. 3,0 -> 3,0.
''dezz, akkor most a segítségedet kérem. Ugyanis nem értettem meg hogy ''a dekódolás szélessége önmagában nem döntő tényező''. Először is, ezt miért mondod? Másodszor mit értesz ''döntő'' alatt? Harmadszor ha a döntő = jelentős, akkor miért nem az?''
Mert a dekóderek utáni részeknek, és talán a retirementnek szűkebb a keresztmetszete.
(De a dekóderekkel is lehet valami, mert hiába tud mind fúziót, egy 5-ös mikroOP csoportból csak 2db-ot lehet párosítani eggyé.)
''Egyébként ha azt veszem amit már írtam, hogy az IPC=1,5 értéket is nehéz elérni akkor ezzel csak megerősítettél abban hogy az IPCmax érték növelés nem hoz túl sokat a teljesítmény növelésében.
Hát igen, nem az említett dolgokon múlik a hétköznapokban a teljesítmény.
[Szerkesztve] -
dezz
nagyúr
válasz
#95904256
#1278
üzenetére
Nézd meg csak ezt: [link]
Itt 4 mikroOP széles ''csatorna'' látható, és tesztek szerint ebből 1 lehet fúzionált, azaz 4 v. 5 mikroOP mehet át, ami 2,0 v. 2,5 x86/stb. utasítás.
És amikor ezt összehasonlítod a K10 ide vonatkozó csatornájával, ami 3 szintén ''uop''-nak van jelölve, vedd figyelembe, hogy az valójában nem mikroOP ott, hanem AMD-féle makroOP, ami egyenként 2db mikroOP. (Ez a nem teljesen korrekt jelölés fel lett róva a szerzőnek, írta is, hogy talán módosítania kellene a képen, de végül nem foglalkozott vele tovább.)
[Szerkesztve] -
dezz
nagyúr
válasz
#95904256
#1275
üzenetére
Egyre rosszabb.
Mondom, ez az 5,0-ás és 6,0-ás érték mikroOP. 1db alap x86/stb. utasítás általában 2db mikroOP-ra fordul, amiből egyes párok fúzionálhatnak. Tehát:
Core 2-nél:
6,0 mikroOP -> 3,0 instruction
5,0 mikroOP -> 2,5 instruction
K8/K10-nél:
3,0 (AMD-féle) makroOP -> 3,0 instruction
(+ K10-nél több utasítás DirectPath) -
P.H.
senior tag
válasz
#95904256
#1281
üzenetére
Eredendően értelmetlen kóddal nem nehéz.
cycle:
movq mm0,[esi] //MM0 <- 64 bites értéket kap
addps xmm0,xmm0 // XMM0 <- megkétszereződik
xorps xmm1,xmm1 //<- XMM1 <- 0
dec ebp // <- EBP csökken (de miért)
movq mm1,[esi] //<- MM1 <- azonos MM0 tartalmával
addps xmm2,xmm2 // <- XMM2 megkétszereződik
xorps xmm3,xmm3 // <- XMM3 <- 0
test edi,edi // EDI tesztje (mi csökkenti? végtelen ciklus vagy 0 volt?)
jne cycle // ciklus vége
movq mm2,[esi // MM2 <- mint MM0
addps xmm4,xmm4 // XMM4 kétszeres
xorps xmm5,xmm5 // XMM5 <- 0
test ebp,ebp // válzotó(?)-teszt
jnz cycle // ciklus vége [/OFF]
[Szerkesztve] -
#95904256
törölt tag
-
P.H.
senior tag
válasz
#95904256
#1279
üzenetére
Ahogy írtad korábban, hogy maga a forrásbeli utasítássorrend kevésbé befolyásolja a K8-at, mint a Core microarchitecture-t, én ütemezésbeli erőtlenségre (''sokszor 0,8-0,9 környéki értékek jönnek ki, a vTune-nal is'') vagy (esetleg, kérdőjelesen) valami retirement-szűkösségre (ilyesmit dezz is linkelt korábban) tudok gondolni, de ezzel ki kellene várni a K10 megjelenését és teljesítményét, abból a realitások talaján talán több kikövetkeztethető.
-
P.H.
senior tag
válasz
#95904256
#1275
üzenetére
(Az első fele törölve
)
Én azon gondolkodom egy ideje, hogyan lehet az, hogy a Core microarchitecture miért nem mutat kétszeres feletti gyorsulást (illetve, hogy a K8 miért nem szakadt jobban le tőle, hiszen nem csak 64->128 volt ott a korábbiakhoz képest). Mi fogja vissza ennyre? Vagy mi nem volt ismert a korábbiakról? Mert az, ami visszafogja, az AMD-t is komolyan érintheti.
[Szerkesztve]
![;]](http://cdn.rios.hu/dl/s/v1.gif)
oktoberre talán elkezdik árusitani.
de ez is tipp 
![[kép]](http://images.anandtech.com/reviews/it/2007/barca/BarcaWinrar.gif "[kép]")
Ú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.
- Elektromos autók - motorok
- Odapakol erőben a Honor Pad GT2 Pro
- Hitelkártyák használata, hitelkártya visszatérítés
- Sok memóriát spórol a neurális textúratömörítés
- Iszonyatos mennyiségű hulladékkal járhat a Windows 10 terméktámogatásának vége
- Szinte csak formaság: bemutatkozott a Pixel 6 és Pixel 6 Pro
- Milyen billentyűzetet vegyek?
- Nyaralás topik
- Építő/felújító topik
- Tarr Kft. kábeltv, internet, telefon
- További aktív témák...
- AMD Ryzen 9 9900X3D - Új, 1 év garancia - Eladó!
- Intel I7-6700 / 4 mag / 8 szál / Beszámítás OK!
- Intel I5-8500 / Beszámítás OK!
- BESZÁMÍTÁS! ÚJ AMD Ryzen 8500G / 8600G AMD Ryzen 7 8700G / 7800X3D processzor 3 év garancia 27% áfa
- Intel Core i7-8700K 6-Core 3.7GHz LGA1151 (12M Cache, up to 4.70 GHz) Processzor!
- Telefon felvásárlás!! iPhone 14/iPhone 14 Plus/iPhone 14 Pro/iPhone 14 Pro Max
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 16/32/64GB RAM RX 9060XT 16GB GAMER PC termékbeszámítással
- Honor Magic 7 Pro - Fekete - Új kipróbált készülék! Karcmentes gyárilag független! 512GB Memória!
- Telefon felvásárlás!! Samsung Galaxy S23/Samsung Galaxy S23+/Samsung Galaxy S23 Ultra
- BESZÁMÍTÁS! ASUS Z390 i5 9500 16GB DDR4 512GB SSD RTX 2060 Super 8GB Rampage SHIVA Thermaltake 500W
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest