Hirdetés

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

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

  • #5288 Petykemano veterán
    Új Válasz #5288
    Ú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

    (Ha jól értem)
    Az AMD olyan szabadalmakat jelentetett meg, amely a kis és nagy magok közötti váltást Hardveresen, az OS vagy az App tudta nélkül valósítja meg.
    [link]

    "TL;DR;
    With these patents AMD is solving two things, which is a very ingenious approach
    1. big.LITTLE architecture that is virtually indistinguishable to the OS scheduler with thread migration done in HW (in contrast to ARM approach)
    Using perf monitor to migrate CPU registers, thread state and execution to big core in HW itself without OS knowledge https://www.freepatentsonline.com/y2021/0173715.html Issue here is that only the big or small core is available at any time not both, but not really an issue on desktop if you already have 16 cores to begin with 2. Big and small cores have different levels of ISA support (i.e the small cores cannot support AVX for example and the big cores can). ( in contrast to Intel ADL approach )
    Using illegal opcode exception in small core to seamlessly migrate the thread state and execution to big core without OS knowledge https://www.freepatentsonline.com/10698472.html "

    Nekem egy kicsit fura. Olyan, mintha az AMD több big.LITTLE projektet is futtatna egyszerre.
    Legutóbbi ábrán inkább úgy tűnt, mintha lenne big cluster + LITTLE cluster és a fabrichoz kapcsolódnak.

    Ez a megfogalmazás, hogy a programszál költöztetése úgy történik meg, hogy valójában a kis és nagy mag nem elérhető egyszerre, ez sokkal inkább arra emlékeztet, ami ezt megelőzően "low-feature / high feature core" címszóval jelent meg. De egyébként 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?
    Egy ilyen megközelítés a fogyasztáson valószínűleg segít, de a tranzisztorigénye a "kis mag" működésnek nem kisebb.

    van ellenérv is:
    "This sounds terrible from the OS kernel point of view. The physical CPU suddenly getting faster or slower without OS intervention is exactly what you don't want to do. This already happens with hardware-controlled turbo, but this will make this even more complicated (previously you could figure out performance by comparing clock speed, now you have no idea how the little core stacks against the big core)."



    "It seems like you are possibly massively over-estimating the amount of floating point used in a JavaScript execution thread vs. the amount of all integer used in actually displaying the GUI. The amount of work to display the GUI is often huge compared to what is actually running in the GUI. Also, I don’t know if anyone is talking about having a core with absolutely no FP resources. If you have a separate small core with a scalar FP unit or even just a small narrow 128-bit unit, that could be used to handle any floating point instructions. Technically they could emulate any vector instructions with a scalar unit; it would just be slow. You could actually emulate floating point units with integer units, but that would be excruciatingly slow.
    [...]
    Perhaps we are going excavator style with multiple small cores sharing the vector execution resources. It could have a small scalar FPU that handles everything except actual vectorized instructions such that the big vector units stay powered down. Intel has certainly had power issues with processors supporting AVX512, so it would make sense to handle very light loads with a small unit, even if it takes multiple clocks, instead of taking the time to wake up the big unit."


    Ez is érdekes ehhez. De ebből nekem nem igazán jön ki a "zen 5 + Zen4D"

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