Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
IMHO modulární architektura vznikla jako elegantní konkurence ne vždy dobře fungujícího hyperthreadingu do kterého Intel už nalil tolik, že si AMD řeklo, že musí jít jinou-přímočařejší cestou. Já už fakt nevím co AMD chce a vůbec bych se nedivil, kdyby modularita zůstala a jen se vyladila.
Tohle je základní nepochopení hyperthreadingu resp. SMT obecně. SMT je o využití nevytížených výpočetních jednotek v jádru. Tzn. ty víš, že se ti polovina polovina nebo i více jednotek v jádru CPU fláká i když se jinak v os hlásí jako plně vytížené a SMT jde o efektivní využití těchto volných jednotek pro výpočty v dalších vláknech (u intelu jen ve druhém, ale jsou i cpu s více thready na jádro).
AMD šlo přesně opačnou cestou - místo efektivního využití volných jednotek přidalo další jednotky, ale současně snížilo počet jednotek na vlákno. I to je jeden z důvodů slabého výkonu na vlákno u Bulldozeru.
Pokud se podíváš na ALU - tak jak modul Bulldozeru, tak jádro haswellu mají 4 alu. Ale zatímco jediné vlákno u haswellu může využít najednou všechny 4 (vyjímečná situace, ale taky pomáhá), u bulldozeru nikdy nemůže jedno vlákno využít více než své 2 ALU.
A teď hypotetická otázka - co by se stalo s výkonem a co se škálováním HT, kdyby v intelu omezili, že jedno vlákno může použit jen alu 0 a 1 a druhé jen alu 2 a 3 (pro znalejší ignorujte omezení jednotlivých alu)?
Problém je, že alokace těch jednotek a uvolnění těch jednotek nějakým threadem není zdarma. Tudíž to nemá jen výhody, ale také náklady.
Tedy samotné přivlastnění si nějaké jednotky zabere nějaký čas, má nějakou latenci a náklady, a dojde ke zpoždění vykonávání instrukcí. Kromě toho také záleží na schopnosti predikce (věštění z křišťálové koule) algoritmu, který odhaduje, kterému threadu je lepší jednotku přidělit.
Pokud se zátěže threadu rychle a náhodně mění, pak efektivita přidělování i predikčního algoritmu způsobuje spíše výkonové zaostávání. Proto HT vypadá mnohem lépe v syntetických testech a recenzích, kde je pro přidělovací algoritmus jednoducho, neb zátěž všech threadů je stejná po celou dobu testů pro recenzi, ale v reálném nasazení už to vypadá mnohem méně hezky a výkon je i výrazně nižší. Občas je lépe dokonce HT zcela vypnout, někdy to výkon zvýší.
---
Na druhé straně jistá forma sdílení jednotek je nutná jako vývoj. Bez toho bude efektivita výkon/spotřeba procesorů velmi špatná, zvláště až se půjde do hodnějádrových procesorů.
Takže jde o to, aby threadů v procesoru běželo naráz opravdu hodně, aby případné výkyvy a ztráty ze sdílení jednotek nikoho moc nebolely. A zároveň aby to bylo provedeno dostatečně dobře.
Miloslav Ponkrác
Buď máš nějaké insider informace o specifickém řešení, nebo si radši o tom něco přečti. Bavíme se o úrovni kde nedochází k přidělování jednotek k vláknům, ale pouze k rozhazování připravených instrukcí do front před jednotky a není důvod pro větší overhead než při běžném ooo superskalárním vykonávání.
Jestli ale máš nějaké lepší informace o konkrétní implementaci, rád si přečtu více.
Ono rozhazování instrukcí do front před jednotky má jednu takovou drobnost. Obvykle jsou instruce užitečné proto, že pracují s daty. Tedy s nějakým stavem proměnných, ať už se nazývají registry či další.
Pořád máš představu, že tohle „rozhazování“ nic nestojí.
Zkus si to v praxi. Najdi 4 lidi, ktřeba právníky, kterým dáš vyřešit 10 právnických kauz. Ale uděláš to fikaně, budeš jim materiály rozhazovat náhodně podle toho, kdo zrovna je volný. Třeba 1. dokument ke kauza A dáš prvnímu právníkovi, 2, dokument ke kauze A dáš 2. právníkovi, atd. Že ty dokumenmty mají souvislosti a případ chce řešit jako celek? Jinak se to řešit nedá. No to je právě ten stav, který se ukládá i mezi instrukcemi – a bez čeho to nefunguje, žádné rozhazování do fronty.
Nepotřebuješ insider informace, jen méně seběvědomí, abys velikost seběvědomí ponížil úměrně svým znalostem. Chápu, že jsem nezdvořilý, ale nevydržel jsem to.
Pro tuto chvíli budu předpokládat (i když asi mylně podle toho cos napsal), že víš jak funguje OoO vykonávání na úrovni hardwaru.
Jediný rozdíl pro případ SMT je, že potřebuješ při přejmenovávání registrů rozlišovat, kterému vláknu daný registr patřil (tzn abys registr prvního vlána nezaměnil se stjně pojmenovaným registr druhého vlákna). To je jediný bit informace navíc. Všechno ostatní funguje úplně stejně jako u běžného OoO vykonávání. Samozřejmě budeš asi chtít zvětšit RS a ROB a nejspíš i další buffery, protože budeš díky tomu efektivně pracovat s více instrukcemi najednou.
Ale pokud je tvoje představa, že se nějak říká "teď přidělíme prvnímu vláknu třetí alu", tak ne - v této fázi jsme už na úrovni jednotlivých instrukcí.
Toto byl popis jednoduchého řešení. Tiše jsem doufal (ale na rovinu i bál se), že máš osobní zkušenosti jak se to dělá v praxi a že mě vyvedeš z omylu (nejvíce jsem s k tomu já přiblížil při implementaci vliw procesoru v fpga). Zatím to tak nevypadá.
On je ten stav poněkud rozsáhlejší, než jen registry. Možná to není obecně známo (pro jistotu píši, že jde o sarkasmus), ale procesor také umí pracovat s RAM pamětí a hodnotami uloženými v paměti. Kromě toho instrukce procesoru také závisí na příznacích.
Navíc instrukce mají mezi sebou závislosti. Například výsledek instrukce A oblivňuje výsledky činnosti instrukce C a D po ní. To znamená, že nelze paralelizovat vše a jenom tak. Ty závislosti nejsou jen přes registry, třeba instrukce A uloží do RAM hodnotu, kterou instrukce C přečte (+ kdo alespoň elementárně přečetl úvod do paralelních algoritmů zná také pojem „cena za paralelizaci“, neboli vše něco stojí, nic není zadarmo).
---
Jedna věc je, pokud jsi navrhoval vliw jednojádrový procesor, druhá věc je navrhovat multijádrový a multuthreadový procesor, který se snaží vyždímat ze sebe extrémní výkon. K tomu není třeba ani tak elektronických znalostí, ale jde více o matematické a teoretické znalosti. To složité, co je na moderním procesoru nejsou vykonávači a jednotky, to složité jsou optimalizátory vykonávaní instrukcí a jejich činnost na zvýšení výkonu.
---
Ve skutečnosti je největší problém nikoli jen přidělování jednotek, ale hlavně to, aby ty jednotky byly vůbec využity. Právě proto, že instrukce mají stav (pracují s proměnnými a daty na úrovni registrů a RAM + závislosti na výsledcích operací předchozích instrukcí) je opravdu nejde jen tak klást jednotlivě do jednotek.
Proto má každý moderní procesor jednotku, která mění pořadí strojových instrukcí. Ta se snaží přerovnat insteukce tak, aby zminimalizovala závislosti mezi instrukcemi, nebo je změnila natolik, aby bylo možné použít co nejvíce jednotek naráz a udělat kus paralelně. Vytížit jednotky na maximum se podaří jen málokdy a výjimečně na nějakou tu nanosekundu, skoro vždy nějaká(é) z nich stojí, protože proud instrukcí a jejich stavy a závislosti je nedovolí využít.
Co ta jednotka dělá, na to stačí sledovat výkon prvních (a několika dalších) procesorů Atom, kterým tato jednotka chyběla (a možná dodnes chybí, nesleduji jejich vývoj). Výkon procesoru šel obrovsky dolů. Synteticky v recenzích se zdálo, že Atom je výkonný dostatečně, protože benchmarky jsou poněkud jednostranné a neodpovídající reálné praxi, ale praktický výkon byl/je mizerný.
---
Jednoduše, je snadné nafrkat do procesoru třeba tisíc ALU jednotek, ale reálně stejně většinu času bude fungovat jen jedna, poměrně dost často dvě. Když se výjimečně podaří nakrmit na zlomeček času tři, je to na oslavu pijatikou. A pokud čtyři, to se stává jednou za hodně dlouhou dobu.
Je to proto, že reálně nejsou instrukce jen tak rozstrkatelné do různých jednotek. A pokud se o to pokusíte, a budete zohledňovat i stav, můžete. Jde to, ale podrazí vám nohy právě ta „cena za paralelizaci“ (tedy synchronizace, přenos stavu do jiné jednotky a zase zpět a další), takže výkon bude výrazně nižší, než kdybyste to prováděl na jediné jednotce, a proto se to nedělá. A proto i výkon multithreadingu, nebo sdílení jednotek je jen málokdy lepší, než když se to šmatlá na jediné jednotce neparalelně. A aby paralelní běh občas zvyšoval výkon, k tomu slouží velice složitá matematická teorie, kterou procesor přetavil do velmi složitých optimalizátorů uvnitř procesoru. A ty optimalizátory často paralelnost vypnou úplně, protože pochopí, kdy neparalelní práce na jediné jednotce je výkonnější.
A dále už nebudu o tom psát, napsal jsem toho dost a vše podstatné. Přesvědčování není moje práce, ať si každý odnese z mého příspěvku, co je mu libo.
Miloslav Ponkrác
Toto nemá smysl, evidentně máš větší mezery, než se na začátku zdálo. Zvláště to dokládá tvé opakování závislostí - prosím podívej se jak se řeší závislost na úrovni ILP a TLP a příjdeš na to, proč se u SMT závislosti v podstatě neřeší (ok, řeší, ale úplně jinde). Pak třeba příjdeš na to, že naopak SMT má v tomto ohledu(!) výhodu proti běžnému vícejádrovému zpracování (a vlastně i proti řešení AMD, kvůli oddělené l1 cache) .
To že jsem řešil vliw znamenalo, že jsem si musel nastudovat jak se řeší ILP a samozřejmě i řešení klasickému (OoO).
No, problém je v tom, že jsi zvolil docela špatný příklad toho, proč je BD proti Core pomalejší. Zabrousil jsi zrovna do oblasti, kde uarch BD je proti Core je efektivnější, tedy do škálování SMT vs CMT. Intel SMT škáluje v průměru kolem 15-20%, někdy i více ale zas mnohem častěji méně a samozřejmě, někde dokonce záporně (vlákno okrádá o prostředky to druhé). U CMT je škálování v poměru daleko vyšší, ale zase to stojí něco jiného.
Stejně tak při počítání těch ALU v superscaláru ti nějak vypadlo to, že SB i IB mají pouze 3 výpočetní porty s různou doménou pro FPU a SIMD, takže žádné 4ALU se nekonají, navíc pokud použiješ všechny tři porty pro int ALU, nemůžeš je už využít pro ostatní výpočty na FPU, což na BD můžeš.
Příčiny nevýkonnosti BD bych proto hledal kdesi jinde, třeba na uspořádání frontendu, predikce, absence uop$, nevýkonných L/S jednotek atd......
Já jsem nereagoval na žádný konkrétní procesor, ani neobhajoval žádný procesor vůči jinému. Poslední mé příspěvky jsou čistě teoretické.
Ono je to těžké, když polovina lidí se vytáhne s nějakou ptákovinou, kterou sebevědomě tvrdí o některé věci (zdůrazňuji obecné věci, nikoli konkrétním procesoru), a pro mě je těžké se na to dívat. zhruba v 99 % se udržím a enchám to být, ale pak mám slabou chvíli a zareaguji. Ale polepším se, slibuji, budu nechávat i blbosti bez reakce, i kdybych si měl diit přidal do /etc/host a přesměrovat ho na 127.0.0.1.
Mě by spíše zajímalo, co by dělal diit, nebo jiné české hw servery, kdyby nemohli krást články z anglických serverů. Nebo kdyby anglické servery šly tvrdě autorským zákonem po kopiích jejich článků i v českém jazyce. Myslím, že by v českých doménách zůstala tak setina serverů, a i to jsem optimista.
Ale slibuji, že pokud možno raději budu balit holky, nebo něco podobného, než číst nesmysly na českých serverech a v diskusích.
Já jsem samozřejmě nereagoval na tvůj příspěvek, ale na ten původní. Ba co víc, dokonce jsem se tě snažil v něm zastat.
Nicméně abych se zase zastal DIIT, tak ani na západ od nás se servery nijak nepředhánějí v nějaké vlastní invenci, či dokonce vlastním měřením toho, či onoho problému v uarch cpu, gpu .... Stejně jak u nás, jsou takovéto informace v drtivé většině také přebírány ze specializovaných zdrojů a to jak populárních, tak samozřejmě též vědeckých.
Pokud by se DIIT věnoval uarch čipů v nějaké hlubší rovině, určitě by to sice pár lidí přilákalo, ale zas nepoměrně více lidí by sem přestalo chodit úplně. Imho nějaká vyváženost v hloubce sdílené informace tedy být musí, jinak server prostě končí.
Já jsem přesvědčen o tom, že následné diskuse pod články slouží především k tomu, aby v nich ze sebe lidé mohli udělat větší či menší hlupáky (samozřejmě včetně mě) :)
1. psal jsem o haswellu (je to v textu).
2. psal jsem, že je to jeden(!) z důvodů slabého výkonu na jádro (opět jsi asi přeskočil tuto část)
3. psal jsem, že bulldozer se lépe škáluje, ale hlavně jsem psal PROČ. A to jsou 2 věci: jednak více paralelních EU v modulu(pozitivní změna) a potom omezení výkonu na vlákno(negativní změna). Kdyby jsi vyřešil moji "hypoteticku otázku", tak by jsi dospěl k tomu, že a) multivláknový výkon by se nezměnil, b) jednovláknový výkon by klesl a -> c) zvedlo by se škálování bez jakéhokoliv pozitivního efektu (právě nižším výkonem v jednom vláknu)!
důvodem nevýkonu BD vůbec IMHO neleží v počtu ALU nebo nepřítomnosti SMT. Počet ALU je stejný jako u Haswellu (a i ty 4 ALU na jádro u HW je docela overkill na poměry x86 a dost pochybuju že je dokáže všechny naplno využít), u AMD je mnohem lépe vybalancován s ohledem na využítí více vláken právě tím, že každý thread má napevno přiděleny dvě ALU o které se nemusí dělit s druhým vláknem. (plus vlastní scheduller, dekode, L1D$, atd.) Proto má CMT mnohem lepší škálování v multithreadu než SMT.
Tvoje hypotetická otázka je nesmyslná, protože ty vycházíš pouze z faktu, že dvě ALU na vlákno by u HW vedly k nižšímu single thread výkonu (což mimochodem vůbec nemusí být pravda). Výkon CPU určují jiné důležitější faktory než je počet ALU na jádro/vlákno a to je IMHO i problém BD arch.
jinak na Anandovi to škálovaní CMT vs SMT pěkně přeměřili http://www.anandtech.com/show/5279/the-opteron-6276-a-closer-look/6
Tak, on tu tvou hypotetickou otázku vyřešil už samotný Haswell nepletu-li se?
Haswell přinesl jeden výpočetní port navíc oproti SB a IB, takže má o 33% ALU výkonu navíc. Ale zvedl se také jeho výkon o třetinu v singlu či multi jak naznačuješ svou teorií? Odpověď je poměrně jednoduchá - nikoli :)
PS: Prostě jednoduché sčítání alu jednotek zde nikdy neplatí a opět připomínám, int alu nejsou jediné výpočetní jednotky v cpu, na které se odesílají uops, stále jsou tam ještě fpu/fmac/avx/simd jednotky v jejichž odesílání by BD měl nad Core triumfovat, ale opak je pravdou.
@mirda cervicek: možná to bude znít divně, ale modulární architektura vznikla hlavně za účelem vysoké propustnosti threadů (throughput) pro serverový workload a zároveň měla přinést menší die a nižší spotřebu (díky sdílené FPU). Ve finále nevyšlo vše jak mělo mimo jiné i proto, že AMD/GloFo měla ze začátku velké problémy s 32nm SOI procesem a také s nedoladěným návrhem samotné BD microarch.
Snad jsem někde četl, že jak K10, tak K11 byly uspěchné a verze uvedené na trh údajně neobsahovaly původní cílový návrh, což by vysvětlovalo, proč byly oproti v té době dosluhující, ale vyladěné architektuře v prvních iteracích takový nedochůdčata... Snad si tentokrát dají záležet a přijdou s něčím opravdu solidním jako byla K8.
Větším problémem mi přijde GF a její zaostávání za Intelem. Jaký proces připraví pro K12? 28nm je i dnes pomalu zastaralý, tak to bude 20LPM, protože i 14XM je spíš pro mobilní čipy?
Tady se jednoduše projevuje síla Intelova kapitálu, který si ten vývoj poctivě zaplatí (protože může), kdežto AMD/GF musí paběrkovat s násobně menším týmem. A do budoucna to bude jen horší, otázka je taky, zda se už opravdu neblížíme reálným omezením, neplynoucím ani tak z fyzikálních příčin, jako spíše ekonomické rentabilitě takové výroby. Ony ty fixní náklady už na 20nm nebyly malé a variábly rovněž nejsou nízké..
To, ze AMD musi paberkovat je jednoznacne vina AMD a jejich strategie poslednich let, ne Intelu. Kdyby se AMD misto vymysleni odpovedi na kazdou slepou ulicku soustredilo na co melo, nebylo by dnes tam kde je.
Jmena stavebnich stroju byla ale zvolena spravne - procesory jim odpovidaji jak rychlosti (mala), tak spotrebou (velka).
Ano, AMD nemělo chodnou strategii v poměru ke své velikosti vůči Intelu. Ale i kdyby celých 6 let co měli určitý technologický náskok věnovali svému rozvoji, tak by se na velikost a finanční možnosti intelu nedostali. Vždyť si vem neúprosný "tiktak" intelu, ti si můžou dovolit utratit desítky-stovky milionů za kraviny jako bylo Larrabee a pak jej v podstatě potopit, můžou si vyvíjet technologie výroby (AMD v tomto vždy bylo nuceno spolupracovat s jinými, např. IBM). Chci tím naznačit, že malý prďousek AMD by se s goliášem Intelem měřit nemohl, i kdyby AMD řídil ten nejlepší říďa na světě a v intelu úřadovala parta šimpanzů: http://www.youtube.com/watch?v=VRrMu7B1L2I ;-)
Nemáš úplne pravdu, ak sa menšia firma sústredí len na to v čom je dobrá vie konkurovať väčšej. Ale AMD muselo robiť všetko čo robil Intel aj keď na to nemalo.
Je pravda, že nějaký inženýr anonymně přiznal, že podle původních plánů měl Bulldozer vypadat spíš tak jako vypadá aktuální Steamroller. Pokud by AMD tehdy měla k dispozici proces na srovnatelné úrovni s tehdejším Intelovým, tak by to nebyl špatný produkt. Jenže reálně teď 28nm Steamroller nestojí pro 32nm Sandy Bridge, ale proti druhé generaci 22nm Haswellu a brzy proti 14nm Broadwellu. Takže je problém na obou stranách. Pokud se podaří zvýšit efektivitu na takt, jádro a tranzistor, pak už bude problém jen na straně GF.
On Intel docela zavahal s 14nm a GF se Samsungem se podle vseho vazne hodne snazej toho vyuzit a dostat svoji 14nm technologii co nejrychleji do provozu. Intelu paradoxne asi vymstilo, ze rochodil 22nm s FinFETem bez double-paterningu a pak se jim sebehlo u 14nm tolik zmen, ze maj rok sekeru a problem s vyteznosti (jinak by pofiderne nezacinali s Core M).
Samsungu se zjevne nejak povedlo dat celkem rychle dohromady fungujici double-paterning pro vyrobu FitFETu. Intel sice bude mit lepsi provozni parametry a vyssi hustotu tranzistoru, ale je taky otazka kolik ho bude v porovnani s ostatnima stat nejakej vetsi svab.
A kde hodlá AMD vzít prachy na zaplacení lidí, kteří umí optimalizovat CPU? Jestli to budou opět prohánět nějakým automatem, tak to bude stejný epic fail jako bulldozer.
Možná byste mohl vědět, že optimalizace většiny věcí na čipu procesoru dělají automatyu nejenom u AMD a Intelu, ale i jinde.
Pochopil byste, kdybyste si zkusil navrhnout ručně byť jen kus čipu, a spočítal všechny parazitní efekty každé cestičky a každé součástky, nejen klasické fyziky, ale v těchto nanometrech prakticky tvrdě kvantové fyziky. A až byste měsíc počítal (a měl toho tak milióntinu procenta spočítáno), tak byste někde zjistil, že cesty i součástky musíte udělat trochu jinak, takže reset a počítáme znovu od začátku.
Bez automatu by možná vznikl jeden procesor za deset tisíc let, rychleji se to lidsky těžko dá spočítat.
Bohužel znalosti hw webů a jejich redaktorů jsou takové, že pouští kachny, jako o tom, že snad nějaká firmy nedělá návrhy čipu z většiny automatem. To souvisí s tím, že české hw weby rozumí více angličtině a publikování (zaručně objektivních) reklamně-marketinkových materiálů, stejně jako jsou dobří ve sbírání drbů, které jim jen tak ze škodolibosti či srandy někdy v anglicky psaném webu pohodí. Kdyby měli redaktoři českých hw webů (alespoň jeden takový web kdyby existoval) nějaké základní elementární tehcnické a fyzikální znalosti, pak by tato informace o tom, že Intel nenavrhuje automatem čipy byly hned pbez přemýšlení zahozena jako nesmysl na entou.
Bohužel humanitně zaměření redaktoři, jejichž největší devizou je jejich zlepšující se schopnost překládat z angličtiny a bez jakýchkoli znalostí, aby obsahu textu po technické stránce porozuměli – nahrává šíření nesmyslných drbů.
Miloslav Ponkrác
Hezky ses rozkecal Ponkrác, ale to si nech na roota. Nikdo tu netvrdil, že se někde navrhují cpu celé ručně, to je jen tvoje bujná fantazie, stejně jako bláboly o kvantové fyzice. To podstatné je, že mezi "automat" a "automat + chytrý chlap" je setsakramentský rozdíl a ten chytrý chlap u AMD prostě není.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.