Diit.cz - Novinky a informace o hardware, software a internetu

Diskuse k CorePrio až zdvojnásobí výkon Threadripper 2990WX [video]

To, ze Windows neskaluje s vyssim poctem jader se vedelo od dob, co nekdo zkusil dual-xeon - nevim zda se konkretne jednalo o 48/96, 56 jader nebo tech 72/144 z Phi. Tj. cca v 2017 :-)

+1
+3
-1
Je komentář přínosný?

Ehhh, tohle se vedelo uz davno pred 2017, teda alespon nekteri to vedeli... Je to dusledek toho, ze scheduler ve woknech neustale nahodne presouva vlakna mezi jadry, coz dela minimalne od XPcek.

Ono tohle chovani scheduleru neni zavazny problem s jistym navrhem procesoru - jako treba maji prakticky vsechny desktopove Intely poslednich deseti let ;-) totizto relativne mala L2 a velka spolecna L3 cache. Jedine o co prijdete pri prepnuti vlakna na jine jadro, je obsah te L2. Zavazny problem to zacina byt prave s NUMA architekturou a jadrami fyzicky na jinych cipech. Linux ma tu vyhodu, ze uz davno a dlouhodobe je laden aby bezel na supermasinach s nekolika tisici jadry... tam si musi jadro sakra dobre premyslet, jestli bude presouvat vlakno na jadro na druhem konci mistnosti :)

+1
+4
-1
Je komentář přínosný?

no rozhodne je to prijemnejsi odhaleni, kdyz je procesor v poradku a chyba je v software a oprava jej zrychly nez naopak, kdy treba meltdown a spectre je v procesoru a oprava to zpomali :)

+1
+8
-1
Je komentář přínosný?

ale fuj, taková zlá slůvka... :-)

+1
+6
-1
Je komentář přínosný?

Lenže oni s týmto súvisia...

Ako som ukázal nižšie, ide na 99,999999999% o problém skáčucej kravy, kde je problémom prázdna cache, ak presuniete vlákno/proces na iná jadro.

Spectre Meltdown a spol. majú dve časti.

1. "Zblbnutie! predikcie pre cudzí kód
2. Prečítanie artefaktov dát s cache, ktoré boli v nesprávne predikovanej časti kódu a teda sa mali z cache dostať von buď po zistení, že je predikcia chybná, čo sa nerobí a je to príčina chýb typu Spcetre a Meltdown a spol, alebo aspoň SW cez flush cache pri zmene kontextu(zmena 3rd Control Register, aka. CR3 ), alebo ringu CPU

Problém je, že flush cache je riešením problému a je univerzálna na celú skupinu chýb, ale nikto ju nerobí, lebo po fluish cahce by sa systém spomalil ako pri probléme Skáčucej kravy a teda min. 15x + čas na flush cache..
A ak sa to má diať 100 x za sekundy na každom jadre pri zmene kontextu, a asi milión krát za sekundu pri zmene ringu volaním syscall na každom jadrem tak bz sme mali emulátor rýchlosti Commodore 16 na Core I9 /Threadripper, preto sa to nerobí. Aj keď by to bolo riešenie všetkých terajších a budúcich chýb typu Spectre a Meltdown. Robí sa to atttack specific bugfixami, ktoré ale spomaľujú menej, ale na každú chybu sa musí urobiť zvlášť oprava...

+1
+2
-1
Je komentář přínosný?

Ted už jen chybí aby to někdo přetestoval na e-zinech a poupravil tak ty dosavadní příšerné výsledky.

+1
+2
-1
Je komentář přínosný?

Budeme-li postupovat dle rozsahleho uvodu v clanku, muzeme odhalit i duvody, proc to na Windows nefunguje a Microsoftu je to jedno. Autor se nad tim uz ale nezamyslel.

Epyc temer nikdo pod Windows nepouziva, servery a tedy i serverove procesory se pouzivaji skoro vyhradne na linuxu, BSD apod. Dost mozna ani Microsoft ve Windows oddeleni zadny Epyc k dispozici nema, k cemu.
TRipper vcelku nikoho nezajima, procesor je na okraji zajmu konzumentu a porizuji si ho predevsim fanousci AMD nebo ti, kteri spoustu jader potrebuji do specializovanych aplikaci a tech mnoho neni. TRipper opravdu neni procesor mainstreamu a tudiz zajem Microsoftu je slaby.
RyZen podobny problem nema. v soucasne dobe ma nejvic 8 jader a ocekava se RyZen 9 generace 3000, ktery by mel mit 16 jader a to je maximum co Windowsy umi.

Zaroven to tedy muze byt i urcitym poucenim pro AMD (fanousci se moc poucit nedaji ikdyz by to nekdy bylo treba), ze zvysovani poctu jader neni vsechno a pro Windows uz AMD v nasledujici generaci dosahne stropu. (AMD to i pravdepodobne vi, protoze z uniku to zatim vypada, ze AMD u nasledujici generace RyZenu vyznamne navysila i IPC, tudiz presne to co je pro Windows potreba.)

+1
-4
-1
Je komentář přínosný?

Toto je čistočistá nepodložená spekulace. MS má jistě do budoucna zájem i toto vyřešit, jelikož momentálně se výkon škáluje i počtem jader. Přeci jen cca 4-4,5GHz je nyní v podstatě strop (při rozumné spotřebě). A MS profiluje W10 jako dlouhodobý produkt.

+1
+4
-1
Je komentář přínosný?

A přesto to doteď ani AMD ani Microsoft ne(vy)řešili...

+1
0
-1
Je komentář přínosný?

jistě má zájem to vyřešit, stejně jako desítky a stovky dalších chyb které zasahují daleko větší množinu uživatelů- To je normální, okrajová platforma nemá prioritu, jsou důležitější věci.

+1
-2
-1
Je komentář přínosný?

RyZen 3000 podle vseho az 5GHz!!!

+1
0
-1
Je komentář přínosný?

Ryzen 3000 určitě ne :-)

+1
-1
-1
Je komentář přínosný?

3000 je oznaceni generace, typ bude nejspis 3700X.

+1
+2
-1
Je komentář přínosný?

nene

+1
-2
-1
Je komentář přínosný?

EPYC používá údajně MS v nějakém datacentru pro Azura a jsou i firmy co mají EPYCké servery na virtualizaci, je ale pravděpodobné, že to bude spíše stylem, kdy na jednom serveru s EPYC CPU běží hromada VM, které mají alokované malé množství jader a nejspíš s tím problémy nejsou.

+1
+4
-1
Je komentář přínosný?

Dovolim si nesouhlasit, pane Redmaxi.

Ono to totiz muze byt problem kernelu, ktery se projevuje u vsech vicejadrovych CPU, jen jeho zavaznost stoupa exponencialne s poctem jader. Tj. napr u 4 jadra zpomaluje CPU (na to rezii) o 2%, u 8 jader o 5%, u 16 jader o 15% a u 34 jader o 50%.

Proto si myslim, ze problem ma smysl resit i u Windows obecne. Samo, jen spekuluji, ale vetsinou podobne chyby nejsou zpusobene natvrdo prekrocenim nejake hranice (ze do 16 jader se chyba vubec neprojevuje a u 17 a vice jader najednou ano).

+1
+4
-1
Je komentář přínosný?

To by mohlo být - kdyby se problém neobjevoval jen v některých aplikacích, že? Viz úvod článku...

+1
0
-1
Je komentář přínosný?

Srovnání v prostředí bez limitace Windows, tj na Linuxu. Cenově mírně dražší i97980xe dostává výrazně na frak. A to jen díky operačnímu systému. Nikdo neřeší škálování multivláknových operací samotných aplikací. Takže rezervy ještě budou.
Kvalitní test - recenze:
https://techgage.com/article/linux-performance-amds-threadripper-2990wx-...

+1
0
-1
Je komentář přínosný?

Ale problém závisí kravy málo jadro Linux v roku 2013. A toto je ono(článok dnes o Windows a článok o jadre Linux z roku 2013). To samozrejme.e odhaľuje prečo Linux expert vie problém MS Windows opraviť, a aj po premietaní, to stále nestačí..

Dalším experimentováním, kdy různými metodami zasahoval do způsobu, jakým Windows využívají jednotlivá vlákna, přišel na to, že ač OS reportuje všechna jádra procesoru jako vytížená, je ve skutečnosti polovina výpočetních prostředků zkonzumována na jakýsi řízený chaos, kdy OS přesouvá vlákna z jednoho jádra na druhé a zpět
https://diit.cz/clanek/coreprio-az-zdvojnasobi-vykon-threadripper-2990wx

4 March 2013
There's also a scheduler patch to fix a "bouncing cow" problem by when running fewer processes on the system than number of processor cores, the process could be bounced around between cores and yield poor performance. This bouncing cow fix for the scheduler yields a performance boost by 15x in a worst-case scenario. More work will come to future Linux kernel releases.

https://www.phoronix.com/scan.php?page=news_item&px=MTMxNzA

Coreprio Can Help AMD Threadripper Windows Performance, But Linux Still Leading Performance Race
Written by Michael Larabel in Operating Systems on 6 January 2019.
https://www.phoronix.com/scan.php?page=article&item=windows-coreprio-lin...

Edit:
ešte kúsok viac

A relatively simple scheduler patch fixes the "bouncing cow problem," wherein, on a system with more processors than running processes, those processes can wander across the processors, yielding poor cache behavior. For a "worst-case" tbench benchmark run, the result is a 15x improvement in performance.

https://lwn.net/Articles/538101/

A ten patch(oprava) je úchvatný..riadky začínajúce
- sa vymažú
+ sa pridajú

- int cpu = smp_processor_id();
- int prev_cpu = task_cpu(p);
struct sched_domain *sd;
struct sched_group *sg;
- int i;
+ int i = task_cpu(p);

- /*
- * If the task is going to be woken-up on this cpu and if it is
- * already idle, then it is the right target.
- */
- if (target == cpu && idle_cpu(cpu))
- return cpu;
+ if (idle_cpu(target))
+ return target;

/*
- * If the task is going to be woken-up on the cpu where it previously
- * ran and if it is currently idle, then it the right target.
+ * If the prevous cpu is cache affine and idle, don't be stupid.
*/
- if (target == prev_cpu && idle_cpu(prev_cpu))
- return prev_cpu;
+ if (i != target && cpus_share_cache(i, target) && idle_cpu(i))
+ return i;

/*
* Otherwise, iterate the domains and find an elegible idle cpu.
@@ -3284,7 +3277,7 @@ static int select_idle_sibling(struct task_struct *p, int target)
goto next;

for_each_cpu(i, sched_group_cpus(sg)) {
- if (!idle_cpu(i))
+ if (i == target || !idle_cpu(i))
goto next;
}
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commi...

+1
+1
-1
Je komentář přínosný?

Ten "bouncing cow problem" je jenom jeden z tisicu problemu, na ktore se narazi pri tuneni scheduleru pro hodnemocjadrove masiny. Rozdil wokna vs Linux je mimo jine v tom, ze Linux se na takovych masinach opravdu pouziva, tudiz tyhle problemy se najdou a vyresi.

+1
0
-1
Je komentář přínosný?

pro hodnemocjadrove

to je synonymum pre manycore?

Ten "bouncing cow problem" je jenom jeden z tisicu problemu

Tak pokiaľ sa nebavím a szstémoch alá TUDOS na jadre M3
M3 https://os.inf.tu-dresden.de/papers_ps/asmussen-m3-asplos16.pdf

Tak je to hlavný problém, aj keď nie jediný...

+1
0
-1
Je komentář přínosný?

Podle toho politického* úvodu by ten, komu umíraly krávy, měly být AMD s Microsftem. Opravdu obviňovali ostatní jak je naznačováno?

*Aby bylo všem jasné, kde je dobro a kde zlo:-)

P.S. Ten výraz "oversimplified" IMO perfektně vystihuje snahu webů s HW a SW zaměřením o zasáhnutí co nejširšího publika, tak pozor, aby to nebyla také střelba do vlastní nohy(ten úvod je možná vtipný, ale určitě je zjednodušující). Například: nechtějí Amazon=nechtějí pracovat, zaručené důvody proč telefony hoří atp.

+1
-1
-1
Je komentář přínosný?

A nebo Intel namazal, aby se neopravovalo, dokud to nebude vadit i jemu ;) Nebylo by to poprvý.

+1
+6
-1
Je komentář přínosný?

Taky si to myslím.

+1
+3
-1
Je komentář přínosný?

Nesmysl, Intel ma dost svych starosti, ten uz je mimo a na nejake podplaceni Microsoftu uz dneska ani nema.

+1
-1
-1
Je komentář přínosný?

Mnohem efektivnější je ale podplácet výrobce HW, ti pak mohou HW konkurence nějak zprasit nebo neprodávat, MS se v tom nemusí nijak angažovat.

+1
+2
-1
Je komentář přínosný?

Souhlas, viz testovane Lenovo, kolik notasu jede na AMD?

+1
+2
-1
Je komentář přínosný?

Ale bude ich viac.

od 1.1. do 6.1.2019 doalo AMD na trh 9 nových notebookých CPU
https://www.amd.com/en/press-releases/2019-01-06-amd-kicks-2019-offering...

Len nech udržia trend priemeru 1,5 modelu na deň.. :)))

je viem, tie 6W modely GPU+ GCN 1.2 GPU sú len do Chromebookov

Starting with the Acer Chromebook 315 and HP Chromebook 14, leading global OEMs are scheduled to release several AMD powered Chromebooks in 2019 delivering fast and efficient computing, with battery life that keeps pace with the consumer’s needs
https://www.amd.com/en/press-releases/2019-01-06-amd-kicks-2019-offering...

+1
0
-1
Je komentář přínosný?

Oproti Intelu relativně málo, třeba na CZC jsem si vylistoval notebooky s mobilními Ryzeny, přičemž ignoruju starší stavební stroje a vypadlo z toho 54 notebooků: https://www.czc.cz/notebooky/produkty?q-c-5-f_100971445494=sAMD%20Ryzen%...

Což vlastně není úplně špatné. Jenže těch Intelovských, pokud beru v potaz jen Core i3/5/7/9 je v nabídce asi 1179 notebooků. A to nepočítáme Core M, Xeony, Pentia, Celerony a tak podobně. Nicméně u obou výrobců je i plejáda smutných a notně ořezaných konfigurací, které se podle mě moc dobře prodávat nebudou.

+1
+1
-1
Je komentář přínosný?

Chybí ještě jeden dílek skládačky aby to celé dávalo smysl. Proč 28/56 xeony v těch problémových aplikacích (třeba to Indigo) nad 16 jader škálují síce hůře, ale škálují, kdežto AMD vůbec, nebo dokonce škálují záporně?

+1
0
-1
Je komentář přínosný?

Treba protoze Intely maji prepinaji procesu vyresene jinak nez AMD CPU a proto je chyba tolik nepostihuje? Ale na druhou stranu jsou pak vice zranitelne temi Spectry a Meltdowny?

+1
+2
-1
Je komentář přínosný?

Podľa mňa tu má vplyv, číslovanie virtuálnych jadier

Intel má tuším párne(sudé) číslo (vrátane nuly) ako fyzické jadro a nepárne (liché) čísla sú Hyperjadrá y SMT.

U AMD Zen by to malo byť inak v plne aktívnom CCX, majú najnižšie čísla 0-3 fyzické jadrá a vyššie 4-7 hyperjadrá z SMT.
Ak je aktívna polovica tak sú fyzické 0 a 1, a logické 2 a 3 atď.
Ak sú aktívne dva plne aktívne CCX
tak sú fyzické jadrá 0-3, 8-11 (8-11 je druhý CCX)
logické 4-7, 12-15 (12-15 je druhý CCX)

atď.

A s týmto plánovač Microsoftu nepočíta.. A už vôbec nie so zdieľanými L2 cache v CCX. a ted fakt, že škálovanie je lepšie pri probéme skáčucej kravy (viď vyššie) je menšia penalizácia, ak sa proces-vlákno presúva v rámci CCX, ako keď sa presúva na iný CCX.

+1
+2
-1
Je komentář přínosný?

protoze epyc a TR jsou slozene z vice kusu kremiku a nemaji spolecnou L3 cache, takze se musi presouvat i cache. Intel ma spolecnou L3 a tak preskoceni zase tolik nevadi.

+1
0
-1
Je komentář přínosný?

Microsoft resi v aktualizacich 10 dulezitejsi veci jako je realne/efektivni vy-rizeni velkeho poctu jader, k prikladu znovu asociace souboru s MS aplikacema, vetsi spehovani, mazani uzivatelskeho nastaveni, 10 sou jednoduse sračka.

+1
+2
-1
Je komentář přínosný?

ono je to účel..

Výrobci pamětí jsou zklamaní z Windows 8, jsou málo náročné
Karel Javůrek 28. října 2012

IHS zveřejnilo procentní zvýšení poptávky po operačních pamětech u starších systémů Microsoftu:

Windows 3.1: +29 %
Windows 95: +23 %
Windows 98: +40 %
Windows 2000: +49 %
Windows XP: +41 %
Windows Vista: +26 %
Windows 7: +18 %
Windows 8: +8 % (odhad)
https://www.zive.cz/bleskovky/vyrobci-pameti-jsou-zklamani-z-windows-8-j...

A podpopra HW pre daný OS je daná podporou predaja ich HW pre náročnosť...

+1
0
-1
Je komentář přínosný?

Pro psaní komentářů se, prosím, přihlaste nebo registrujte.