PCTuning fórum

SMT s ALU může a nemusí mít nic společného. Jeho efektivita a poměr efektivity se na více jádrech dá jistě optimalizovat, ale běžnej pepa nemá jak využít víc než 8-16T. Pokud aplikace bude potřebovat hrubou sílu fyzických jader, tak výkonné SMT nevyhnutelně přinese snížení výkonu tak jako u Zen2. Asi to zatáhnou tím, že optimalizace nové generace přesto přinese větší výkon na jádro než generace starší, nicméně to v době osmijádrové není moc ku prospěchu.

Zajímalo by mě, co je žene tímhle směrem, a ne směrem robustnějších registrů, instrukčních sad nebo přidání PGA na řešení definovaných funkcí, aby se procesor nemusel dřít s hrubými výpočty...

Dělají z toho pomalé prase s velkým throughputem, a to nevidím dobudoucna jako cestu. Tedy, mohutná paralelizace je sice nevyhnutelná, ale skákat do ní po hlavě na domácích stanicích v roce 2020 je moc brzo. Ať si s tím daj na 10 let ještě pauzu...

crashPC píše:SMT s ALU může a nemusí mít nic společného. Jeho efektivita a poměr efektivity se na více jádrech dá jistě optimalizovat, ale běžnej pepa nemá jak využít víc než 8-16T. Pokud aplikace bude potřebovat hrubou sílu fyzických jader, tak výkonné SMT nevyhnutelně přinese snížení výkonu tak jako u Zen2. Asi to zatáhnou tím, že optimalizace nové generace přesto přinese větší výkon na jádro než generace starší, nicméně to v době osmijádrové není moc ku prospěchu.

Zajímalo by mě, co je žene tímhle směrem, a ne směrem robustnějších registrů, instrukčních sad nebo přidání PGA na řešení definovaných funkcí, aby se procesor nemusel dřít s hrubými výpočty...

Dělají z toho pomalé prase s velkým throughputem, a to nevidím dobudoucna jako cestu.

Jak Richie už dříve psal, konečně někdo zmaterializuje tu na papíře vyvinutou, nikdy nevydanou DEC Alphu, od Kellera.

Ale jinak, na ten throughput se zaměřovali i pod starým Meyerovým vedením, s ne dobrou reputací, a výsledným Bulldozerem. Tak když se více různých architektur, rozdílnými prostředky vydává podobným směrem, asi všeci ví, co dělají. Risk to je asi malý, pokud přidají pár ALU, které stejně budou většinou nevyužité v normálním PC, tak to SMT jim to v simulátorech nějak bude ukazovat lepší využití toho obřího nárůstu tranzistorů.

V simulátorech... hádám že tam byl i Bulldozer dobrej eh.

Já osobně nekvituji nic co mi nepřinese globální nárůst IPC i v naprosto pro tohle neoptimalizovanym kódu. Ostatně SMT4 (nebo 8, 16, je to fuk thready moc tranzistorů nestojej, exekuční jednotky ano) je jedna z cest jak na CPU hodit mass muiltithread neoptimalizovanej kód a aspoň ňák tim zasaturovat pipeline. Ale chtělo by se to prostě zaměřit hlavně na klíčový bottlenecky (eghm latence do paměti egm, a DDR5 tenhle problém ještě zhorší) současnejch systémů a ne se snažit dělat core/thread race kterej je drtivý většině z nás k ničemu a přerostl už i potřeby menších a středních serverů.

Apple plánuje tu cestu B s relativně malym CPU a specializovanmými akcelerátory na konkrétní funkce. Uvidíme kdo nakonec vyhraje.

Souhlasil bych, ale kde že je ten mass multithreaded kód?
V tom vidím ten problém. Jednou jistě bude správně mít 128C/512T. No ještě tam nejsme.

crashPC píše:Jednou jistě bude správně mít 128C/512T.

IMHO takový procesor by už docela dobře renderoval FullHD 3D scénu s jednodušším raytracingem i bez potřeby výpočetního výkonu grafické karty. Sem s ním

Ano a teď si představ dedikovanej RT akcelerátor určenej jen na to a jeho výkon v porovnání s tímto. V tom je ten kámen úrazu, dávat tam více a více neefektivních univerzálních CPU jader nevidím jako nejlepší budoucnost.

Co se mass multithread týče tak leda renderer nebo ňáký kalkulace tvorby buňěk či solárních systémů a pod. Nic jiného tak vysoko neškáluje a i tam by se dalo dosahnout mnohem lepšího výkonu/watt třeba i jen blbym GPU, většina těchlech věcí jde převést do GPU ready FP64/32/16/8.

crashPC píše:SMT s ALU může a nemusí mít nic společného.

SMT s počtem ALU může mít hodně společného. Vezmi si že SMT u Zenu dokáže vyždímat nějakých 25% výkonu navíc. Což logicky znamená, že ST load dokáže vytížit jednotky na cca 75%. Toho nevyužitého výkonu tam už moc nebude možná tak 5-10% a zdvojnásobením počtu vláken by sice zvýšili propustnost o těch 10%, ale ST výkon by klesl na polovinu což by byl naprostý průser. Zkrátka roubovat SMT4 na současný Zen2 nedává žádný smysl.

IMHO jediná logicky správná cesta pro využití SMT4 je navýšit i počet ALU, dejme tomu z nynějších 4 na 6:

1. Navýšit počet ALUs pro větší ST výkon potřebuješ tak jako tak. Od 2ALU K6, 3ALU K7, přes 4ALU Zen, po 6ALU next gen
2. SMT4 potřebuje hodně nevyužitých ALUs, jinak nedává smysl
3. Pro zachování MT výkonu potřebuješ aby příliš neklesl poměr ALU/vlákno, takže opět je lepší navýšit počet ALU
4. OoO může prioritizovat kód vlákna kterému branch prediktor předpoví větší pravděpodobnost úspěchu, takže větší výběr = nižší spotřeba CPU
5. možnost měnit priority - to už myslím umí IBM

Všechno tu už v podstatě bylo, jak SM4, SMT8, priority pro vlákna, tak 6ALU v applu. Jenom to ještě nikdo nedal dohromady. Člověk nemusí být génius aby si viděl jak to do sebe zapadá. Nové označení 19h Family otevírá dveře velkým změnám. Stejně je ostuda, že ta Alpha EV8 se SMT4 byla zaříznuta Compaqem ve prospěch takového zmetku jako bylo Itanium. Věčná škoda, protože úspěch EV8 by mohl popohnat vývoj kupředu a mohli jsme tu mít SMT4 v x86 už dávno.

Tahle úplně to neni. ALU a FPU maj určité svoje schopnosti a určité výpočty využívaj určitou část. to je podstata HT ala využít tim že tam proženu ještě jeden thread ty nevyužité části a získat výkon navíc. Teoreticky můžou bejt situace kde i 2 thready nevyužijou pipeline úplně protože třeba chtěj to samé nebo podobné (tam pak ani samo HT nemusí přinést výkon) ale stejně tam zbydou jiné volné prostředky třeba pro třetí nebo čtvrtej. Zároveň ale čím méně ALU tím menší potenciál něco navíc vytřískat, na druhou stranu čím více tím delší možná bude pipeline neni to vždy více ALU více addidas.

Další problém je že to jak řeší SMT nyní AMD a Intel je že se thready o prostředky perou, ala prohnánim 2 threadů přes 1 jádro ti sníží výkon na thread na onom jádře. To neni optimální a hodně je to závislý aby to OS dobře rozhazoval což někde (LOL Windows ) bejvá problém.

DOC_ZENITH píše:V simulátorech... hádám že tam byl i Bulldozer dobrej eh.

Já osobně nekvituji nic co mi nepřinese globální nárůst IPC i v naprosto pro tohle neoptimalizovanym kódu. Ostatně SMT4 (nebo 8, 16, je to fuk thready moc tranzistorů nestojej, exekuční jednotky ano) je jedna z cest jak na CPU hodit mass muiltithread neoptimalizovanej kód a aspoň ňák tim zasaturovat pipeline. Ale chtělo by se to prostě zaměřit hlavně na klíčový bottlenecky (eghm latence do paměti egm, a DDR5 tenhle problém ještě zhorší) současnejch systémů a ne se snažit dělat core/thread race kterej je drtivý většině z nás k ničemu a přerostl už i potřeby menších a středních serverů.

Apple plánuje tu cestu B s relativně malym CPU a specializovanmými akcelerátory na konkrétní funkce. Uvidíme kdo nakonec vyhraje.

Přesně tak, SMT je super v tom, jak neoptimalizovaným kódem perfektně vytížit všechny jinak nevyužité jednotky. V tom byl fail Bulldozeru kdy si Meyer myslel, že donutí miliony programátorů optimalizovat kód pro BD, který v simulátoru na tomto faik kódu dával dobré výsledky. Jako kdyby nevěděl že lidi hledají cestu jak si práci usnadnit a ne si ji přidávat.


Naopak si nemyslím, že problém je propustnost pamětí. Naprostá většina věcí se vejde do cache a rozdíl ve výkonu DDR4-2066 vs 4400 je pár procent, rozhodně neodpovídá víc jak dvojnásobné propustnosti. Latence to samé. CL8 ti taky nepřinese dvojnásobný výkon oproti CL16. Jinak Apple má arm jádra se 6xALU a bez SMT, takže jde cestou hrubého výkonu, +50% větší IPC oproti Skylake hovoří za vše.

Třeba kdyby AMD udělalo sdílený front-end pro celý CCX, tak by mohlo HW řídit thready jak to vyhovuje CPU a ne to nechávat na poťapaném Win scheduleru.


Délka pipeline souvisí s frekvencí a nikoliv s IPC. Více ALU = více IPC. Tady naprosto platí že více ALU více Adidas.

Apple má arm jádra se 6xALU a bez SMT, takže jde cestou hrubého výkonu, +50% větší IPC oproti Skylake hovoří za vše.

Zase ty pohádky

njn, chvili tu byl klid.

A to co řekl o pamětech je taky mimo, resp v některym SW je tomu tak, nemá to smysl, uvidíme jakej ten CPU bude. Ňákou tu L4 na NB sdílenou se všemi jádry bych uvítal mnohem raději jak 4-way SMT, které bych spíš vypnul protože pro to nemám využití. Já mam 18 jádrovej CPU a na více jak 8 jsem jej neměl zapnutej krom bencharků nikdy, protože ve win je to kontraproduktivní.

“[Sunny Cove has an] 800 instruction window, sustains between 3 and 6 x86 instructions per clock,” says Keller, “massive data predictors, massive branch predictors… We’re working on a generation that’s significantly bigger than this and closer to the linear curve on performance. This is a really big mindset change.”

Tím potvrdil, že Intel pracuje na uarch s masivním ST výkonem. Velký ST výkon s malým počtem ALU neuděláš, viz Bulldozer, takže je jasné že Golden Cove bude o dost širší jádro a počet ALU bude větší než současných 4. On si tu svoji EV8 stejně nakonec postaví, ať už to bude Zen3 nebo GoldenCove.

Než Keller odešel z AMD tak nejspíš pracoval na hrubé koncepci 19h Family Zen3, která měla být podobná s Arm zenem. Je otázka jestli Golden Cove je odpoveď Intelu na stejně široký Zen3. Je to dost pravděpodobné. Ale ikdyby Zen3 byl jen úzký Zen2 s naroubovaným SMT4 se 4xFPU, tak prostě už kvůli Inteláckému Golden Cove bude AMD muset přijít s nějakým 6 ALU ekvivalentem dřív nebo později.

EV8 by tehdy nejspíš selhala kvůli enormní komplexnosti. Buď by to mělo příliš nízkou frekvence, nebo příliš vysokou spotřebu, dost možná by to byl velkej problém zvalidovat a vychytat bugy.

IMHO velká šance, že by to dopadlo by to jako iAXP432 - ambiciózní architektura, ale právě kvůli tomu nízký výkon. Ta komplexita není zadarmo.

Ono je jiné mít takovou šířku/počet jednotek/etc dneska s dokonalejšíma nástrojema (mnohem větším výkonem pro simulaci), úplně jiným rozpočtem tranzistorů a energetickou efektivitiou, a na začátku tisíciletí s cca 180nm procesem. A zas ednesk aby ta architektura už zase byla zastaralá a nevýkonná. Zase musíte uvažovat realisticky, ne si z toho dělat nějaký mýty o zlatým věku nebo cobykdyby zázračnejch zbraních.

Richie: Snadno se dá souhlasit, ale i nesouhlasit, podle toho, kam míříš. Navyšovat výkon ALU jde jistě i bez zvětšování jejich počtu. Je to příliš "coby kdyby". Jak jsi psal, problém je v tom, že data nejde dost naporcovat, aby SMT správně krmilo zbytek. A na to poukazuji já - prostě je moc brzo, a stále potřebujem více výkonu z jednoho jádra krmeného jedním vláknem. Optimalizovaný SW prostě roky ještě nedostanem.
Taky podotýkám, že čím robustnější SMT, tím víc se vkrádá do spotřeby procesoru a, a tím klesají takty reálných jader, a tím je menší výkon. Nadruhou stranu PGA/PAL tolik nežere, ale asi není sranda to implementovat.

Realisticky - každé přidání další výpočetní jednotky znamená, velmi velké zvýšení komplexnosti všech podpůrných obvodů OoO enginu. Někde jsem četl až exponenciálně, ale neůžu to najít a nechci si vymýšlet, tak tuto poznámku asi nebrat vážně. Pak mají většinou designéři nějaký bugdet - spotřeba, velikost křemíku, pokud se nepletu okolo roku 2000 byly čipy nad 100mm2 ekonomická šílenost. A u komplexnějšího čipu se hůře dosahuje vysoké frekvence. Takže vždy jde o to najít ten správný vyvážený mix. Byla by tenkrát lepší bájná Kellerova K8 s 6xALU a frekvencí 800MHZ, Pentium4 na 4GHZ nebo reálná K8 na 2-3Ghz?

Takže Zen3 má být na stejném procesu jen s EUV, tam jim moc budget tranzistorů/spotřeby, kam se vlézt, nenaroste. Kolik dalších nových výpočetních jednotek je realistické očekávat?

Záleží, co budou muset umět... ALU není jen jedna...

crashPC píše:Záleží, co budou muset umět... ALU není jen jedna...

To je takový zanedbaný detail

Nj, každej hned mástr přes procesory. Nakillený hospodský kecy. Včetně mě samozřejmě.

Jan Olšan píše:EV8 by tehdy nejspíš selhala kvůli enormní komplexnosti. Buď by to mělo příliš nízkou frekvence, nebo příliš vysokou spotřebu, dost možná by to byl velkej problém zvalidovat a vychytat bugy.

IMHO velká šance, že by to dopadlo by to jako iAXP432 - ambiciózní architektura, ale právě kvůli tomu nízký výkon. Ta komplexita není zadarmo.

Ono je jiné mít takovou šířku/počet jednotek/etc dneska s dokonalejšíma nástrojema (mnohem větším výkonem pro simulaci), úplně jiným rozpočtem tranzistorů a energetickou efektivitiou, a na začátku tisíciletí s cca 180nm procesem. A zas ednesk aby ta architektura už zase byla zastaralá a nevýkonná. Zase musíte uvažovat realisticky, ne si z toho dělat nějaký mýty o zlatým věku nebo cobykdyby zázračnejch zbraních.

V tomhle se neshodneme. V DEC pracovali nejlepší inženýři v oboru a všechny Alphy byly ve své době top procesory. Nevidím důvod proč by tak zkušení lidé měli selhat v případě EV8. Zase takové sci-fi to nebylo. Taková EV7 byla větší skok v počtu tranzistorů (EV6 15 mil -> 130 mil EV7 -> 250 EV8) a taky měla integrovaný MEM řadič což okopčila K8. Dneska právě můžeme říct, že ta EV8 byla správná a nadčasová koncepce.

Na rozdíl od té nepovedené Inteláčké iAPX. Je rozdíl vyvíjet jen nové CPU pro osvědčenou architekturu jako pro tu Alphu nebo x86 a je rozdíl přijít s novou architekturou, nepovedeným slabým CPU a ještě s nefunkčním kompilerem. Není se čemu divit že se to nechytlo.

mr.qeg píše:Realisticky - každé přidání další výpočetní jednotky znamená, velmi velké zvýšení komplexnosti všech podpůrných obvodů OoO enginu. Někde jsem četl až exponenciálně, ale neůžu to najít a nechci si vymýšlet, tak tuto poznámku asi nebrat vážně. Pak mají většinou designéři nějaký bugdet - spotřeba, velikost křemíku, pokud se nepletu okolo roku 2000 byly čipy nad 100mm2 ekonomická šílenost. A u komplexnějšího čipu se hůře dosahuje vysoké frekvence. Takže vždy jde o to najít ten správný vyvážený mix. Byla by tenkrát lepší bájná Kellerova K8 s 6xALU a frekvencí 800MHZ, Pentium4 na 4GHZ nebo reálná K8 na 2-3Ghz?

Komplexnost tam roste hodně, nejspíš to bude pekelně složité implementovat. Ale to je právě ta výzva, přijít s něčím co ostatní pokládají za nemožné. Holt budou muset víc namáhat svoje mozky a míň outsoucovat do indie. Pitomej Apple to dokázal a má 6 ALU. Navíc si vemte, že ARMy umí počítat vektorory o šířce 2048 bit díky SVE2 instrukcím. Zatímco uživatelé Intelu hýkají blahem nad AVX512 tak ARM umí 4x delší vektory. ARM začíná x86 nejen dohánět, ale v některých věcech i překonávat. Jinak já si myslím že ta bájná Kellerova K8a byla něco jako 4ALU+SMT2, tedy více méně jako Zen1, což bylo v té době sci-fi. A frekvence nesouvisí s komplexností, ale s délkou pipeline, přičemž max frekvence je limitována tou nejpomalejší stage. Není jediný důvod aby měla 3x nižší frekvence, tos trochu přehnal. Problémy tam můžou být, stejně jako K10 měla nízké takty kolem 2.8GHz kvůli nějakým bugům v pipeline, tak vyladěná K10-2 na novém procesu už pracovala na 4GHz. Problémy jsou od toho aby se řešily.

Nesouhlasím s DOCem ohledně toho zvyšování cache. Paměť žádné výpočty neprovádí a tudíž nemůže přímo zvyšovat výkon. Jediný efekt je, že snižuje bottleneck paměťového subsystému a tedy nepřímo zvyšuje výkon pomocí lepší saturace výpočetních jednotek. To samé dělá velikost okna OoO nebo všemožné buffery. Ale když je těch ALUs málo jako v Bulldozeru, tak ti nepomůže ani 256 MB L3 cache. Pěkně to bylo vidět na Duronu, který měl L2 dvakrát menší než L1 a přesto měl pořád solidní výkon.

Jádro Zen3 může mít díky komplexnosti 2x víc tranzistorů, stačí když zkrouhnou L2 a L3 cache na polovinu a jsme zpátky na 1.5 násobku což je úplně v pohodě. A zvětšení cache si můžou nechat pro Zen4 na 5nm.