Ú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
- Ohh Lenovo ThinkPad P15 G2 Tervező Vágó Laptop -75% 15,6" i5-11500H 32/1TB RTX A2000 4GB /1 Millió/
- UHH! HP EliteBook 850 G8 Fémházas Multimédiás Laptop 15,6" -40% i7-1165G7 16/512 Iris Xe FHD EU-HUN
- IBM PS/1 2168-552 486SX-25
- ASUS ROG Strix RTX 2080 Ti OC 11GB
- Acer Swift 3 (SF314 54) i5 / 8GB RAM / SSD / FullHD / kiváló állapotban!
- HP EliteBook 830 G11 Üzleti erő kompromisszumok nélkül!
- BESZÁMÍTÁS! Apple MacBook Pro 16 M4 Pro 24GB RAM 512GB SSD - garanciával hibátlan működéssel
- BESZÁMÍTÁS! Lenovo Legion 5 15ITH6H Gamer notebook - i7 11800H 16GB DDR4 512GB SSD RTX 3060 6GB W11
- ÁRGARANCIA!Épített KomPhone Ryzen 7 9800X3D 64GB RAM RTX 5080 16GB GAMER PC termékbeszámítással
- Azonnali készpénzes félkonfig / félgép felvásárlás személyesen / csomagküldéssel korrekt áron
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest