- Android alkalmazások - szoftver kibeszélő topik
- Profi EKG-s óra lett a Watch Fitből
- Honor 400 Pro - gép a képben
- Samsung Galaxy S21 és S21+ - húszra akartak lapot húzni
- Honor Magic7 Pro - kifinomult, költséges képalkotás
- Samsung Galaxy A54 - türelemjáték
- Milyen okostelefont vegyek?
- Telekom mobilszolgáltatások
- Apple iPhone 16 Pro - rutinvizsga
- India felől közelít egy 7550 mAh-s Redmi
Új hozzászólás Aktív témák
-
Lasi
tag
Tökéletesen egyet értek.
Bár valahogy az AMD felé húzódom, mindig kérdezem magamtól, nem lenne egy kicsit jobb az Intel. Nem hiszem, hogy meg fogom lépni a váltást, de ami itt zajlik a két gyártónál az nagyon kemény. ... Pillanatok alatt változik mindkét oldal technikája. Természetesen a lépcsőfokok folyamatosságával.
-
Lasi
tag
fLeSs
Ez igen. Én csak most olvastam a tesztet, de nekem nagyon tetszett.
Átfogó és érthető. Szerintem a lényeges dolgok ki lettek emelve. Nem hiszem, hogy ennél jobbat ki lehetett volna hozni a jelenlegi állásból. Azzal pedig egyet értek, hogy a valós alkalmazás függvényében a teljesítmények változhatnak. -
04ahgy
nagyúr
Ez a teszt nagyszerű. Totálisan brutális, és nagyon jellemzi a színvonalat. Először is szeretnék gratulálni hozzá.
Másodszor pedig: igen vegyes az összkép, mégis igen éles a kontraszt. Amit ebből a tesztből megkapunk, mi, az olvasó, az igen csekélyke dolog. Csekélyke ahhoz, amit a mérnökök véghezvittek az AMD-nél / intelnél a processzorok tervezésekor. Rettenetesen jól látszik belőle a gyökeresen eltérő szemlélet, ami fennállt akkor, mikor ezeket a mikroelektronikai csodákat kiötlötte az emberi elme.
Mindamellett furcsa érzéssel viseltetek ennek az elolvasása után, mert egyszerűen csak a körülmények azok, amik negatívan hatnak. Először a nyers erő. Az intel gyártástechnológiája a tények alapján jóval nagyobb órajelek elérését teszi lehetővé. Arra billen tehát a mérleg, továbbá a nyers ereje is nagyobb a CPU-nak intel fronton (gondolok itt a 2 vs. 3 SSE végrehajtóra). Viszont a teszt arra is rámutatott, hogy nem szabad az AMD felett sem keresztet vetni, mert meglepő architekurális előnyöket is felsorakoztat. Csak azt sajnálom, hogy az órajel terén még gyengélkednek.
HGyu
-
#82
Rive
veterán
Foglalt név
#80
Rive
veterán
válasz
Foglalt név
#80
üzenetére
Mindkét gyártó babratolja a cache-t és az FSB-t is. Meg a memória fajtáját is, alkalmadtán. Meg az IO-link sebességét (igen, ez az Intelnél egyelőre azonos az FSB-vel).
Szóval majd ha másba is bebabratolnak, az értelmes kérdéssé teszi, hogy, vajon miképpen változnak a processzorcsalád mutatói. De addig hatékonyság dolgában az üzemi szorzóval illendő tesztelni
Példának okáért állhat itt mondjuk a K7 vége: a kezdetek kezdetén ugye a K7 nagyon jól skálázódott. Aztán a végén már hiába volt a nagyobb cache, a nagyobb FSB - az egymást csak alig valamivel követő órajelváltozatok már alig tértek el egymástól teljesítményben...
-
#80
Foglalt név
addikt
Rive
#55
Foglalt név
addikt
-
Supra
tag
Egyébként itt szerintem többen is tévednek abban, hogy fekete-fehér alapon abszolúlt győztest várnak - pedig ilyen nem lesz. Más platformok, más tulajdonságokkal, a legjobb válasz amit várni lehet max az, hogy melyik miben jobb, mire célszerűbb használni...
Egyébként ha már ilyen mélyre merültünk, megérne szerintem egy cikket a 64 bites üzemmód ismertetése, leírása, mert erről sokan beszélnek, de alig valaki tudja, miröl is van igazán szó... Gondolok itt előnyökre, hátrányokra, mikor érdemes, mikor nem, illetve mikor elengedhetetlen.
-
Raymond
titán
LOL, egy kis tortenelem a masodik linkbol amely meg a HP/Compaq merger elott irodott:
[I]"Unfortunately, as the x86 nears its 25th birthday, it's clear (to Intel, at least) that it's been pushed to its limits. This is why Intel is working with HP to base their IA-64 architecture on the PA-RISC instruction set. The IA-64 architecture is an interesting blend. On the one hand, it (supposedly) supports object-code compatibility with the previous generation x86 family (though at reduced performance levels). Obviously, it's a RISC architecture since it was originally based on Hewlet-Packard's PA-RISC (PA=Precision Architecture) design. However, Intel and HP have extended on the RISC design by using another technology: Very Long Instruction Word (VLIW) computing. The idea behind VLIW computing is to use a very long opcode that handle multiple operations in parallel. In some respects, this is similar to CISC computing since a single VLIW "instruction" can do some very complex things. However, unlike CISC instructions, a VLIW instruction word can actually complete several independent tasks simultaneously. Effectively, this allows the CPU to execute some number of instructions in parallel.
Intel's VLIW approach is risky. To succeed, they are depending on compiler technology that doesn't yet exist. They made this same mistake with the iAPX 432. It remains to be seen whether history is about to repeat itself or if Intel has a winner on their hands."[/I]
De reg volt mar ez is. Es mara a valasz is megvan a feltett kerdesre
-
-
P.H.
senior tag
Ebből nem kell vizsgázni. Ez a cikk nem azért van, mert ebből mindent egyből megtudsz, hanem pl. mert ha ilyen szinten érdekel, akkor pl. tudod hova tenni az ehhez (angol nyelvű) hasonló cikkeket, és nem fordulsz el ennek a második fejezetnél, hogy nem érted,
(Csak zárójelben jegyzem meg - és provokatív leszek, célzásképp -, GPU-témában elég soványak a magyar nyelvű források.)
-
#67
Balala2007
tag
Balala2007
tag
A cache méréseknél meg volt "magyarázva" és meg is értettem hogy miért lehet a másolás gyorsabb mint az írás...no de a memóriánál...?
![;]](//cdn.rios.hu/dl/s/v1.gif)
Idezetek az everest.chm-bol:
Memory Read
The benchmark reads a 16 MB sized, 1 MB aligned data buffer from system memory into the CPU.
[...]
Memory Write
The benchmark writes a 16 MB sized, 1 MB aligned data buffer from the CPU into the system memory.
[...]
Memory Copy
The benchmark copies a 8 MB sized, 1 MB aligned data buffer into another 8 MB sized, 1 MB aligned data buffer through the CPU.Copy = "Egyszerre" Read es Write.
Sot: az AMD procik esetében gyorsabb a másolás mint az olvasás...elobb kíírja a proci a cuccot mint ahogy beolvassa...
Nem, ez azt jelenti, hogy a read es write atlapolodhat.
Read:
movdqa xmm0, [esi]
movdqa xmm1, [esi + 16]
...Write
movdqa [edi], xmm0
movdqa [edi + 16], xmm1
...
Copymovdqa xmm0, [esi]
movdqa [edi], xmm0
movdqa xmm1, [esi + 16]
movdqa [edi + 16], xmm1
...CopyBW <= ReadBW + WriteBW
Sajna nincs egyseges szemlelet, hogy a copy-nal a read es write egyutt vagy kulon szamit, Sisoft Sandra mindkettot beleveszi, az RMMA es a Sciencemark meg nem. Ez szemlelet es valasztas kerdese. Mi az elobbit valasztottuk, hogy a cache meretu blokkoknal a teljes adatforgalom a cache-en belul maradjon.
képes akár az elméleti sávszélességnél is nagyobb értékeket mérni
Arra a lassan ket evvel ezelotti malorre gondolsz, amikor az uj membw rutin beta tesztelesekor az elso 2MB L2-es Prescottokat egy VIA chipsetben tesztelgettuk az RMMA-val egyutt? Elobb kellett volna gyanakodnunk arra, hogy egy 2MB-os cache 16MB memoria tesztelesebe bezavar, minthogy az -- esetleges aszinkron -- VIA varazsol valamit. Ez egy hulye feltetelezes volt reszunkrol, de mi nem ragaszkodunk hozza. A bench modul 125-os buildje ota van cache invalidacio a memoriara vonatkozo benchekben, a Vegleges verzioba mar csak a javitott kerult bele. RMMA iroknak level ment, reakcio 0, RMMA maig invalidalas nelkul mer. Ugyanugy, ahogy a "lelkesedesbol" irt osi rutin. Idonkent persze felbukkanak extrem magas bw riportok, de eddig az osszesrol kiderult, hogy a user valamilyen modon megpiszkalta a time source-ot.
-
hmmmm, de jó kis cikk, nemcsak a Phenomot segít elhelyezni, hanem arról is ad infot, hogy milyen körülmények között (lesz) érdemes Wolfdalre / Yorkfieldre váltani Conroe-ról / Kentsfieldről. nagy thanx!
-
Rive
veterán
Az IPC csak annyit jelent, hogy a procc egy órajel alatt átlagosan hány utasítást hajt végre. Pillanatnyi értéke függ a végrehajtott kódtól, memória- és IO-alrendszertől. Van ugyan maximuma, de azt csak speciális, köznapi felhasználásban tipikusan totál értelmetlen kódok alatt képes közelíteni. És ez a maximális érték sokszorosa a 'rendes' üzem alatt felmutatottnak.
Azért a kavar, mert az IPC tipikusan nem köznapi használatú fogalom. Inkább a processzor hatékonyságát jelenti, nem a nyers sebességét. A Dokar által említett energiamegtakarítós példában az IPC megnő ugyan, de az órajel meg annyira lecsökken, hogy a végeredmény brutális (számítási)teljesítménycsökkenés. Csak nem a (mag)órajel csökkenésének arányában.
-
Ribi
nagyúr
Nemertek hozza azert kerdezem hogy az IPC nem egy fix dolog hogy az architektúra ennyit ennyit tud es kesz ? Csak furcsallom hogy tulajdonkepp a proci mindig lazsal. Es amikor igazan lazsalni akarna meg taknyomvagjak hogy marpedig most meggyorsabban kell dogozni.
Lehet hogy azert nem lehet 6 szorozo ala venni mert az a max IPC amit bir ?
Ha a memot megrantom akkor is megy felfele az IPC ?
Elegge ossze vaok zavarodva mostan
-
Rive
veterán
Azonos memóriaórajel mellett. Ezért csalna az a szorzóállításos módszer, amit itt fentebb FN felvetett.
Gondolj bele! Fix órajelen állandó a memória késleltetése (ns) és sávszélessége (MB/s). A processzor a memóriából annyit lát, hogy x (core)órajel alatt (ns/freki) megjön az adat, mégpedig órajelenként y byte (MB/sec /freki). Ebből csinál a tehetsége szerint IPC-t.
Ha kisebb a(z) (core)órajel (a szorzó), akkor a procc annyit lát, hogy kevesebb órajel alatt több adat jön. Naná, hogy nekivadul.Természetesen itt a memória és a CoreClock közötti szorzóról van szó.
-
Rive
veterán
Hülyén hangozhat, de: ja. Próbáld meg kiszámítani, hogy alacsony és magas szorzónál menyi egy-egy memóriahozzáférés késleltetése a mag órajelciklusaiban számolva. Eléggé brutálisan meg tudja dobni az IPC-t.
Ui.: most nincsenek ugyan itt a régi dolgaim, de úgy emlékezetből K7 esetén volt olyan teszt, aminél a 8X és a 12X -es szorzónál mérve majd' kétszeres különbség volt az IPC-ben. A szumma teljesítmény persze jócskán visszaesett a lecsökkent órajel miatt, a hatékonyság azonban durván nőtt.
-
dokar
addikt
-
#55
Rive
veterán
Foglalt név
#54
Rive
veterán
válasz
Foglalt név
#54
üzenetére
???
A szorzó tipikusan az a dolog, aminek elállítása a 'rendes' működési tartományból kitúrja a procit. Az 'üzemi' szorzóval kell tesztelni, ha releváns eredményt akarsz.
Ui.: ha így jobban érted: az alacsonyabb szorzót a procc úgy látja, mintha brutálisan betuningoltál volna a memória-alrendszerbe. Ha pedig téged az üzemi körülmények között mutatott hatékonyság érdekel - a clock-to-clock verseny - akkor nem tuningolhatsz.
-
#54
Foglalt név
addikt
Rive
#49
Foglalt név
addikt
6*333=2000=10*200 nem? Csak az első esetben nincs olyan érzésem, mintha a Pentium Dual-Core áll ki a k10 ellen... Bár látom ezt senkinek sem sikerült felfogni, szóval biztos én írtam hülyén, bocs
Ha vlki ebből azt látja ki, hogy ott kevesebb a cache vagy csak 2 mag, azért sajnos nem tudok felelősséget vállalni
-
#53
Foglalt név
addikt
fLeSs
#52
Foglalt név
addikt
Nem a HT-nek van köze bármihez, hanem a QPB-nek. Ami ha jól tudom, akkor a core2-nál igenis szerepet játszik a tesztekben...
Szóval akkor a kérdés. Miért nem a szorzót vettétek lejjebb az fsb helyett, mikor az második sokkal inkább teremt szűk keresztmetszetet?Egyébként belátom, hogy poénkodni egyszerűbb, mint gondolkodni vagy értelmes válaszokat írni, csak a hasznát nem érzem.
-
#52
fLeSs
nagyúr
Foglalt név
#47
fLeSs
nagyúr
válasz
Foglalt név
#47
üzenetére
A HT-nak mi köze itt bármihez?
Egyébként aki nem érti meg, hogy mire jó ez a "teszt" (nem véletlen a zárójel), annak már mind1.
Majd nemsokára jön a sima teljesítményteszt. -
#25954560
törölt tag
nekem pl azert erdekes a cikk, mert mi altalaban konkret architekturara fejlesztunk. igy most, amikor par cuccost lehet at kell vinni pentium-m-rol es sparcII-rol opteron-ra, lehet erdemes elgondolkodni egy-ket dolgon azon kivul, hogy milyen optimalizacios kaccsolot kapjon a gcc
hacsak nem az derul ki, hogy a gcc kaccsoloja tokeletesen elegendo de ehhez meg lehet tesztelgetni kicsit.
szoval nekem nagyon tetszik a cikk -
#49
Rive
veterán
Foglalt név
#47
Rive
veterán
válasz
Foglalt név
#47
üzenetére
A cikk ebből a szempontból (majdnem) jó. Ha mélylélektan, akkor kifejezetten illik elvonatkoztatni a konkrét órajeltől. Max. azt lehet a cikkíró szemére hányni, hogy ez csak részben történt meg: egy rakás mért érték nem architektúra-, hanem órajelfüggő. A nanoszekundumban mért késleltetés, például. Az adott tárgykörben használják még az órajelben mért késleltetés a cache dolgaira. Egy-egy architektúra esetén ez bármilyen órajelnél konstans. Legtöbbször.
A dolog hátulütője, hogy itt a legtöbb embert a procc szumma teljesítménye érdekli, nem pedig a 'mélylélektanhoz' tartozó mértékszám(ok). Amik pl. a klf. referenciaként használt tesztek esetén mért IPC, CacheMissRatio, meg más hasonlók.
Mindenhol a cikkíró dolga, hogy a két véglet között hogyan egyensúlyoz. A cikk ebből a szempontból egy korrekt kompromisszum.
-
disused
csendes tag
ebbol kene az olvasoknak holnap vizsgazni 95% megbukna, pont mint az elozo k10 architektura ismertetesbol... leirjak itt sokan, hogy "fu de jo", meg "tok ertheto", de ha megkerdeznenk 1-2 reszen, hogy ez vajon miert igy van, micelbol, nagy csend lenne.. be kell latni, hogy itt nincs aki ert hozza, talan 10-15 emberke eltudja mondani, hogy mikent mukodik, meg vagy 4-5 aki erti is, oszt annyi
-
#47
Foglalt név
addikt
Foglalt név
addikt
Mennyire érzitek egyenlőnek, hogy az amd a kb. saját órajelén fut és főleg a ht alapsebességen volt, miközben az intel kb. 50%-on(ha a 400MHz-et vesszük alapul). Nem lett volna objektívebb a teszt egy 6*333-as beállítás a core-oknál?
-
#41
Mz/ts250@300
tag
Mz/ts250@300
tag
Jó kis cikk lett gratula az ironak
Azt tudtam ,hogy a brisbane cache valamivel lasabb mint elöde
De egy 939 es toledo magos 2000mhz-s X2 es procim
everest memoria &cache bencmark L2 tesztbe jelentösen jobban szerepel. -
-
Rover623
félisten
Egyébként vicces, hogy egyetlen, ráadásul nem is lényeges mérési eredményen így kiakadtál, itt sztem vmi személyes ellentét van a háttérben, aminek nincs sok köze a topikhoz, úgyhogy inkább mailben rendezd le a programírókkal.
Én egyáltalán nem tartom viccesnek...
Nem lényeges mérési eredmény?
Szoktál te itt az érintett topicokban nézelődni, olvasgatni?
Szeretnéd tudni, melyik tesztet használják leginkább az Everest készletéből?
Melyik panel képét linkelik leggyakrabban?
Megsúgom: a memória írás/olvasás és a cache/latency elemzőket...
És ez alapján sírnak vagy örülnek...eredménytől és vérmérséklettől függően.Személyes ellentét:
- először nem volt...a békés egymás mellett élés híve vagyok, az amatőrök egyébként is ritkán utálják egymást.
- aztán volt...bár igazából nem (egy)személyes...kicsit más szemmel kezdtem nézni a "hivatásos" programfejlesztőket.
- aztán megint nem volt...én "nyugdíjba" vonultam, Fiery világhírnévre tett szert, nem voltunk egy kaszt
, nem találkoztunk.
- aztán lett...itt összeszaladtam Fiery-vel és szakmai érvelések helyett csak süketelést kaptam. -
fLeSs
nagyúr
Nem kerüli ki a cache-eket, ezt utólag kiszedtem, véletlenül maradt benne a cikkben (az előző oldalon írtam is, hogy a K8-nál korlátot jelentett a 2x64 bit load/1x64 bit store, és ez látszott is az everest eredményeken).
A K10 írási/másolási eredményeire még én is várom a választ, a benchmark modulok készítője most jutott hozzá egy K10-es procihoz, szal ki fog derülni, hogy mi az ábra. Nekem van sejtésem, de nem akarok hülyességet mondani.
Sztem benchmarkok közül az Everest a leg uptodate-ebb, szóval nincs vele semmi gondom.
A Sandrát sosem szerettem, ez most sem változott meg, mértem azzal is mindent (memory bench, cpu interconnect efficiency, memory latency, memory és cache bench), és teljesen gázos, teljesen logikátlan, csak az Intelnek kedvező eredmények jöttek ki (mint a cikkben is látható SSE-s tesztnél), ezért inkább kihagytam őket.
Mértem CPU-Z latencyt is, linpackot és winrar-t is. A CPU-z latencyt végül nem használtam fel, mert így is több latencys teszt volt a cikkben. A winrar bench vista alatt nem túlságosan használható, linpackból meg csak SSE2-est találtam, szal nem túl friss, ezért inkább azt is hanyagoltam.Összességében az Everestben vannak optimalizációk, értelmes eredményeket ad, és megismételhető eredményeket ad, ezért használtamelsősorban ezt. Ha neked nem tetszik, akkor sajnálom.
Egyébként vicces, hogy egyetlen, ráadásul nem is lényeges mérési eredményen így kiakadtál, itt sztem vmi személyes ellentét van a háttérben, aminek nincs sok köze a topikhoz, úgyhogy inkább mailben rendezd le a programírókkal.
A memóriatesztek közül a Rightmarkos eredmények a relevánsak, mert több szálon lehet vele mérni, és ki tudtuk vele mutatni, amit ki akartunk mutatni. -
Rover623
félisten
Nem az Everest-el nem vagyok kibékülve...
Az olyan tesztekkel nem vagyok kibékülve, ahol kétségeim merülnek fel a tesztelési körülményekkel, a "mérőműszerekkel" kapcsolatban...
Az olyan tesztprogramokkal nem vagyok kibékülve, amelyek egy ideig korrektek voltak, mert lelkesedésből készültek, mert szakmai kihívásnak tekintették a fejlesztését, aztán átalakultak kereskedelmi termékké, és bulvárirányba mentek el.
Az olyan fejlesztőkkel nem vagyok kibékülve, akik "eladják" az olyan benchmark rutint, ami képes rácáfolni a fizikára...képes akár az elméleti sávszélességnél is nagyobb értékeket mérni, képes a memória esetén másolásra nagyobb értéket adni mint olvasásra...mindeközben hangoztatva, hogy ez tuti jó, és semmiféle gyorsítótár nem "zavarhat be" mert "kikerültük"...és akiknek a legfőbb érvük az, hogy ez azért is lehetséges, mert más tesztprogramok is hasonló értékeket mérnek.
Ahol a fenti kritériumok teljesülnek, és lehetőségem van, lázadozni fogok...függetlenül attól, hogy Everest-nek hívják vagy sem.Az Everest egy nagyon klassz termék...csak a memóriatesztek egy ideje semmit sem érnek benne...nagyon sajnálatos, hogy pont ezen része miatt tekint rá kvázi "ipari szabványként" a szakma...
Persze arról a "szakmáról" is megvan a véleményem, amelyik hajlandó szó nélkül elmenni ilyen anomáliák mellett... -
Supra
tag
Azért egy dolgot ne feledjünk el! Ezek egy szálas tesztek, amelyek érdekesek, de nem feltétlen életszerű felhasználás! Az AMD K7/8/10 platfomnak pontosan a felépítéséből adódik az, hogy hatékony 2-3-4-8 stb. mag esetén is - de ez az előny sem mostani a tesztekben, sem az életben nem jön még ki igazán, legalábbis otthoni környezetben.
De amikor nem pl. streaming jellegű alkalmazás van futtatva, hanem több kód, melyek egymástól független adatokkal dolgoznak, akkor nagyot tud romlani a közös buszon kommunikáló magok (Intel) teljesítménye. Szerveres alkalmazásnál/ jellegű terhelésnél ez már 2 magnál is észrevehető...Szóval várjuk ki a végét, és mindenki imádkozzon az AMD-ért, mert ha nincs verseny, akkor talán még mindig a PIII-al molesztálna minket az intel... :-)
Egyébként nagyon jó a cikk, hiánypótló! Némi részletezés jól jönne, de ez lehet akár majd külön téma is!
-
klambi
addikt
nekem, nem sok fogalmam volt eddíg hogy mit is fognak tudni ezek a processzorok, csak mindíg a külföldi tesztekben is dicsérték mind1ikett hogy mennyire jó lesz majd ha el jön, itt szintén, ez a teszt legalább valami szám adatot szolgáltatott hogy mihez is tartsunk, ha szintetikus hanem...
-
azbest
félisten
Valahol az egyik itteni fórumban láttam félrevezető dolgot erről az kavart meg (valaki azt írta hogy az l3 a ht sebességével megy)
Bepillantottam a korábbi cikkekbe és leesett, hogy a memóriaműveletek nem a HT-n át mennek. Ebből kiindulva ha AM2ben is ugyanolyan órajelen mehet az L3 mint AM2+ ban, akkor nincs hátrányban egy régebbi biosfrissített lap sem.
-
#95904256
törölt tag
Sőt: az AMD procik esetében gyorsabb a másolás mint az olvasás...előbb kíírja a proci a cuccot mint ahogy beolvassa...ez már döfi...
Ez a másolásos teszteredmény csalóka. Úgy tűnik hogy minden bájt mind az olvasás, mind az írás során beleszámítódott az eredménybe. Ha a tesztprogram úgy címzi a memóriát hogy a memóriavezérlő közben időt spórolhat az átlapolásokkal, akkor jöhet ki ilyen eredmény. Pl. ugyanarról a címről olvasom és írom az adatot, akkor pl. feleannyi lapváltást kell lekezelni a memóriamodulnak mint sima olvasás esetén. Ez a "holtidő" így nem jelenik meg a mérésben.
szerk.: Mérési bizonytalanságnak nagyon durva lenne az 5% körüli eltérés...
-
dekoninck
aktív tag
Nem semmi ez a cikk! Még laikus is ért belőle egy csomó mindent. Épp mostanában akartam megkérdezni, hogy szegény AMD prockók a pirinyó L2 cache-jükkel nincsenek-e nagy hátrányban a túlméretes Core2 cache-ekkel szemben, de már meg is kaptam a választ
De maradt még két kérdésem:
- A cikk írója itthon - azon kívül, hogy népművel - hogyan tudja kamatoztatni e tudását?
- Milyen progival készülnek a pofás grafikonok? -
Rover623
félisten
Kicsit más véleményen vagyok...
Gyengébbek kedvéért (logikai) sorba rakom a lényeget:
1. A "teszt" a szintetikus benchmarkokra alapozott...bevallottan.
2. A következtetéseket, konklúziókat a tesztelők és a kedves olvasók is ezek alapján vonták/vonják le.
3. A tesztek egyes esetekben szemmel láthatóan gyengélkednek vagy éppen rácáfolnak a fizikai összefüggésekre.Tehát?
-
#14
Tuco Ramirez
őstag
Tuco Ramirez
őstag
Nagyon tetszett az írás, igazi profi munka.
Ezek után már csak arra vagyok kiváncsi, hogyan teljesít majd a K10 a Penryn-nel szemben a valós alkalmazásokban. -
Andre1234
aktív tag
nagyon tetszik ezen oldalról való megközelítése a tesztelésnek.szép olvasható cikk..
pont ez itt a lényeg hogy a különbségeket, előnyöket, hátrányokat megmutatva tisztán láthatjuk a k10 tudását és az elhelyezkedését a cpu mezőnyben.
1-2 stepping és nálam is dobog majd 1 k10fleSs gratt a cikkhez (és várjuk Oliverda dfi lapos tesztjeit)
-
rollins
őstag
Még nem olvastam el, de az L3 -nál: További nehézség, hogy sokkal bonyolultabb cache-koherenciakezelő logikára van szükség
Szóval itt fordulthat elő, puskázok, idézet hwsw:
mikor az egyik maghoz tartozó másodszintű gyorsítótárban (L2 cache) a címfordítási tábla frissítés alatt áll ugyan, de nem kerül zárolásra, így a harmadszintű (L3 cache) gyorsítótárba másolva más magok kezdenek el dolgozni az alapján -- ezzel sérül a koherencia. A probléma oka, hogy a címfordítási tábla állapotát jelző bitek nem változnak meg "atomi" időben, így cache-műveletek férkőzhetnek be ebbe az ablakba.
Rover623: -
Rover623
félisten
A cache méréseknél meg volt "magyarázva" és meg is értettem hogy miért lehet a másolás gyorsabb mint az írás...no de a memóriánál...?
Sőt: az AMD procik esetében gyorsabb a másolás mint az olvasás...előbb kíírja a proci a cuccot mint ahogy beolvassa...ez már döfi...
Első körben az egy szálon futó memóriateszteket vettük elő, ilyen az Everest is, amely a gyorsítótárakat megkerülve mér.
Hát persze...a fentiek csak így fordulhatnak elő... -
#5
Pjotor1986
tag
Pjotor1986
tag
Jó cikk, első olvasatra is érthető a lényeg a laikus számára is köszi!
-
Lyobag
csendes tag
véleményem szerint azért egy kis szövegmagyarázat itt-ott nem ártana.
megjegyezném: az x86 és x87 megtévesztő lehet egyeseknek, talán gépelési hibára gondolnának. (az x86 az intel 8086/88 processzorra épülő architektúra és nem mindenki tudja, hogy az X87 - avagy a 8087-es gyakorlatilag egy kiegészítő matematikai társprocesszor a 8086/88-hoz) -
Rive
veterán
Izé.
A Core processzorokban nyolcutas csoportasszociatív L1 cache található, ami azt jelenti, hogy csak minden nyolcadik memóriabetöltés igényli a 64 bájtos cella felülírását
Ez aztán jól oda lett fogalmazódva, csak épp szerintem nem az jön le belőle, aminek kéne.Ha már mélylélektan, akkor a cache dolgainál az órajelben mért késleltetéséről illik beszélni, nem az órajelfüggő ns-ről. Mondjuk a sebességnél is jobb lenne a byte/clock mértékegység.
A többit majd máskor elolvasom. Picit ömlesztett árunak tűnik, szóval nagyon neki kéne ülnöm, amire most nincs időm. -
rollins
őstag
Igaz szintetikus tesztek és tudni lehetett hogy csoda nem történt, de a Már csak egy-két hét, és kiderül, a 2,95 GHz-es K10 azért valamit már csak tudhat... azért adhat egy kis bizakodásra?
Kíváncsian várom a tuningolt 9500 erdeményeket és hogy volt -e valami gond vele.
az jó! Az kell. 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- AZONNALI SZÁLLÍTÁS Eredeti Microsoft Office 2019 Professional Plus
- ÁRGARANCIA!Épített KomPhone i5 10600KF 16/32/64GB RAM RTX 3060 12GB GAMER PC termékbeszámítással
- Új Apple iPhone 16e 128GB, Kártyafüggetlen, 3 Év Garanciával
- ÁRGARANCIA! Épített KomPhone Ryzen 5 7600X 32/64GB DDR5 RTX 5060Ti 8GB GAMER PC termékbeszámítással
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 32/64GB RAM RX 9070 16GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged