Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Takovýho smetí a pak ti stejně vnutí chipset na desce protože to přece prodává desku :-(
Čipset na desce a konektivitu z něj. Takže máš moderní čipset a moderní CPU, ale do přední pozice lze vyvést jen "obstarožní" USB 5Gbps (případ u X570). Doufám, že u X670 se to zlepší.
To ale není problém čipsetu, X570 má těch 10Gbps USB portů relativně dost. To je problém výrobců MB.
A všiml si někdo že EPYC IO čiplet je v podstatě rozdělen na 4 kvadranty, které jsou téměř identické a každý z nich obsahuje více méně IO čiplet pro Ryzen? Samozřejmě až na nějaké drobné rozdíly. Docela chytré řešení.
Má na starosti tu část Vesmíru, kterou Vesmírní lidé nazývají
Bela, Quadra nebo 4. Sektor Vesmíru.
Problém je, že na Anandtechu to měřili a ty čtyři části serverového IOD tvoří 4 NUMA uzly, a pokud chce jádro přístup do paměti připojené mimo jeho domovské 2-kanály RAM, tak je tam výkonová penalizace daná latencí.
Takže oproti Zen1 ty NUMA uzly úplně neodstranili. Zen3 by mohl přinést opravdu unifikovaný 8-kanál řadič, který by zvedl výkon. Čas na vývoj měli. Protože Zen2 Rome má pořád jenom 4x 2-kanál.
A jak pomala mrdka to je, ze.. Hanba im! :(
Záleží na desce, některé ten 10Gb/s USB-C header mají, některé ne. To není problém chipsetu.
Co konkrétně je navíc v Chipsetu (třeba x570) proti IO čipletu?
Podle mě nic, grafika je nebo jde do CPU, SSD jde do CPU, zvukovka je externě nebo v GPU a LAN je v CPU.
Nevim, jak to děláte, ale u mě ty snímky rozklikávací nejsou, mám jen náhled na malé verze.
Ve FF mi to taktez nejde. Plus jeste:
>zaměříme na nic.
>x16 SedDes
Díky za upozornění. Vypadá to, že si editor při uložení vymazal kus kódu, který si automaticky generuje sám rozhraním pro obrázky. Až se zaktualizuje cache, mělo by to být ok.
Uz je to ok, ve strukture tranzistoru jsem vycetl i "zde neni Intelovo" :-)))
RE: "Toto řešení se zdá být dokonce elegantnější než přístup Intelu, který BMC připojuje k lince vyvedené z externího čipsetu. Tím sice ochrání „celistvost násobků“, ale na připojení externího čipsetu spotřebuje část linek, jimiž je vybaven procesor."
Nejsem si vedom, ze by Intel opustil koncept DMI. Ackoliv to vyuziva v zakladu PCIe protokol, tak na DMI se neda povesit neco, co neni chipset.. (videt to je napr. u 2S/4S desek, kdy prvni socket ma na DMI chipset, a ten CPU musi byt osaze, ostatni sockety nemaji DMI pripojeno nikam - ackoliv autor clanku se snazi navodit pocit, ze by snad tyto linky slo vyuzit. AFAIK nejdou.
Bez ohledu na to, zda k DMI je nebo není připojen čipset, je na procesoru DMI rozhraní stále přítomné, ve jmenovaných případech navíc zbytečně, a tím blokuje prostor pro další linky.
To DMI tam ale byt musi a je schvalne DEDIKOVANE, nad ramec 16/28/44 linek, stejne tak jako u amd je UMI nad ramec 16/20 linek v DT. A kde ho nemaj - tj. musi krast spojeni z PCIe (EPYC), tam to dela problem s tou nedostupnosti plneho poctu linek.
Takze si to zhrnme - AMD si vydlabalo na dedikovane rozhrani, prece si vse pripojite pres express, ne? A pak ho potupne zas vratilo, takze tak zbytecne jak si myslis, to precejen nebude :)
A ve skutecnosti to neni jedno x1... ale jsou to dve x1, v pripade 2S EPYC ROME je BMC na jednom socketu a druhej socket je pak tunelovan skrze CPU v prvnim.
Co fanboys ale nezminuji je, ze v pripade Intelu je 2S system postaven tak, ze jsou dostupny vsechny PCIe linky obou procesoru, protoze S2S je skrze dedikovane QPI. V pripade AMD je to tak, ze se na S2S se pouzivaji primo PCIe linky. Klasicky 2S AMD EPYC tedy ma per socket - 5 x16 vyvedeno do slotu a 3 x16 pro spojeni dvou socketu.
Tj. pri prechodu z 1S na 2S je to u (starsiho) Intelu 44 --> 88 linek a u amd z 128 --> 160. Doposud dobry - ale pojdme jeste vejs - v pripade 4S systemu je na intelu 176 PCIe linek (4x44), u AMD ale uz jenom 128 linek (4x32), protoze tri spojeni 2x16 jsou na sousedni sockety. A pro top stroje v 8S konfiguraci, mame u Intelu 8x44 linek = 352 linek, zatimco u AMD to bude prinejlepsim jiz jenom 8 1x16 = 128 linek, kdyz se vse vyplejtva na spojenu CPU (8P system ale nezminuji.. cpu jsou urceny do 1P/2P platforem, a existuje diagram zapojeni 4P ROME).
Nepreferuji ani jedno, ani druhe - ale je videt ze optimum a skalovatelnost je u obou vyrobcu nekde jinde.
Pak je tu ovšem ještě ten drobný detail, že u AMD jsou to PCIe 4 linky a u Intelu PCIe 3, tzn. i v případě hypotetického 4S systému nabízí AMD vyšší celkovou propustnost než Intel...
Nuda, ani jedna ALU. A cache vykon nerobi!
Problém je, že cache výkon urobí
Dnes máme problém "ládovať" výkonné jednotky dátami
dnes majme v booste +-4GHz a teda takt 0,25ns
řadič RAM
Ryzen 7:1800X :74 ns - ak sa pristupuje k RAM= tak CPU čaká 296 cyklov a teda je výkonovo spomalená na 1/296 svojho taktu
Ryzen 7:2700X:66 ns (-11 %)
L3
11 ns
vs
9,2 ns (-16 %) - To je spomalenie len na 1/37 taktu na tú chvíľu
a pri L1
1,1 ns
0,95 ns (-13 %) - to je cca 1/4 taktu
https://diit.cz/clanek/latence-cache-zen-ryzen-2000
A čím viac je v CPU cache tým častejšie sa pristupuje namieto do RAM do cache.
A teda je CPU podstane zrýchlený, ale čim viac rýchlejšej cache ve v CPU, tým je drahší na výrobu...
A podobné zrýchlenia majú buffere pri radičoch.
Přijde mi, že předpokládáte že neexistuje cache prefetching a zároveň že všechny operace v CPU trvají 1 takt. Též nezapomínejte že výron CPU neroste lineárně s velikostí cache, on vlastně roste od určité úrovně jen nepatrně. Nicméně děkuji za věcný komentář.
odpoveď je nižšie. Inak ďakujem
Latence pametoveho system vykryva cache jen z mensi casti, vetsi prinos ma dobre navrzena pipeline - a na vykon ma spis vliv znova ta pipeline, ROB, prefetcher a jine komplexnosti.
Historicky taky existovali pocitace ktere meli neskutecny vykon zcela bez pouziti cache - napr. Cray MTA - samozrejme za urcitych podminek - jako ze tam musi bezet dany pocet vlaken, ve kterych se dlouhe pametove latence prekryvaj posunute o 1 takt: https://en.wikipedia.org/wiki/Cray_MTA
To už sa môžeme baviť o Space T3, Power 8 a ich SMT-8 reschedulingu atď.. Lebo aj Smrdí facto umožňuje pustiť inštrukcie, pre ktoré sú dáta pripravené.
>Přijde mi, že předpokládáte že neexistuje
>cache prefetching
To nepredpokladám ani omylom. Lenže cache prefetch potrebuje nejaký buffer v radič RAM na to, aby vedel robiť prefetching včas.
>a zároveň že všechny operace v CPU trvají 1
>takt.
To nepredpokladám a ani nemôžem, ale kolegovi som hyperbolizoval vplyv. Bral som extrémny stav, že nič z opatrení nezafunguje.
> Též nezapomínejte že výron CPU neroste
>lineárně s velikostí cache, on vlastně roste
>od určité úrovně jen nepatrně
To niekde tvrdím? Alebo je to dôsledok tej hyperboly?
Ak bude čítaní z RAM 0,1% a zrychlim ich 200x
0,999 kódu bude trvať 0 999 času
A
0,001 kódu bude trvať 0.000005 času
teda kódu bude trvať 0.999005 času
a teda výkon bude
1.000996 násobný. teda zdvihne výkon o necelé promile.
Prax ale ukazuje, že je problémov je toľko, že nárasty sú v jednotkách percent.
A to hlavne kvôli koherncii cache.
Takže taká multibránová L1 v IO chiplete
mapovaná ako sekcia L1 v každom jadre a presun dát do nej v prípade nutnosti koherencie by zdvihla multicore výkon pomerne výrazne
Cache se da udelat CC, ale ma to dopad na vykon, takze je lepsi psat MP aplikace tak, aby si data mezi sebou nekradli.
Tam, kde je nutno sdilet vice dat mezi procesory je lepsi pak zvolit jinou architekturu, napr. u GPU mate cca 32 jader sdilicich cca 100kB register file, nad kterym muzou vsichni naraz operovat plnou rychlosti.
> je lepsi psat MP aplikace tak, aby si data mezi sebou nekradli.
Súhlas, ale:
A aké percento programátorov to vie. Masovo sa paralené programovanie používa minimálne od MULTICS-u z roku 1964 a stále to dokáže len 1% (a radikálne sa to nezmenilo)
Parallel programmers not prepared for the glorious revolution
By Wily Ferret
Tue Nov 27 2007, 12:28
INTEL RECKONS barely one per cent of software programmers are prepared to face the challenge of parallel programming, which the hardware giant (unsurprisingly) reckons is the future of development.
už defunct
http://www.theinquirer.net/inquirer/news/1026585/programmers-prepared-gl...
If only one percent of pragrammers is able to do so, it may be hard.
And is was not changed since that time till today
Software needs meaty cores, not thin, stringy ARMs, says Intel
By Simon Sharwood, 26 Feb 2014
“The world has a big issue around vectorisation and parallelisation of code,” Graylish said. “99% of code isn't written that way.” Graylish also feels “defining a workload that can run in 1000 cores is hard.”
Most software, Graylish added, “still requires a big meaty core” and Intel is happy to provide them.
http://www.theregister.co.uk/2014/02/26/software_needs_meaty_cores_not_t...
>Tam, kde je nutno sdilet vice dat mezi procesory je lepsi pak zvolit jinou architekturu,
>napr. u GPU
To je tak 1% z toho 1% paralených programátorv, čo by toto zvládlo efektívne
>Přijde mi, že předpokládáte že neexistuje
>cache prefetching
To nepredpokladám ani omylom. Lenže cache prefetch potrebuje nejaký buffer v radič RAM na to, aby vedel robiť prefetching včas.
>a zároveň že všechny operace v CPU trvají 1
>takt.
To nepredpokladám a ani nemôžem, ale kolegovi som hyperbolizoval vplyv. Bral som extrémny stav, že nič z opatrení nezafunguje.
> Též nezapomínejte že výron CPU neroste
>lineárně s velikostí cache, on vlastně roste
>od určité úrovně jen nepatrně
To niekde tvrdím? Alebo je to dôsledok tej hyperboly?
Ak bude čítaní z RAM 0,1% a zrychlim ich 200x
0,999 kódu bude trvať 0 999 času
A
0,001 kódu bude trvať 0.000005 času
teda kódu bude trvať 0.999005 času
a teda výkon bude
1.000996 násobný. teda zdvihne výkon o necelé promile.
Prax ale ukazuje, že je problémov je toľko, že nárasty sú v jednotkách percent.
A to hlavne kvôli koherncii cache.
Takže taká multibránová L1 v IO chiplete
mapovaná ako sekcia L1 v každom jadre a presun dát do nej v prípade nutnosti koherencie by zdvihla multicore výkon pomerne výrazne
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.