Hirdetés

  2. Fórumok
  3. Lokál
  4. AMD CPU-k jövője - amit tudni vélünk
Legfrissebb anyagok
PROHARDVER! témák
Mobilarena témák
IT café témák
GAMEPOD témák
Keresés

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

  • #6995 HSM félisten S_x96x_S #6976
    Új Válasz #6995
    Ú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 S_x96x_S #6976 üzenetére

    Teljes mértékben egyetértek vele. :K
    Nem véletlen írtam már januárban: "a skálázódási probléma megoldási kényszerének áthárítására a szoftverekre, szoftverfejlesztőkre" [link] .
    Illetve: "...a hardveresek átdobták a problémát a szoftvereseknek, amiből ritkán szoktak jó dolgok kisülni" [link] (Itt írtam az ARM megoldásáról is.)
    De 2021 közepéről is érdekes az utolsó bekezdés innen: [link] .

    "persze ezzel majd az AMD-nak is meg kell küzdenie majd"
    Úgyérted a szoftverfejlesztőknek, akiknek +1 speciális architektúrára kell majd optimalizálni? ;]
    Egyébként szerintem lehet(ne) ezt okosan csinálni, hogy kellőképpen hasonlóak legyenek a magok ahhoz, hogy ne legyen ennyire kényes kérdés, mi, hova ütemeződik. Tehát a jó irány szerintem az lenne, ha azonos módon kellene optimalizálni a magokra, elég lenne az, hogy a magasabb prioritású feladatok a gyorsabb, az alacsonyabbak a lassabb magokon futnának és a szoftverfejlesztőnek nem kellene másra már figyelnie.

    #6977 Petykemano: Ha jól tudom, ARM alatt az EAS rendszer segít be [link] . (Itt is ír pár dolgot, ami talán hasznos [link] .)
    De ez nem teljesen ugyanaz a probléma, hiszen mobilon a prioritás az energiatakarékosság, míg az Alder esetében a marketing khm, innováció, akarom mondani "throughput". Tehát röviden papíron az ARM azt csinálja, hogy arra a magra igyekeznek rakni a feladatokat, ami a leghatékonyabban el tudja végezni azokat. Abba most ne menjünk bele, hogy ez a rendszer sem olyan szép a gyakorlatban, mint így leírva.... :)

    #6980 S_x96x_S: "az ütemezés - szerencsére szoftveres, amin könnyű változtatni."
    Az Alder problémájának azt a részét nem fogja az ütemező megoldani, hogy a szoftveredet mire optimalizáld, pl. van-e HT vagy nincs, vagy befékezi-e a buszt a kis mag vagy sem....
    A Zen5-féle megoldásnál majd meglátjuk, hogyan sikerül összerakni a rendszert, lesznek-e hasonló gubancok vagy sem.

    #6986 Petykemano: Csak a Rembrandt nem hinném, hogy "elvinne" a lábán egy platform startot. :N Az még AM4-nél is csak egy erős középkategória lenne. Kéne mellé még valami, ami kicsit nagyobbat szól. :K

    #6993 Pakmara: Pl. gyártási/tervezési költség optimalizálása. Az olcsóbb termékbe elég kevesebb periféria vezérlő/PCIe sáv, a drágábba viszont több kell, így pedig egy lapkával megoldják mindkét igény lefedését. Mint a processzoroknál, 8 magig 1 CCD-t, 8-16 között kettőt raknak rá.

  • #6983 poci76 aktív tag S_x96x_S #6976
    Új Válasz #6983
    Ú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

    poci76

    aktív tag

    válasz S_x96x_S #6976 üzenetére

    Tapasztalatom szerint korántsem ennyire problémás az E és P magok ütemezése. A P magon két szál fut, így az egy szálra jutó számítási teljesítmény nincs messze egy E magra jutó számítási teljesítménytől, így minden optimalizálás nélkül is egész jól ki lehet használni a processzort. Nekem nagy meglepetést okozott a 12900K a 10850K után, mert nem számítottam túl nagy sebességnövekedésre.

    Egy szimuláció, amivel nézni szoktam, hogy milyen gyors a proci, a következő futási időket produkálta. A szimulátor nincs optimalizálva heterogén magokra (annál is inkább, mert 2017-es):

    Ryzen 3 1200 => 119.753 seconds
    Ryzen 7 1800X => 77.733 seconds +54%
    Threadripper 1920X => 53.300 seconds +46%
    Core i9 10850K => 49.072 seconds +9%
    Core i9 12900K => 28.737 seconds +65%

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

    > vagyis, hogy 2 -nél több chipetet tud-e kezelni a desktopos io-die

    Ezt a kérdést kiküszöbli Zen4+Zen4D, ami 2023Q1-ben gyártható.

    > Ami furcsa lesz nekem, hogy míg az AVX-512 támogatást az AMD kiemeli majd ...

    AdoredTV utolsó videója szerint a Genoa és a Bergamo is támogatni fogja az AVX512 utasításokat, 256b-es Load/Store műveletekkel, de a tényleges művelet végrehajtás elvileg 512bites lesz.
    Az AMD helyében én azt csinálnám, hogy a Zen4D esetén a műveletvégrehajtást is kettévágnám 256bites szeletekre. és akkor kisebb a mag, de az ISA támogatás ugyanaz.

    > Agner on Aldder Lake

    AZ elején említi, hogy azért nehéz tájékozódnia a programnak vagy az operációs rendszernek, mnert a DRM miatt egységesíteni kellett a P és E magok CPUID-jét. Bármilyen hülyén hangzik is, de szerintem ez egy nem várt probléma az Intel részéről, amire csak egy rossz megoldást tudtak adni. Azt gondolom, hogy ha nem CPUID-vel, akkor valamilyen más módon megoldást fognak találni arra, hogy a magok megkülönböztethetők legyenek egymástól.

    Másrészről a Ryzen és szerintem az Intel cpu-k esetén is valahogy tudatható a rendszerrel, hogy melyik a legjobb és második legjobb mag. Az más kérdés, hogy ezzel aztán mi mit kezd, de nyilván ez a fajta megkülönböztetés szintén kiterjeszthető.

    Harmadrészt sajnálatos, hogy Agner Fog irományában egy árva szó nem esik az Arm-ról. Pedig az ARM esetén évek óta létezik a külön clusterba szervezett kis és nagy magok megkülönböztetése, a klaszterezés első generációja a big.LITTLE volt, most tudtommal a DinamIQ néven fut. De még ha feltételezzük is azt, hogy ez annyira egyszerű, mint ahogy az Intel Thread Director csinálja, vagyis hogy a Foreground applikáció fut a nagymagos clusteren és minden más background folyamat a kismagos clusteren, amiről ugye Agner is azt mondja, hogy ez desktop környezetben nem jó megközelítés. Akkor is ma már a nagymagos clusterben is kétféle mag van: a Cortex X1/X2 típusú és a Cortex A78/A710. Ebben az esetben az Arm hogy csinálja? hogy különböztetik meg ezeket a magokat? Teljesen véletlenszerű lenne, hogy a nagymagos clusterben a programszálat az X_ vagy a A7_ típusú mag kezeli?

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