Copyright © 1998-2025 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2025 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
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 :)
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...)
Č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ť...
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ěžší.
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.
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
"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.
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.
> 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.
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ě.
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.
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.
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?!
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...
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
Zen3 8/32 na to číslo se pěkně kouká.
8/24;)
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.
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ě?
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-...
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.
"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".
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.
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.
"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.
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
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ů..
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.
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.
"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ů*.
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.
- 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 ..
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
No to není RISC architekturou - i ta používá více vláken na jedno jádro viz Power, SPARC ...
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.
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í.
S tím bigLITTLE a ultramobilním segmentem mě spíš napadá, jestli AMD díky chipletovému designu neimplementuje obdobný přístup.
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.
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.
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?
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.
"jsou ideálem dvě až tři velká jádra na nižší frekvenci"
Ne, potřebuješ rychlé hlavní jádro, které synchronizuje ostatní.
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.
"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
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.
„pro většinu zůstává ideál 8/8 10/10 apod.“
No vida, loni to bylo 6, předloni 4… ;-)
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.
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.
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.
„nikde na svete neni vice nez SMT2, ne skutecne.“
Jak moc je skutečný Xeon Phi / Knights Corner?
:D
...a kvantové počítače mají SMT=nekonečno ;)
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
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.
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ě.
Ok, tak ten EV8 jsem netusil, ze byl udelan skrze rozsireni.
Diky za upozorneni.
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...
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.
Jak je to s IBM PowerPC jsem uz psal.
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.
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.)
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.
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íš.
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? ;)
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.
ja pouzivam Process Lasso, a nemusim nic vypinat, len stale 1x nastavit kazdu appku,ci ma alebo nema pouzivat SMT
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).
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
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).
> 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.
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.
------------------------- ------------------------- ------------------------- -------------------------
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.
------------------------- ------------------------- ------------------------- -------------------------
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í.
"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
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.
a kolko tretie ...
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.
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
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.
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.
https://pctforum.tyden.cz/viewtopic.php?f=1&t=277651
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.
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.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.