Hirdetés

  2. Fórumok
  3. Lokál
  4. AMD CPU-k jövője - amit tudni vélünk
Keresés

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

  • #8610 HSM félisten hokuszpk #8606
    Új Válasz #8610
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    HSM

    félisten

    válasz hokuszpk #8606 üzenetére

    "Szvsz dupla méretú L1 -ből kevesebb adat csorog le."
    512KB-al kevesebb lecsorgásról beszélünk magonként, az összesen 4MB. Ez szerintem nem fog csodát tenni a 32MB L3-hoz képest.

  • #8607 Petykemano veterán hokuszpk #8606
    Új Válasz #8607
    Új hozzászólás
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Petykemano

    veterán

    válasz hokuszpk #8606 üzenetére

    > az L3 ha jóltévedek victim cache. azaz az előtte lévő szintekből kicsorgó adatokat tárolja.
    > Szvsz dupla méretú L1 -ből kevesebb adat csorog le.

    Igen, de ez magonként csak +0.5MB, egy CCX-ben összesen 4MB többlet. Ez magonként 0.5MB-nyi adat gyorsabb hozzáférését teszi lehetővé, mivel az a 0.5MB nem az L3$-ben, hanem az L2$-ben van.

    De a Zen architektúra achilles sarka nem ez, hanem a chiplet felépítés miatt magasabb késleltetésű memóriaelérés. (Nem tudom esetleg a sávszélesség jelenthet-e bármilyen limitációt, mindenesetre itt van olyan Genoa konfiguráció felvázolva, ahol 2 GMI linken kereszül csatlakozik egy CCD) Az, hogy a memóriavezérlő elérése nem valamilyen belső buszon közelre történik, hanem szubsztráton keresztül, biztosan limitáló tényező.

    A lényeg, hogy a 32MB helyett 96MB L3$ viszont nem 4MB valamiyel gyorsabb elérését teszi lehetővé, hanem 64MB-ét pont azon a ponton, ahol a legérzékenyebb.

    Persze nyilván az L3$ cache méretére igaz a csökkenő határhasznosság elve.

    > Zen5 -re volt valami hír, hogy összevonják az L2 -t ;
    > ha igaz a hír megkockáztatom, hogy bazi nagy közös L2 mellett akár el is tűnhet az L3.

    Szerintem 8 mag számára közös L2$-t csinálni megfelelő gyorsaságban és hogy akkor is kielégítő teljesítményt nyújtson, amikor a magok nem valami közös problémán dolgoznak, nehéz lehet.
    A szóbeszéd szerint a szerverek szeretik a gyors privát L2$-t.

    Az L3$ eltűnhet, de valószínűbbnek tartom, hogy 3D stackelik.
    Az még esetleg lehetséges út, hogy elengedik a szubsztráton keresztüli kapcsolatot (SerDes) és az IOD és a CCD között a NAvi31-nél látott módon (MCD-GCD) teremtenek szélessávú kapcsolatot. Ebben az esetben a stacked L3$ már mehetne az IOD-ra is és akkor az minden CCD-t ki tudna szolgálni. Ez abból a szempontból is, jó volna, hogy a CCD helyett az IOD-nak lehet kliense egy GCD is, vagyis egy IGP és akkor máris sikerült megoldani az APU-k 3D stackelt v-cache/infinity cache kérdését is.

    Azt persze nem tudom, hogy ez tényleg jó irány-e. L3$ nélkül azért az egész félkarú óriás. EGy ilyen bonyolult packaging drága is lehet, meg növelheti a hibaarányt is, meg volumenkorlátos is lehet ahhoz képest, ha van egy közepesen jó, de minden extrát nélkülöző alap lapkád, amit végtelen mennyiségben, hibátlanul, olcsón tudsz kipumpálni és szükséges esetén, kisebb volumenben ezzel-azzal dekorálni.

    Az AMD eddig megfigyelt kockázatvállalási hajlandósága mellett azt gondolnám, hogy inkább valószínűtlen a kizárólag egzotikus kialakításra, 3D packagingre építő megközelítés nagy volumenben, olcsón gyártható jó mainstream bázislapka nélkül. (És szerintem L3$ nélkül nem lenne jó)

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