Ú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
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Bambu Lab 3D nyomtatók
- Hobby rádiós topik
- Futás, futópályák
- Xbox Series X|S
- Autós topik látogatók beszélgetős, offolós topikja
- Friss videón a RoboCop Rogue City - Unfinished Business
- Motorolaj, hajtóműolaj, hűtőfolyadék, adalékok és szűrők topikja
- A fociról könnyedén, egy baráti társaságban
- Milyen egeret válasszak?
- További aktív témák...
- Bomba ár! Dell Latitude 5490 - i5-8GEN I 8GB I 256GB SSD I 14" FHD Touch I HDMI I Cam I W10 I Gari!
- Bomba ár! Dell Latitude 7280 - i7-7GEN I 16GB I 256SSD I 12,5" FHD Touch I Cam I W11 I Garancia!
- Bomba ár! Dell Latitude 5590 - i5-8GEN I 8GB I 256SSD I 15,6" FHD I HDMI I CAM I W11 I Gari!
- LOQ 15IAX9 15.6" FHD IPS i5-12450HX RTX 4050 16GB 1TB NVMe magyar vbill gar
- Bomba ár! Lenovo ThinkBook 15 G2 - i5-1135G7 I 16GB I 512GB SSD I 15,6" FHD I Cam I W11 I Gari!
- Telefon felvásárlás!! Xiaomi Redmi Note 13, Xiaomi Redmi Note 13 Pro, Xiaomi Redmi Note 13 Pro+
- MacBook felvásárlás!! Macbook, Macbook Air, Macbook Pro
- Bomba ár! HP EliteBook 830 G7 - i5-10GEN I 16GB I 512GB SSD I HDMI I 13,3" FHD I Cam I W11 I Gari!
- Lenovo Thunderbolt 3 kábel (4X90U90617)
- 4 év gari - magyar bill. - Lenovo ThinkPad Z13 G1 - AMD Ryzen R7 Pro 6850U, 13.3" 2.8K OGS érintő
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest