Új hozzászólás Aktív témák
-
Balala2007
tag
Ezt a jelenseget az szokta okozni, hogy egy masik program is hasznalta a cache-t a meres ideje alatt. Torekedj arra, hogy az EVEREST bench merese kozben a leheto legkevesebb masik program fusson, illetve ami megis fut, az inaktiv legyen. Minden szamit, virusirto, service-ek, halozati forgalom, stb.
AIDA64.com
-
Balala2007
tag
válasz Picturemaker #1102 üzenetére
Pentium E5200-as procinal tudunk ilyenrol. (Az egy Penryn alapu ketyere, amibol kihagytak az SSE4.1 tamogatast.) Ha errol van szo, akkor a kovetkezo benchmark frissitesnel javitva lesz.
AIDA64.com
-
Balala2007
tag
válasz #95904256 #1709 üzenetére
A memoria kesleltetes tesztnel egy lancolt listat hasznalunk, ahol az elemek a kovetkezo elem memoriacimere mutatnak, kiveve a legutolso elemnel, ami a legelsore mutat. A tesznel ezt a listat jarjuk be, es kiszamoljuk mennyi ideig tart atlagosan a kovetkezo elemhez eljutni:
...
mov eax, [eax]
mov eax, [eax]
mov eax, [eax]
...A memoria kesleltetesnel az EVEREST 16MiB-on elhelyezkedo listat hasznal, ahol ez egyes elemek kozott 1024 byte van -- es a legutolsot kiveve -- mindig eggyel nagyobb cimu szomszedra mutatnak. Olyan ertelemben "linearis", hogy monoton novekvo cimeket hasznal, de a lista elemek kozott 1KiB hely van.
Bar a legtobb CPU nem szokott 1KiB-ra elore olvasni, a Nehalem prefetcherei mar kepesek ezt a modszert bizonyos korulmenyek kozott atverni, ezert ott egy kicsit bele kellett mar "piszkalni".
AIDA64.com
-
Balala2007
tag
válasz #95904256 #1712 üzenetére
A Nehalem IP prefetchere lett "tul okos". IP prefetcher a Conroe ota letezik, de a Nehalemben kiterjesztettek a hatokoret, tavolabbra is mukodik, es ez mar kepes volt atverni a rutinunkat egy bizonyos kod konfigracioban. (Az EVEREST memoria rutinjai nem bedrotozottak, hanem egy belso assembler helyben gyartja le a procikhoz szukseges verziokat.) A fix annyi volt, hogy ezt a kodot kihagyjuk Nehalemen es a leszarmazottain.
A hw prefetcherek alapbol mukodni szoktak, hacsak ki nem kapcsoljak az MSR-ek atirasaval.
[ Szerkesztve ]
AIDA64.com
-
Balala2007
tag
válasz #95904256 #1746 üzenetére
Az direkt van, hogy nem minden processzoron ugyanaz a kod fut. Meg azonos utasitaskeszlet eseten is tekintettel kell lenni az egyedi sajatossagokra, pl. pipelined-e az FPU, milyen az FXCH kezelese, stb.
Ez a store-forwardingos dolog nagyon furcsa... Kerlek ket eltero mukodesu procirol masolj be ide a topikba 1-1 EVEREST CPUID dumpot (jobbklikk alul a Copyright-on -> CPU debug -> CPUID & MSR dump), es ird mellejuk, hogy melyiken milyen mukodest tapasztaltal.
AIDA64.com
-
Balala2007
tag
-
Balala2007
tag
válasz Oliverda #1825 üzenetére
A memoria bench ertekeket illetoen nekem ugy tunik, scientia keveri az elmeleti memsavszel fogalmat a kihasznalhatoval. Igaz, hogy mindket konfigban hasonlo memoriak vannak, kozel egyforma elvi savszellel (EVERESTben az Alaplap/Alaplap/Memoriabusz tulajdonsagai alatt nezheto meg), de hogy ezekbol mennyit tud tenylegesen kihasznalni egy egyszalas alkalmazas, az mar hw implementacio fuggo, es pont ezt mutatja meg az EVEREST. Mind a ket procin a szamara kedvezobb savszel mero rutin fut a tudtunkkal leggyorsabb verzioban. Ha felbukkanna egy gyorsabb kod K10-re (tobbszal es realtime priority nem er), akkor orommel lecserelnenk arra (bar erre eleg keves eselyt latunk, eleg sokmindent vegigprobaltunk mar).
A cache-eknel egyreszt tul lassu lenne, ha keresgelnenk mekkora meretu blokkot hasznaljunk, masreszt meg altalanossagban nem is mindig lehet szamitani arra, hogy lesz "lapos" resze az atviteli gorbenek. (ket pelda akosf-tol 1, 2) Igy mi inkabb a CPUID-bol olvassuk ki a cache meretet, es azt hasznaljuk.
Mivel non-temporal write-ot hasznalunk, ezert ritkan, de elofordulhat, hogy write gyorsabb, mint a read. (Bizonyos K7-eseknel tipikus volt anno...)
[ Szerkesztve ]
AIDA64.com
-
Balala2007
tag
Komoly kulonbseg van az AES-NI hasznalata es az anelkuli AES teljesitmeny kozott:
AMD FX-8150, CPB Off
AES-NI Off AES-NI On
32b 117.4 MiB/s 2376.0 MiB/s
64b 128.3 MiB/s 2376.2 MiB/s
Intel i7-2600, Turbo Off, C1E Off
AES-NI Off AES-NI On
32b 133.1 MiB/s 2494.2 MiB/s
64b 158.0 MiB/s 2426.9 MiB/sAES256 ECB mode encrypt, az AIDA64 2.20-ben kiadott B398-as bench modullal merve a fejlesztoi toollal, Win7+SP1 alatt, 1 thread eseten, RAM-ra vonatkoztatva.
[ Szerkesztve ]
AIDA64.com
-
Balala2007
tag
Pl. egy bizonyos kódolási sebesség felett talán már a Ram sebessége is limitálhat.
Az a kodolando adat mennyisegetol fugg. Ha nem fer bele a cache-ekbe, akkor tobb szalat esetleg mar nem tud ellatni a RAM.Előbbi azt jelenti, hogy 1 processzormagon futott ?
Igen.Utóbbi pedig, hogy a kódolás a ramból a ramba történt ?
Igen, pontosabban az L1D-be, mivel csak 8KB-ot mertem, hogy a legjobban latszodjon a kulonbseg.Nincs tapasztalatom a Bitlockerrel, de pl. itt erezheto elonyt mertek ki.
Az AES-NI mellett megemlitenem meg, hogy nem csak a sebessege, hanem a biztonsaga is jobb. Az egyszerubb/gyorsabb AES kodokat elvileg le lehet "hallgatni" (side channel attack) a konstans tablak hasznalata alapjan, es az AES-NI kifejlesztesenek egyik legfontosabb motivacioja ennek a kikuszobolese volt.
AIDA64.com
-
Balala2007
tag
Sajnos a reprodukalhatosag hianya miatt egyelore nem tudtuk beazonositani, hogy milyen korulmenyek miatt eshet vissza BDZ konfigon az L2 read sebessege.
Ez belassulas nem jelentkezik mas, pl. az alap frekvencian? Instabilitas helyett inkabb az lenne a tippunk a jelensegre, hogy egy masik thread ugyanazt az L2-t erolteti hasznalni, mint az AIDA64, es osszeakadnak. Ha modod van ra, probald ki minel kevesebb hatter process futtatasa nelkul a merest, pl. egy friss Windows installal.
AIDA64.com
-
Balala2007
tag
válasz dergander #3204 üzenetére
- Reprodukalhato ez az eredmeny?
- A tobbi AIDA64 benchmarkban (pl. Julia) is jelentkezik hasonloan gyanus ertek?
- A Win8.1 az a 9600-as vegleges build vagy a Preview?
- Downclockolva mondjuk 3GHz-re aranyosan kisebb az eredmeny?
- Futott valami az AIDA64-en kivul a hatterben?AIDA64.com
-
Balala2007
tag
válasz Picturemaker #3421 üzenetére
Egy más jellegű kérdés: a memória és cache tesztnél miért van az, hogy a másolás gyorsabb, mint az írás? A másolás nem olvasás+írás?
Az AIDA64 3.00 ota a read es a write 64MiB-ot, a copy 32+32MiB-ot allokal threadenkent. A cache-eknel eleg bonyolult a keplet, de az mindenhol igaz, hogy a copy a read es write meretet hasznalja, felet olvassa, felet irja.
Ennek egyreszt az az ertelme, hogy az atvitelnel gorbenel szimmetrikusan ugyanott torik le a cache hataroknal a copy, ahol a read es write is, masreszt -- foleg cache-eknel -- ha dedikalt read es write eroforrasok vannak, akkor azoknak a hatasa egyertelmubben latszik.AIDA64.com
Új hozzászólás Aktív témák
- Videó stream letöltése
- Azonnali informatikai kérdések órája
- Ubiquiti hálózati eszközök
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Motorola Edge 40 neo - színre és formára
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Autós kamerák
- Android alkalmazások - szoftver kibeszélő topik
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Ukrajnai háború
- További aktív témák...