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

  • #5303 HSM félisten Petykemano #5288
    Új Válasz #5303
    Ú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 Petykemano #5288 üzenetére

    "ez utóbbi tulajdonképpen miben különbözik attól, mintha mondjuk egy mag áramtalanítaná az AVX512 vagy egyéb részeit (regisztereket, cache-t, ALU-kat stb), amit épp nem használ"
    Abban, hogy ami ott van, azt nem tudod áramtalanítással olyanná tenni, mintha nem lenne ott. Pl. a mag többi részét is hozzá kell igazítani, a jelutakat is hosszabbítja, így kikapcsolva is indirekten növeli a többi rész fogyasztását.

    Ez az OS tudta nélküli kis mag használat viszont hasznos lehet áramfogyasztás csökkentő célokra, az Arm-féle megvalósításnak is volt ilyen működési módja [link] . Ebben kevesebb elvérzési lehetőséget látok, mint a konkurens elképzelésben. Bár a leghasznosabb egy kapcsolható megoldás lenne, ha működhetne automatikus átkapcsolással, de ha olyan a munkafolyamat, mondjuk egy reboot árán átkapcsolhatnád, hogy elérhető legyen minden magod külön külön a takarékos mag utasításkészletével.

    Egyébként vicces valahol (miközben mérnöki szempontból tökéletesen érthető és szükségszerű), hogy a mai napig előfordulnak ilyen problémák a nem heterogén felépítés miatt. Egy CCX itt, egy CCX ott, egy erős mag itt, egy gyengébb mag ott... És ezek még viszonylag hasonló képességű holmik voltak mondjuk egy tervezett 8+16-os Alder Lake utódhoz képest... :DDD Lesz itt felfordulás még emiatt szvsz. :K

    #5289 Petykemano : A CMT koncepciója szvsz jó volt. A Bulldozer piaci szerepléséhez más, szerencsétlen körülmények is hozzájárultak. Egyébként logikusnak tűnik az osztott FPU az AVX512-re. Kérdés, ezzel nem-e dobjuk kukába a használatának előnyeit. Illetve az első generációs Zen fele szélességű FPU-ja sem bizonyult rossz kompromisszumnak, lehet lenne értelme az AVX512-nél is bevetni, elkerülendő a mag túlzott "kiszélesedését". :K

  • #5295 Petykemano veterán Petykemano #5288
    Új Válasz #5295
    Ú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 Petykemano #5288 üzenetére

    big.LITTLE híradó

    Hát tiszta hülyék vagyunk! Csodáljuk itt az ARM SVE2-t, hogy hűűű, meg háá, milyen jó, hogy az utasításhossza független a hardver feldolgozó-hosszától.
    De hát ez eddig is létezett az x86-ban is.

    Emlékszünk?
    "A Jaguar ennek támogatását egy 128 bites FADD és egy szintén 128 bites FMUL egység segítségével oldja meg, vagyis a 256 bites AVX utasításokat két 128 bites részre osztva hajtja végre a rendszer, tehát gyorsnak nem nevezhető, de egy alacsony fogyasztású processzormag esetében ez is jóval több a vártnál. Természetesen a 128-128 bites FADD és FMUL egység a 128 bites SSE utasításokra pozitív hatással lesz, hiszen azokat a Bobcattel ellentétben a Jaguar már nem osztja két részre."
    [link]

    Tehát a Jaguar képes volt 256bites AVX utasítások végrehajtására, csak 2 órajelciklusra volt hozzá szüksége.
    Aztán nem is olyan rég:

    "The key highlight improvement for floating point performance is full AVX2 support. AMD has increased the execution unit width from 128-bit to 256-bit, allowing for single-cycle AVX2 calculations, rather than cracking the calculation into two instructions and two cycles. This is enhanced by giving 256-bit loads and stores, so the FMA units can be continuously fed."
    [link]

    Tehát a Zen is 4db 128 bites FP feldolgozóval rendelkezett, amiket össze tudott vonni 1db 256 bites AVX2 utasítás egy ciklusban történő végrehajtására. Akkoriban még volt is szó arról, hogy ennek annyi előnye van az akkor már 256bit hosszú FPU-val rendelkező skylake-kel szemben, hogy akár két különböző 128bites utasítást is végre tud hajtani 1 órajelciklus alatt.

    Tehát valójában biztos megvalósítható lenne az, hogy
    a) 4db 256bites fpu feldolgozó helyett 8 db 128 bites legyen és ezeket vonja össze. a zen1 => zen2 váltás esetén azonban 4db 128bites feldolgozó helyett 8db 128bites feldolgozó használata biztosan bonyolultabb és nehezebb lett volna, mint 4db 256 bites feldolgozó arról nem is beszélve, hogy nem is biztos, hogy ki lehetett volna használni. De ez most mindegy is
    b) Az AMD valószínűleg most is képes lenne 4db 256bites feldolgozót összevonva egy órajelciklus alatt végrehajtani 512bites AVX-512 utasításokat.
    Vagy akár arra is képes lehetne, hogy összevonás nélkül, 2 órajelciklus alatt hajtsa végre.
    (Más kérdés, hogy ennek van-e értelme)

    Mindenesetre az látszik, hogy akár x86 alapon is megvalósítható lenne az, hogy a kismag csak 2db 128bites FPU-t kap és ennek ellenére feature-kompatibilis marad AVX512 tekintetében az akár 4db 512bit hosszú FPU-val rendelkező nagy maggal. Csak ugyanazt az utasítást lényegesen lassabban képes végrehajtani.

    "The current rumored specs for Big.Little appear more or less like this in my opinion:
    Small Zen4 cores with 128-bit SIMD and big Zen5 cores with 512-bit SIMD.
    Zen4 4-track on 3nm => lower leakage, same frequency capability (smaller FPU requires less current)
    Zen5 5-track on 3nm => higher leakage, higher current capability (to feed larger FPU), thus higher frequency support at low/mid SIMD capability.

    8 Zen5 cores(Big core CCX), 4 Zen4 cores(Small core CCX) => similar strategy as Apple."
    [link]

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