Keresés

Hirdetés

Új hozzászólás Aktív témák

  • Balala2007

    tag

    válasz dezz #2044 üzenetére

    Nyugodtan megbizhatsz a CPUZ latency ertekekben, ezt mint EVEREST fejleszto mondom. :) Ugyanazt a lancolt listas merest vegzi mind a ketto, (illetve ha akosf progijat is beleszamolom, akkor mind a harom.) Az a gond, hogy a memlatency erteke eleg sok mindentol fugg, emiatt a teljes kepet nem lehet 1db skalar ertekkel jellemezni. Szamit az alignment; az irany, hogy novekvo, csokkeno vagy kovetkezetlenul ugral a cimek kozott; a hasznalt memoriaterulet merete, hogy belefer-e valamelyik cache-be; illetve leginkabb az ugras merete, (ez a ''stride'') azaz mekkora tavolsag van 2 cim kozott.
    Ezen parameterek alapjan lehet a latency matrixokat szerkeszteni, amit az EVEREST is meg tud tenni a developer verzioban. :) Ime egy pelda: [link], illetve ugyanerrol a geprol a CPUZ dumpja: [link] Latszik, hogy a CPUZ a backward linkelt listat hasznalja (felteszem azert, hogy egy-ket korabbi prefetchert atverjen, amik csak novekvo cimek eseten tudtak eloreolvasni), es annak egy reszmatrixat irja ki, a techreport pedig ebbol a matrixbol onkenyesen kivette a 8MiB blokkmeretu 512 byte stride-os erteket.
    Az EVEREST az elorefele lancolt, 16MiB blokk, 1024 byte-os stride-os erteket irja ki a GUI-n.
    Mind a ketto ''igazi'' ertek, csak mas parameterekkel futott a meres.

    AIDA64.com

Új hozzászólás Aktív témák