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

Diskuse k Zen 3 a SMT4: Podpora více než dvou vláken na jádro je logická

nj, len M$ trvalo cca 2 roky, kym relativne normalne implementoval pouzitie Zen do Win10. A to slo "len" o implementaciu 8/16 do desktopu. Podla mna hypoteticky Zen3 8/32 M$ nezvladne :)

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

Což o to, Microsoft prý dostal vzorky od AMD pozdě, a tak je pochopitelné, že měl problémy.
Ale to, jak AMD řešilo podporu svých procesorů na Linuxu, kde to jaksi bylo na nich, je dost smutné. Zeny byly zpočátku pěkně užrané, měly problémy s turbem a řízením spotřeby.
Plánovač na více vláken byl na Linuxu včetně NUMA už dávno hotový, protože musel umět např. osmiprocesorové sestavy s Intelem, 100 jádrové Tilery, SMT8 procesory od IBM, takže tohle problémy nebyl. Ale jak se AMD postavilo k ovladači, to bylo dost smutné. Když to nezvládlo samo AMD, jak měl být Microsoft lepší?

(A ne, nefandím Microsoftu, a ano, mám rád AMD...)

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

Čo konkrétne nezvládli v GNU/Linux u AMD so Zen ?

openSUSE Tumblewwed na AMD Ryzen 5 1500X
nabootovalo na prvý raz Windows 10 sa ani nechceli inštalovať...

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

Já nepíšu, že to nebootovalo, ale o funkčním power managementu, které se do jádra dostalo do použitelného stavu až pár měsíců po vydání Zenu.
Zpětně je to pochopitelné, protože se Zen šil holt horkou jehlou a mělo to svůj význam pro pokladničku AMD, zvládli to dobře, ale přijde mi nemístné nadávat Microsoftu, který to měl o kus těžší.

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

Já si tedy nejsem úplně jistý, ale spíš bych řekl, že ovladač zařízení (CPU) poskytuje jakési API pro ostatní části systému. Pokud dojde k rozšíření "metod", které toto "API" poskytuje, je pak už na zbývajících částí systému, jestli implementují nové "funkce a metody".
Z toho usuzuji, že pokud byl problém s monitoringem a nastavováním stavů, stojí za tím autor subsystému řízení spotřeby. Co nevím je, zda tyto moduly píše AMD.

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

Rozhodně AMD může buďto patche vytvořit a zaslat správci toho subsystému, nebo nabídnout správci pomoc v podobě dokumentace, vzorků a financí nebo vlastních vývojářů.
Ostatně podobně si stěžoval právě Microsoft (i když kdo ví, kde je pravda), že dokumentaci a testovací vzorky dostal pozdě.

Takhle zpětně to pro AMD dopadlo i přes tyhle drobnosti skvěle, ale já tehdy právě z těhle důvodů Epycy nekoupil, a teď mám zase na pár let vystaráno. Pokud se situace u dalšího Zenu bude opakovat, doufám, že se Intel vzpamatuje, jsem docela namlsaný tím, že jeho enterprise věci fungují dle očekávání.

Z tohohle pohledu mě opravdu pobavila reklama AMD, že doteď nikdo nikdy nebyl vyhozen za to, že zvolil Xeon, a u toho fronta těch vyhozených lidí po vydání Epycu. To sedlo krásně, díkybohu za to, ono fakt dost dlouho nebylo na výběr. Stavební stroj Opteron jsem koupil jeden a asi nikdy na to nezapomenu, co to bylo za neštěstí :-D

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

"já tehdy právě z těhle důvodů Epycy nekoupil, a teď mám zase na pár let vystaráno"

Měl jste na mysli, že teď máte na pár let o zábavu postaráno? Vypínání HT, sledování CVE, jaké zas nové zranitelnosti se objeví a co je potřeba povypínat, aktualizovat a zpomalit tím systém... ;-)

Pokud se plně produkčně použitelným staly CPU EPYC v linuxu po pár měsících, tak to považuji za celkem normální stav. Zcela novou architekturu hned po vydání kupují jen early-adopters, kteří holt musí počítat s pár porodními bolestmi. Navíc než nové odladěné drivery z kernelu probublají do největších distribucí do stable větve a admini vše aktualizují holt i pár měsíců zabere.

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

Mě paradoxně tyhle chyby v CPU netrápí, protože všechen software, co tam běží, je považován za bezpečený, a zároveň je to vše za firewally, kde Intely nejsou. Nemám tam žádné terminálové servery nebo veřejné VPS, takže i přesto, že by ty chyby nebyly opravené nijak, kromě toho, že s tím musím počítat, mě to nijak neohrožuje. Mnohem větší nebezpečí je to pro pracovní stanice, kam se instaluje všechen možný balast, pro webové prohlížeče, když je to zneužitelné i javascriptem a podobně. To, že mi tam běží Linux s Oracle databází je k této chybě zcela irelevantní. Pokud by Oracle databáze chtěla vykrást moje data, nepotřebuje k tomu chyby v CPU.
Největší problém je to pro cloudy jako jsou AWS, Azure nebo Google, tam je to průser, který bych řešit nechtěl. Taky proto Amazon už nějaký ten pátek nabízí i armové virtuály na vlastním železe.

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

> přijde mi nemístné nadávat Microsoftu, který to měl o kus těžší.

Az na to, ze nemel. 8C Ryzen a 16C Threadripper nebyly nejak uber-vyjimecne procaky. Ano prinesli nevidany vykon za skvelou cenu, ale "mnohojadra" a NUMA systemy existovali davno predtim. Takze vymluva ze jim prisli pozde vzorky je mimo. Navic MS prodava Windows i na servery, a v serverove verzi Woken tohle museli mit davno poresene, jinak by to byl nepouzitelny a neprodejny smejd.

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

Však to také fungovalo, jen ne optimálně, protože Widle nevěděly, ke které NUMA doméně které jádro spadalo. Ono je třeba říct, že Epycy přinesly něco, co na Windows do té doby neexistovalo, a to dvě vnořené NUMA domény (první stupeň bylo přímé připojení k paměti, druhý stupeň paměť přes jiné jádro, třetí stupeň paměť přes jiný procesor).
Takže logicky, pokud je AMD na tento nepodstatný detail nepřipravilo včas, nebo to Microsoft podcenil (je možná i kombinace obojího), nefungovalo to pak optimálně.

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

Pocatecni odladeni Zenu na obou OS nebylo nic moc, to myslim nebylo tak velke prekvapeni. Solidni fail ovsem je chovani Windows na 2970WX a 2990WX. Jestli jsem spravne pochopil problem, tak OS sice po aktualizacich spravne vidi NUMA topologii CPU, ale scheduler nevi jak s ni spravne pracovat.

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

Jak má sakra poznat, která jádra mají vyšší paměťové latence? (čip-čip-paměť)
Snad AMD dodá podklady u SMT4, která jádra jsou stejná jádra.

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

Tak, že AMD dodá specifikace, upozorní Microsoft na tenhle problém a ten pak opatchuje scheduler tak, aby tyhle věci poznal.
Ale někde v tom řetězci je problém. A myslel jsem, že už je vyřešený, ono to trvá stále?!

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

Keby to tak bolo, tak ten problém nie je na Core i9

Windows 10 vs. Eight Linux Distributions In Various "Creator" Workloads On An Intel Core i9
on 1 October 2019
https://www.phoronix.com/scan.php?page=article&item=windows-linux-creato...

Windows 10 vs. Ubuntu 18.04 LTS Performance On AMD Ryzen 9 3900X
on 26 July 2019
https://www.phoronix.com/scan.php?page=article&item=3900x-windows10-ubun...

A Look At The Windows 10 vs. Linux Performance On AMD Threadripper 2990WX
13 August 2018.
https://www.phoronix.com/scan.php?page=article&item=2990wx-linux-windows...

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

8C16T vo Win10 nie je a nebol problem

problem bol nad 16 vlakien a aj to uz by malo byt asi fixnute, takze TR2 2990WX ktory ma 32C64T by uz nemal vykazovat vykon ako TR2 2950X ktory ma 16C32T

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

Zen3 8/32 na to číslo se pěkně kouká.

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

8/24;)

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

Spíš než 8/32 by to mohlo být, jak píše no-X ...
16/64
12/48
8/24
6/18
Ahlony pak třeba 6/6 nebo 6/12.
Protože logicky čím víc provozuješ zátěž(aplikace) pro více vláken, tím vícejádrový CPU koupíš a tím větší přínos pro tebe má SMT.
Krásný způsob jak v nové generaci přinést něco nového a přitom nemuset zvyšovat počet jader(který je imho dostatečný per segment(desk./work.(po vydání TR3000)/serv.)).
AMD opět boduje(bude, doufejme), díky za to. Vděčný uživatel R5 2600.

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

Není v celém tom konceptu něco špatně? Udělám jádro, pak udělám 2 jádra, pak udělám složitější 2 jádra a ještě složitější. Pak přijde problém, že ta složitá jádra nejsou dostatečně využitá a tedy přidám SMT, pak se to znova opakuje tak přidám SMT4.
Není na čase se pokojně vrátit k RISC architektuře a všechny tyhle vychytávky řešit softwarově?

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

x86/x86_64 je interne RISC so SW nadstavbou, ktorá spôsobuje, že sa navonok chová ako CISC

Koncept zložitých jadier bol skôr ako mulijadrá
aj v P5 z 22.3.1993 bola superskalárna architetúra (ako zložité jadrá)
https://compfuter.wordpress.com/2011/02/05/the-architecture-of-pentium-m...

A nebol úplne prvý, len v P5 tam bol skok voči i80486

ZEN2 má oproti P5-ke v FPU len malú zmenu z 3 na 4 EU
ALU má nárast z 2 na 5 EU a AGU z 1 na 3
https://hexus.net/tech/news/cpu/131549-the-architecture-behind-amds-zen-...

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

Jj už jsem psal v jiné diskuzi, velkou pákou v té době v oblasti x86 byl Nexgen (potom koupený AMD).

Vzpomeňte jak na to šli se zvyšováním IPC dříve alias P4 nebo AMD "stavební" stroje, prodloužili pipeline a to byl přešlap jako bota Melichar- zjistilo se, že teoretické modely fungování CPU vůbec nebyly korespondující s reálnými aplikacemi, ale CPU už se dotlačily do výroby.
Proto se dnes jde cestou HT.

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

"x86/x86_64 je interne RISC so SW nadstavbou, ktorá spôsobuje, že sa navonok chová ako CISC"

Tohle je obecny blabol. Nechapu, proc tomu lide veri, proc to siri.

x86 architektura je CISC a nema interne RISC. RISC architektura neni jen o jednodussich instrukcich, ale i o spouste dalsich zalezitosti. x86 pouziva dekodery a rozklada CISC instukce na primitivnejsi, ale to samo o sobe z ni nedela "vnitrne RISC".

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

IMHO se mýlíš. Které konkrétní vlastnosti RISC procesorů nemá "jádro" X86 procesorů?

Smyslem RISC architektur byla instrukční sada, která absencí instrukcí nepracujících s registry umožňuje snadnou implementaci superskalárnosti a reorderingu. A přesně ze stejného důvodu se dnes dekóduje na mikroinstrukce v CISCcích.

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

Přesně tak. On tomu Mali moc nerozumí. RISC taky umožňuje instrukce o konstantní délce, které jsou vhodné pro max plynulost zpracování, tedy vysoké frekvence. CISC byl omezen rychlostí zpracování té nejsložitější instrukce.

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

"RISC taky umožňuje instrukce o konstantní délce, které jsou vhodné pro max plynulost zpracování"

Taky umoznuje? Mas to obracene. RISC je ten, ktery takovy system zavedl. CISC ma promenlivou delku instrukci a ani micro ops nemaji fixni delku.

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

A co asi píšu? Každopádně bys měl napsat všem IT webům, nakladatelstvím a autorům učebnic, že moderní x86 nejsou vnitřně RISC jak tvrdí už nějakých 20 let. A začni radši hned, máš dost práce :D

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

Ono se to běžně učí např. na vysokých školách.. A taky je to pravda ;)

Složité x86 instrukce, které mají různou délku, můžou mít přístup do paměti všude možně (třeba u ADD) apod. (klasické CISC vlastnosti) jsou překládány na micro ops, které mají stejnou délku a přístup do paměti mají pouze u LD a ST instrukcí. Je to sice klasický superskalární CISC procesor (řízen SW), ale pro samotné vykonávání výpočtů využívá superskalární RISC jádro.

Pokud by skutečně šlo o CISC (a takové stále existují - zejména ve světě mikrokontrolérů), nikdy by nedosahoval takových výkonů..

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

To ze nektere veci CISC adoptoval z domeny RISC z neho vnitrne nedela RISC.

uOPS nemusi a casto nemaji stejnou delku, podle toho, jaky maji operand, mrknete treba na specificka uOPS cache u Intelu. I pristup do pameti se lisi. Proste uOPS nejsou RISC instrukce a konec debaty. Je to optimalizace CISCu vyuzivajici nektere principy RISC architektury.

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

Ty nechápeš, že taková RISC architektura jako ARM taky umí pevnou i proměnlivou délku instrukce. A dělá to z ní snad CISC? Nedělá.

Prostě dnešní x86 CPU mají vnitřní RISC jádro a už se s tím smiř prosím tebe.

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

"A dělá to z ní snad CISC? Nedělá."

No, dělá to z ní přinejmenším ne-až-tak-RISC, protože jedním z klasických kritérií pro RISC je *minimum instrukčních formátů*.

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

Nebuď hnidopich. Inženýři v silicon valley to nazývají RISC, takže bych si tady nehrál na chytřejšího. Oni tyhle CPU vytváří, my tady jenom hloupě tlacháme a slovíčkaříme. Zatímco Izrael s polovinou obyvatel ČR má Intelácké vývojové centrum, tak mi tady v ČR budeme poučovat celý svět, ale sami děláme iba celé vodiče.

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

- rec se vyviji a lide maji tendenci si mnoho veci zjednodusovat ;)
- ohledne CR tvrdis nepravdy
- Intel si myslel ze drahe spickove odborniky nahradi armadou levnych "inzenyru" a nasypal do toho mnoho miliard ver ze kdyby podobnou sumu zainvestoval kdekoliv jinde tak to dopadne podobne ..navic dostal plno vyhodnych pobidek ..

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

Tak mi pověz jaké CPU se v ČR vyvíjí? Je mi jasné že jich jsou desítky, stovky, ba přímo tisíce...
Tak mi jmenuj alespoň 3.
Jo chlapče, doby kdy ČSR s profesorem Svobodou byly na špici vývoje CPU jsou dávno v tahu. Doporučuji se dovzdělat o Svobodovi na root.cz

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

No to není RISC architekturou - i ta používá více vláken na jedno jádro viz Power, SPARC ...

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

Zkuste zabrousit do historie proc vznikl CISC; RISC ma svoje velke nevyhody, jednou z nich je nutna existence 100% optimalnich kompilatoru... a to je pohadka z rise snu.

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

Pleteš si RISC a VLIW.
- RISC vznikly jako reakce na CISC, nikoli naopak
- jedním z důvodů vzniku RISC instrukční sady byla právě neschopnost kompilátorů efektivně používat složité CISC konstrukce
- Optimální kompilátory potřebují VLIW procesory, kde je paralelizace záležitostí kompilátoru. RISC procesory právě zavedly takové věci jako reordering a superskalárnost, která potřebu efektivního kompilátoru snižovala.
- největší nevýhoda RISC procesorů je velká paměťová náročnost kódu (a z toho plynoucí zatížení cache syubsystémů). Proto je dnešní model: kompaktní CISC kód překládaný na "RISC mikroinstrukce" tak efektivní.

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

S tím bigLITTLE a ultramobilním segmentem mě spíš napadá, jestli AMD díky chipletovému designu neimplementuje obdobný přístup.

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

Celej bigLittle je kravina co vznikla kvůli hráčům a benchmarkům. Nemám potřebu si vybírat mezi dvěma velkými jádry s vysokou frekvencí a čtyřmi malými jádry s nízkou frekvencí, když jsou ideálem dvě až tři velká jádra na nižší frekvenci. Platí to pro mobily i PC, proto je dnes zbytečné se trápit s Atomem nebo Jaguarem, když podtaktovaná velká jádra přinesou lepší svižnost a stejnou spotřebu. A to nemluvím o SW/HW zjednodušení - větší blbuvzdornost.

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

Sám si kravina s tím Big.Little. Palomino určitě není chytřejší než inženýři Qualcommu nebo Applu. Jestli jo, tak se tam přihlas a oni tě zaměstnají jako svého ředitele.

Určitě bych se zamyslel proč neúspornější a nejefektivnější CPU na světě (SOC v mobilech) se drží konceptu big.Little. Taky bych se zamyslel proč nejvýkonnější CPU na světě momentálně má Apple, jeho jádro Vortex má 6xALU jako první na světě, IPC +58% proti Intel Skylake.

Než pošleš životopis do Applu na toho ředitele CPU divize, zkus si o tom něco málo zjistit abys nám tam nedělal ostudu.

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

Ti inženýři nejsou hloupější než já, ale bohužel se musí přizpůsobit těm hrám a benchmarkům. S tím Applem už jsi akorát čím dál víc trapný. Jen idiot může věřit tomu tvému vortexu +58% proti Intel Skylake. TA PROCENTA NEVYJADŘUJÍ REALITU a silně pochybuji i o REÁLNĚ existující best case situaci. Nějaký software co lidé používají a je tam dosaženo takového výsledku by nebyl?

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

Tak to je snad dobře že se inženýři přizpůsobují těm hrám aby byly rychlejší, ne? Ty bys chtěl aby to bylo pomalejší nebo co???

Ten SW se jmenuje SPECint2006, v profi světě slouží pro porovnání různých platforem, můžeš třeba porovnat x86 s ARMem, Risc-V, Power atd. Obsahuje spoustu dílčích benchmarků, komprese, emulace, datábáze atd. takže dokážeš zjistit slabiny a silné stránky CPU... a také odhadnout výkon pro tvoji budoucí aplikaci. Jen idiot může nerespektovat nejlepší profi benchmark na světě.

Ano, Vortex má 6 ALU jednotek a proto má +58% IPC oproti 4 ALU Skylaku.
Zen 3 bude mít také 6 ALU jednotek, proto se dá očekávat +40-60% IPC oproti 4 ALU Zen 2.

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

"jsou ideálem dvě až tři velká jádra na nižší frekvenci"
Ne, potřebuješ rychlé hlavní jádro, které synchronizuje ostatní.

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

V článku to vypadá příliš optimisticky a ty případy, kdy je lepší HT/SMT vypnout jsou prezentovány jen okrajově. Často jsem kvůli hrám HT/SMT vypínal a pro CADy (ne pro vizualizaci-tam je přínos více jader i HT/SMT) projektu to bylo podobné. HT/SMT není bohužel blbuvzdorné a co je nejhorší, někdy je i vyloženě blbé a přiřazuje větší prioritu nevhodnému vláknu. Do serverů zřejmě OK, ale pro většinu zůstává ideál 8/8 10/10 apod. Jádra jsou levná, doba Pentia 4 je dávno pryč, tak proč to dělat takhle složitě. Software má k dokonalosti daleko - buďme realisti.

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

"někdy je i vyloženě blbé a přiřazuje větší prioritu nevhodnému vláknu" prirazovani uloh/vlaken jadrum je ulohou OS a mate pravdu, ze vindows jsou nebo spise byly dosti zoufale, linux to samozrejme umi lepe. Ale s poslednim updatem windows se to zasadne zlepsilo

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

Protiřečíš si. Vypínáš SMT abys měl větší IPC/vlákno pro aplikace a přitom požaduješ více jednodušších jader. SMT4 je boční produkt výkonného a složitého jádra, navíc SMT lze vypnout.

Hlavní je, že Zen 3 bude monstr jádro, které bude drtit výkonem úplně všechno od Intelu. +50% na stejné frekvenci je naprosto reálné očekávat při zvýšení ze 4 na 6xALU. Je jasné že výkon budou tajit co nejdéle, aby si AMD nepoškodilo prodeje stávajících Zen2. Dnes nedostatkové 12-ti jádra 3900X budou výprodejové zboží a v bazarech se bude válet hromada levných 8-mi jader 3700X.

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

„pro většinu zůstává ideál 8/8 10/10 apod.“

No vida, loni to bylo 6, předloni 4… ;-)

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

Nikde nepopírám, že se to zvyšuje a každý to má trochu jinak. Nenáročný uživatel se i dnes cítí luxusně (má rezervu) i s 4/4. Ryzen 3 1200.

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

Ja si tady taky pridam trochu sve vody do mlyna. Amdahl's law urcuje, ze systemy s omezenou paralelizaci nebudou uz profitovat z vice "procesorovych jader". Vzhledem k beznym typum SW se vliv skalovani zacne ztracet nekde u 32 vlaken.
Takze jestli se budeme bavit o 4 jadru s SMT4, tak to asi problem nebude, ale u 16 jadra s SMT4 urceneho na neprofesionalni pouziti uz ten prinos nebude tak meritelny. Bude pak take hodne zalezet na OS a jeho rezii. Pri spatne optimalizovanem OS (M$ W) muze byt prinos i negativni.
V profi sfere se ale hojne pouzivaji silne paralelizovany SW a tim padem skutecne je velice vyhodne vytizit prostoje CPU na maximum diky SMT4 a nebo klidne i SMT8. V ten okamzik je mnoho vlaken skutecne uzitecnych.

Pokud bude prodej RyZen 5/7/9 pokracovat s SMT2, tak to dava smysl.

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

Jestli se nepletu, tak zatim nikde na svete neni vice nez SMT2, ne skutecne. Jestli to AMD zvladne, tak klobouk dolu. Ja jsem velice skepticky, protoze by to znamenalo velmi velmi velke prekopani architektury.

IBM ma sice az SMT8, ale pouzivaji takovy podvudek. Totiz maji 4/8 malych jednoduchych jader, ktere jsou oproti x86 velice omezena. A pred tim maji spolecny planovac, takze pro system se to jevi jako blok schopny zpracovavat 8 vlaken, ale fakticky je to jen zamaskovanych 8 jader.

To ze AMD rozsiruje nektere prvky pipeline muze byt jednoduse proto, ze bude pridavat ALU/AGU. Pro SMT3+ by museli podle me udelat hodne velke zmeny v architekture, prevysujici i zmeny pro x86_64 rozsireni.

S vyssim utilizaci jadra jde v roku v ruce take vetsi energeticka zatez, takze nizsi boostovani, atp. Proto si nemyslim, ze by to byl dobry krok.

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

„nikde na svete neni vice nez SMT2, ne skutecne.“

Jak moc je skutečný Xeon Phi / Knights Corner?

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

:D

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

...a kvantové počítače mají SMT=nekonečno ;)

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

Intel Xeon Phi je co ja vim "manycore". To neni to same jako simultaneous multi threading. Time-multiplexed multithreading to podle me neni skutecne SMT4.

To je podobny system, jako ma IBM, jednoducha JADRA. Skutecny SMT beru tak jak je implementovat Intelem, ci AMD na x86 procesorech. Tedy ze kazde jedno jadro je schopne zpracovavat vice vlaken.

Pokud beres SMT jako ciste schopnost procesoru zpracovavat vicerovlaken, pak je blbost psat veci jako "8c/16t". Pis vzdy tedy 16t a neres kolik to ma jader :D

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

Podle guideline k Intel Xeon Phi HPC, je implementace SMT v Phi hoodne odlisna od HT v klasickem x86 intelu. Vetsina veci je 4x skopirovana vcetne prefetch bufferu, instrukcnich counteru, atp. A primo pisou, ze kazde jadro je schopne vykonavat 2 (slovy dve) instrukce. Takze ma SMT2 akorat je to zamaskovano tim multiplexem.

A prave na to narazim. Je to radikalni uprava a je to vyhodne pro HPC segment, nikoli pro obecne pouziti. Kdyby AMD neco takoveho delalo, tak si podle me totalne rozhodi vykon v "beznych" aplikacich.

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

Mýlíš se.

Serverový ARM má také SMT4.
DEC Alpha EV8 měla také SMT4 už ve 90 tých, byť ji Compaq zařízl než sám zkrachoval.

Zen3 bude nová 19h mikroarchitektura - takže velké změny lze očekávat. Zen 2 byl poslední 17h CPU. Jim Keller rozjel v AMD paralelní vývoj 2 uarchitekur - malý a velký Zen. A ten Big Zen AKA 19h bude Zen3. Proto přijde relativně brzy po Zen2, makali na tom paralelně.

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

Ok, tak ten EV8 jsem netusil, ze byl udelan skrze rozsireni.

Diky za upozorneni.

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

Co je vlastně "jádro"? V dobách před-P5 bylo celé CPU "jen ALU" (ano, hooodně zjednodušené). Takže, pokud bude jádro zen3 mít 6xALU, klidně můžou implementovat SMT6 :-) Né, jasně že by museli jádro "trochu víc" přepracovat, než "jen" přidat ALU...

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

Jsi mimo, mimo viz ostatní, tak PowerPC má 8 vláken na jádro, Sparc také tak - víceméně všechny čistě serverové CPU šly tímto směrem už dávno.

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

Jak je to s IBM PowerPC jsem uz psal.

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

MIPS s implementovaným MT ASE může mít myslím až 4 TC (thread context), takže se to dá brát jako SMT4. Vtipný je že jednotlivé TC se sdružují do VPE (virtual processing element) a jednotlivých VPE může být na čipu víc. Nejlepší ale je, že jednotlivé TC se mohou mezi VPE dynamicky přesouvat, vznikat a zanikat.

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

Clanek super, ale jedna poznamka ohledne IPC. AMD v Zen2 dotahli IPC na uroven Intelu, coz je super, ale zase neni to zadny zazrak, proste Intel to umi taky. Proto nechapu, ze se v clanku pise, ze Zen2 mel mit puvodne nizsi IPC. Vzdyt to, ze soucasne RyZeny dokazi konkurovat Intelu je prave zasluha onoho zvyseneho IPC, takze bych ocekaval, ze by prave to mela byt zasadni priorita pro ten produkt.
Vemte si Intelem propagovane i9-9900K, ten procak ma IPC stale nejvyssi a zadny procesor od AMD se na nej nechyta, proto ho taky Intel a jeho fanousci prezentuji jako idealni herni procesor. Situace teda neni takova, ze by AMD melo naskok, takze IPC by stale melo byt zasadni, pokud chce AMD jeste vice odrovnat procaky Intelu i v hracskem prostredi.

Jinak osobne protoze nepocitam zadne vedecke vypocty, nehledam vzdalene civilizace ve vesmiru ani nepocitam cislo "pí", tak mi staci i SMT=1, u AMD neni vubec zastoupeno, u Intelu to ma i7-9700. Nakonec Intel i7-9700 8/8 ma ve hrach vyssi vykon nez RyZen 3600 s 6/12, tudiz je docela videt, jak malo muze SMT hrac vyuzit. (Prosim nechytejte me zase hned na rozdilnou cenu obou procesoru, tam neni o cem debatovat, jen davam priklad ohledne toho SMT.)

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

A "náhodou" jste si nevšiml, že i7 má "až 4,7GHz" a ten R5 "až 4,2GHz", že? Jestli ono to nebude z části i tím (a z části plánovačem Windows, který je fakt ... nenapadá mne jak to slušně napsat). Vsadil bych se, že "zabetonovat" oba procáky na 4,2GHz, vyhrál by Ryzen a nebo by to byla plichta.

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

Red je zase mimo. IPC má amd vyšší než Intel, jen nedosahuje takovejch taktů. Ale takovou jednoduchou věc jako co znamená ipc mu nevysvětlíš.

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

ja ako hrac zatial na Ryzen1 6c -mam SMT zasadne -VYPNUTE :)) ale ked si neskor kupim R2 6c -tak SMT2 vyskusam, ale nepredpokladam pre hraca nejaky vyznam, ci? ;)

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

Výkon SMT ve hrách
https://www.techspot.com/review/1882-ryzen-9-smt-on-vs-off/

je to jak na houpačce, ale SMT je malé plus i dnes. A s tím, jak se s tím budou vývojáři her učit (protože SMT se dostává do mainsteamových CPU), tak se množství her, kde to bude mít negativní vliv na výkon, bude zmenšovat.

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

ja pouzivam Process Lasso, a nemusim nic vypinat, len stale 1x nastavit kazdu appku,ci ma alebo nema pouzivat SMT

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

Chování predikovatelné, v průměrech fps spíš pomáhá SMT off, když jde do tuhého, tak SMT zapnuto zajistí vydolování i zbytků výkonu ("bublin") a zvyšuje se tak 1 % low. Na to, jaké takty má Ryzen, je obdivuhodné, jak se drží a vlastně je rozumější koupit víc jader/vláken kvůli dropům (a budoucnosti) než se honit za co nejvyšším průměrem ("benchmarkem"). Marketingově by - pro zasvěcené - udělali líp, kdyby pohli s frekvencí, než že by nabízeli 8 jader 32 vláken (a prodávali víc pruhů víc adidas nezasvěceným).

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

U her je to otázka, která pochopitelně souvisí se stavem herních enginů. Je jasné, že dnešní hry mají (mohou mít) víc vláken minimálně pro jednotlivé typy úloh - např. grafický model, zvuk hry, zvuk komunikace, IO od uživatele, IO ze sítě od hráčů, IO ze sítě od serveru hry, AI, GUI... Ale těch není nekonečno nebo prostě dostatek. Potom je opravdu lepší mít víc plnotučných ale nevytížených jader, kdy sousední vlákno jiného typu úlohy nezdržuje (aby moje bušení do klávesnice nezpomalovalo zvuk např.)

Dále je třeba nezapomínat, že i scheduler má svoji režii a tím větší, čím více vláken musí brát v potaz, že se složitostí jádra klesá dosažitelná frekvence* a také že klesají přinosy z dodatečného vlákna /v hardwarovém smyslu/.

Z toho a milionu dalších proměnných je jasné, že navrhnout takové jádro je odvážný krok se složitou cost benefit analýzou a proto se bojím, aby nevymysleli další buldozer. Nemusíme si asi nalhávat, že by hry nebyly stále hlavní berná mince. Pokud to teda AMD nechce zabalit a věnovat se serverům a spol.

*která jim v důsledku bude bránit uvést herní procák, i když by SMT vypli nebo ponížili

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

Ještě mě napadá jeden "ojeb", jak by to mohli udělat. Totiž tak, že by např. na 8 jádrovém CPU označili BIG jádra s SMT="málo" a např. 2 jádra by měla SMT=4 na to smetí v pozadí a to dynamicky podle aplikace /hry/. Hvězdička z předchozího textu by ovšem platila dál (možná i podpořena vyšší spotřebou).

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

> Dále je třeba nezapomínat, že i scheduler má svoji režii a tím větší, čím více vláken

Kterej scheduler mas na mysli ? protoze jestli se bavime o micro-OP scheduleru, tak ten vlakna v potaz nebere, protoze (AFAIK) na te urovni HT vlakna uz neexistuji. Takze je celkem putna kolik tech vlaken mas. HT vlakna existuji ve frontendu, tam se instrukce dekoduji na micro-OPs a priradi se jim zavislosti (na jinych instrukcich). Backend pak v zasade potrebuje jenom ty zavislosti, z ktereho vlakna prisli mu muze byt sumafuk.

Teoreticky bys mohl mit bottleneck v miste, kde se dekodovane instrukce z frontendu cpou do backendu, nicmene podle me bude bottleneck jinde. Jestli to (>2 SMT) ma mit smysl, tak budou muset rozsirit backend. 4 ALU a 3 AGU jsou na 4 vlakna malo.

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

Napsal jsem scheduler pro zjednodušení. Jasně, že jsou tam i "mikrovlákna", spekulativní exekuce, out of order, prefetch a další chaos, kterej zase zpětně probublává přes cache nahoru. Plus ten Scheduler s velkým S, co to rozhazuje na ALU, AGU a FPU (je nebo bude to opravdu tak?). Nechtěl jsem do toho tolik zabřednout, klidně to dopřesni.

Nicméně nikde nikdo nic nepíše o SSE/AVX/FPU, to bude taky posíleno? Jak (dobře) bude ošetřeno, která vlákna spolu souvisí, u programátora, v kompilátoru, přes "NUMA mapping" (+čiplety), ve Windows, ve scheduleru, přes nějaký atributy, flagy? ...čili díváme se na buldozér II.

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

------------------------- ------------------------- ------------------------- -------------------------
Autor spravne pise, ze IPC a SMT su doplnkove. Lenze bezne pod pojmom IPC myslime IPC NA JEDNOM VLAKNE (!!!), NA JEDNOM VLAKNE, NIE NA CELOM HARDVERI x86 JADRA, ktore naraz dokaze prevadzkovat 2-3-4-...8 vlakien.

Jasne, samozrejme ako sa pise, uz aj jedno x86 jadro je tak zlozite, ze v praxi dnes dosiahnut jeho maximalne teoreticke IPC je dost tazke (nieze by take programy neboli) a zvysnu napr. 20% rezervu vo vykone x86 jadra moze vyuzivat druhe vlakno. Lenze pod zvysenim IPC ide prave o to! Zvysovat IPC jedneho vlakna ci uz
1) reduckiou vykonovych rezerv a bublin
alebo
2) proste pridavanim tranzistorov (tam rezervy a bubliny mozu ostat, alebo sa dokonca aj miene zvysit).
V oboch pripadoch sa prakticke IPC (myslene na jednom vlakne) zvysi. V prvom pripade redukciou rozdielu medzi praktickym a teoretickym IPC, v druhom pripade pridanim kremika pre vypocty, kde sa rezervy a bubliny mozu dokonca navysit, ale toto navysenie rozdielu bude prevazene pridanym kremikom.

Ak chceme aby kazde jedno jedine jadro vykonavalo SMT3 ci SMT4, musi to byt riadne silne plnotucne jadro, mozno este silnejsie ako tie dnesne. LENZE: ak bude vykonavat jedine vlakno, rozdiel medzi teoretickym a praktickym IPC bude priepastny, napr. prakticke IPC pre jedno vlakno vyuzije iba 40 ci 50 ci 60% vykonu celeho jadra (lebo jadro musi byt pripravene na masivnejsi multithreading) a nie priemernych 80% ako dnes.

Pri SMT3/SMT4 je velmi dolezite ako sa bude chovat z hladiska zatazovania jednotlivych jadier vlaknami cely CPU. Vlakna by mali byt najprv pridelovane celym jadram, az kym sa nevycerpaju vsetky fyzicke jadra. Az ked pocet vlakien prevysi pocet fyzickych jadier, az potom ma nastupit SMT. Pri vyuzivani jedneho silneho tucneho jadra pre SMT3/4 jednym vlaknom ho napr. toto vlakno zatazi na 60% a vlakno ide NAPLNO. Druhe vlakno vyuzije dalsich 30% (a vlakno ide NA 30/60 = POLOVICU), tretie vlakno vyuzije napr. 8% z vykonu x86 jadra (a vlakno ide na 8/60 = 13%) a poslednemu vlaknu ostanu totalne omrvinky a medzierky vo vykone celeho x86 jadra: posledne 2% (a vlakno ide na 3,5%). Predstavme si tie rozdiely pre 4-vlaknovu ulohu, keby napr. na 4C/16T CPU bezali tie 4 vlakna kazde ma inom fyzickom jadre a teda kazde vlakno naplno a mame absulut full plny vykon (400% vykonu vlakna) a keby vsetky tie 4 vlakna bezali na jednom jedinom CPU, vtedy mame 100+50+13+3,5 = 166,5% vykonu vlakna.
------------------------- ------------------------- ------------------------- -------------------------

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

To, co píšeš, je jasné. Oni to jádro právě rozšíří, aby k tomu ucpání docházelo později. Přesto je otázka, co takové rozšíření přinese. Dobrý myšlenkový experiment by byl, zda jsou lepší 2 jádra 8 vláken nebo 4 jádra 4 vlákna. Zase milion proměnných, tj. jak kdy a jak u čeho, včetně toho, jestli by byla na plochu větší ta "lepší" plnotučná jádra než (možná) menší "horší" jednovláknová - ale na celkovou plochu čipu menší, která by (ta horší menší) ale dosahovala (možná) vyšších frekvencí - ale na celkovou plochu čipu větší. A to si musí přežvejkat oni. Ale kdyby měli prachy, vydají dva různé křemíky a konec trápení.

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

"zda jsou lepší 2 jádra 8 vláken nebo 4 jádra 4 vlákna" - no tak to je myslim jasne jak facka a ani by jadra nemuseli nutne vyzerat ako dnes: ze SMT/HT znaci iba par % tranzistorov navyse (na reziu a sfunkcnenie) a vyuzije to tych par (desiatok %) nevyuziteho teoretickeho IPC (proste zvysok vykonoveho kremiku) celeho jadra

proste absolutne kazda logika hovori, ze 4C4T bude absolutne vzdy lepsie (prinajhorsom rovne) ako 2C8T
aby tam bol vykon rovnaky, kazde fyzicke jadro v tom 2C procaku by muselo mat 2x vykon ako fyzicke jadro v 4C procaku (a pokial mame tu istu arch., tu istu frekvenciu a cele to nechame iba na SMT... tak neviem neviem)
proste ak chcem vykon zdvojnasobit, boha-proste pridam fyzicke jadro a neondim sa s viac-vrstvovym SMT, ktore mi vykon fyzickeho jadra zdvihne mozno o 50% , mozno o 60%, mozno o 70-80%, ale zrejme nie o 100%

a dalej - horsie, lepsie, jednovlaknove jadra .... no koncept big.LITTLE (dnes mame uz dokonca big.miDdLe.MITTLE) sa v clanku spomina a okrem toho horsie, lepsie, jednovlaknove jadra tak trocha suvisia aj s tym co sme tu uz mali: 2-vlaknove moduly architekury Bulldozer, tam 1 modul bol viac ako jedno jadro s HT, ale zasa menej ako 2 samostatne jadra bez HT ... ak by som to mal normovat na koeficient vykonu jedneho x86 jadra bez HT, tak potom:
- jedno jadro bez HT: vykon 1x
- jedno jadro s HT: vykon 1,20-1,25x
- bulldozer modul: vykon 1,5-1,6x
- dve jadra bez HT: vykon 2x

NO LENZE: vieme ako to s bulldozermi dopadlo

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

Ano, čili pokud nepřemýšlí nad jádrem, které by mělo alespoň pro některé use case potenciální tří a vícevláknový výkon kolem minimálně 200 % jednovláknového výkonu, tak SMT4 nemá moc smysl a byli by jsme opravdu u buldozeru (a ještě dál). Jinými slovy, kolik výkonu vydoluje čtvrté vlákno? 1 %? 3 %? 5 %? Nevíme.

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

a kolko tretie ...

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

To záleží asi na charakteru zátěže, pokud půjde o masivně vláknovou úlohu (ač v rámci jednotlivých vláken relativně nenáročnou) tipoval bych, že širší SMT může snížit režii context switchingu. Pokud nebude scheduler bláznit a stabilizuje obsluhu vláken na jednotlivých (CCX/core/SMT) mohlo by to přinést navýšení výkonu (snížením míry jalové režie, zvýšením cache-hit-ratio, ...). Nakonec UltraSPARC Tx, primárně snad mířený na middle-tier měl 8-way SMT.

Zajímavé bude sledovat nakolik AMD rozšíří v dalších generací management zdrojů CPU/IO/MEM. Již u Epyc Rome jsou snad přidány instrukce umožňující stanovit míru využití cache/mem_bandwidth například v rámci VM. Pokud by šli ještě dál a umožnili plánovat přidělení dalších zdrojů (např. INT/FP/AVX), umožnilo by to definovat i v rámci sdílení HW VM s vyhrazeným "výkonem" bez ohledu na míru/charakter vytěžování dílčími VM.

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

každopádne vždy platí: 2x meraj a raz rež
ja by som povedal 100x meraj a 1x rež

musia to poriadne premysliet, aby tretie a stvrte vlakno na tom istom jedinom jadre nebolo skor na pritaz

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

Asi jsou to zatím zbytečné obavy. Na nějaké AMD prezentaci zmiňující Milan (Zen 3) u něj bylo 64/x2 (core/threads). Spekuluje se např. o sloučení CCX/L3 v rámci chipletu. Necháme se překvapit.

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

Ja beru SMT jako prumerne vyrovnani vykonu architektury pri jakekoli uloze/zatezi, ci uz dobre optimalizovane/navrhnute na ni nebo ne, presne jako clanek uvadi, co neprinese navic(vykon) hruba integrace na poli teoretickeho IPC to nahradi rozsirene SMT, jestli to AMD v Zen 3 nasadi tak by se mel Intel skutecne bat.

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

Díky. Navzdory tomu, co tady hypuje Richie Rich, se ukazuje, že změny v jádru ZEN 3 budou korespondovat s možnostmi 7nm+ procesu, tj. relativně malá úspora ve spotřebě a denzitě nepovede k velkému nabobtnání jádra.
Nyní se tedy potvrzuje, že EPYC Milan půjde na trh už v Q3 2020. Ryzeny 4xxx by mohly vyjít souběžně nebo o kvartál později. Pěkné tempo.

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

Já nehypuji, jenom očekávám od AMD že dožene konkurenci. Když může mít Apple v telefonu CPU se 6xALU, tak nevím proč by PC měla zaostávat.

Zatím je vyvrácen jen 4-way SMT. Nové široké jádro může existovat i se SMT2. Ostatně to Applí Vortex jádro SMT nemá vůbec a pořád patří k nejúspornějším mezi ARMy.

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

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