- iPhone topik
- Samsung Galaxy Buds3 Pro - szárat eresztettek a babok
- Google Pixel topik
- Samsung Galaxy S21 Ultra - vákuumcsomagolás
- Samsung Galaxy A54 - türelemjáték
- Yettel topik
- Samsung Galaxy Z Fold3 5G - foldi evolúció
- Apple iPhone 17 Pro Max – fennsík
- One mobilszolgáltatások
- Farmerbe öltözik a Redmi Pro Max
Új hozzászólás Aktív témák
-
Petykemano
veterán
#zen5 #zen 5 #magszám
Roppant érdekes.
Más fórumokon még élénken vitatják, hogy vajon a Zen5 hoz-e magszám emelkedést - elsősorban a CCX-en belül értve. Nemhogy 16, de még a 12 magos CCX is felmerül, amit a Mi300-ban elérhető 24 magból deriválnak.Legutóbbi videójában AdoredTV is megállapította, hogy a 16 magos CCX jelenleg valószínűtlen. Valójában ezen kívül kevés megállapítás hangzott el.
Vajon mi értelme/célja lenne a CCX-en belüli magszám emelkedésnek? A CCX-en belüli magok L3$-en keresztül tudnak egymással adatot megosztani, egymás közötti késleltetésük alacsony. Tehát 8-ról 12 vagy 16-ra növelni az egy L3$-hez kapcsolt vagy CCX-en belüli magok számát - ennek értelme akkor és ott lenne, amikor olyan alkalmazás fut, ahol a szálak kommuninálnak, adatot osztanak meg egymással és egy ilyen alkalmazás 8 magon túl terjeszkedik, vagy legalábbis több erőforrást használna.
Világos, ha jelenleg egy ilyen élénk szálközi kommunikációval működő program túlterjeszkedne a 8 magon, akkor abból olyan bedadogás (lassulás) keletkezne, mint amit a 4 magos CCX-szel rendelkező Zen processzorok esetén láttunk.
12 vagy 16 magos CCX esetén a program máris terjeszkedhetne 8 magon túl anélkül, hogy a megnövekedő késleltetés miatti teljesítményvesztést el kéne szenvednie.De ennek a célnek az eléréséhez vajon valóban a CCX-en belüli magok, vagyis az L3$-hez kapcsolt magok számának növelése az egyetlen és leghatékonyabb útja?
Leginkább amiatt vetődik fel bennem ez a kérdés, mert szerintem míg a játékok terén ennek hosszútávon - ha a programok is úgy akarják és az Intel is felkészült - lehet, hogy lehet valamilyen pozitív hatása, addig szerintem a szervereknél szinte semmi. Miért tenné meg akkor az AMD?
Mielőtt válaszolni probálnék a kérdésre, elmondanám az alternatívát:
Tehát szerintem szerverek esetén nem sok haszna volna a 8 helyett 16 magos CCX használatának (most itt a lapkaméretet még hagyjuk)
Ha viszont desktopon - vagy a ThreadRippernél - a minimum 2 CCD-s összeállításoknál szempont a CCD-közi késleltetés csökkentése, akkor azt egy IOD-hoz kapcsolt (3D) SLC-vel is meg lehetne oldani, ami kicsit ahhoz hasonlóan működhetne, ahogy a Navi31 esetén is az MCD-be épített infinity cache tulajdonképpen a MEmóriavezérlő előtti bufferként fogható fel. Ezt használhatnák a CCD-k, vagy CCD helyett egy GCD is, vagy az IOD-ba épített IGP.Egy ilyen megoldás enyhítené a CCD-CCD kommunikáció késleltetését és tudná tompítani a másik CCD-re való szál-átugrás problematikáját. Megkockáztatom, hogy az AMD hybrid architektúrájának jelenleg kritizált problémáit (a 3DCCD-ről szál kiszorulása vagy rossz ütemezése miatti dadogást) enyhítené. Persze az IOD-ra helyezett SLC-nek akkor tényleg méretesnek kellene lennie.
Viszont ha ennek ugyanúgy nincs haszna a szerverpiacon, akkor miért csinálná ezt az AMD? Hiszen soha semmit nem csinálna kizárólaga desktop piacra.
Erre a kérdésre a válasz az lehetne, hogy a CCD-CCD kommunikáció késleltetésének csökkentése inkább mellékterméke lehetne az elsősorban a mobil piacra gyártott chiplet APU-knak, amelynél a GCD külön van gyártva, és egy szincén külön gyártott MCD-hez, vagy más esetben IOD-hoz kapcsolódik, amely valamilyen módon tartalmazza a komolyabb GCD a korlátozott memóriasávszélességgel rendelkező környezetben való működéséhéz szükséges infinity-cache-t.Mi viheti rá mégis az AMD-t arra, hogy 12 vagy 16 magos CCX-ez készítsen?
A lapkaméret, vagy költséghatékonyság.Sajnos ugye számokat egyik elképzelés mellé sem tudok rendelni. Bár azt gondolnám, hogy a 3D tokozás a következő 1-2 évben csupán 1-2 dolláros többletköltséggé fog redukálódni és elég sokat lehet majd nyerni azon is, hogy nem a legfejlettebb gyártástechnológiát használod. Azt sem tudom, hogy vajon 16 mag egy L3$-hez rendelésének milyen többletköltsége van: szükséges-e a méret kétszeresre növelése úgy is, hogy előzőleg duplázták az L2$-t? Kell-e növelni az asszociativitást? Mennyivel nagyobb tag szekcióra van szükség, stb És ugyanúgy nem tudom, hogy ha ugyanezt az L4$ esetén kell megvalósítani, akkor az mit jelent.
De egy olyat el tudnék képzelni, hogy ha az AMD lecsökketi a bázis L3$ méretét a Zen5-ben - adabszurdum 0-ra - akkor annyira kicsi lenne már a CCD, hogy azért muszáj emelni a magszámot, mert különben túl nagy lenne rá a 35mm2-es v-cache. (már amennyiben azt továbbra is N7-en gyártják)
Azon sem lepődnék meg, hogy ha a következő 1 évben több különböző Zen5 lapkamérettel és L3$ konfigurációval találkoznánk a szivárgásokban.
Új hozzászólás Aktív témák
- Akciós Windows 10 pro + Office 2019 professional plus csomag AZONNALI SZÁLLÍTÁS
- BESZÁMÍTÁS! MSI B760 WIFI i9 14900KF 32GB DDR5 1TB SSD RTX 3090 Trinity OC 24GB LIAN LI PC-O11D 750W
- Új Razer 16 QHD+ OLED 240Hz i9-14900HX 24mag 32GB 2TB SSD Nvidia RTX 4090 16GB 175W Win11 Garancia
- Új Dell 14 Inspiron 5435 FHD+ Ryzen7 7730U 4.5Ghz 16GB 512GB SSD Radeon RX Vega 8 Win11 Garancia
- ÁRGARANCIA!Épített KomPhone i9 14900KF 32/64GB DDR5 RAM RTX 5070 12GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: NetGo.hu Kft.
Város: Gödöllő
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest