Hezky clanek. Ovsem s malou chybkou ve vysvetleni move elimination. Naprosta vetsina CPU neumi do out-of-order zpracovani zahrnout pamet - tedy ze hodne fyzickych registru zabrani castejsimu pristupu k pameti. To je dost casty omyl a standardne to tak nefunguje. Jedine CPU, ktere tohle castecne umi, je AFAIK Zen2, ale Zen3 uz zase ne.
Já teda věci moc často nekomentuju, páč rozumím jenom regulárním výrazům. Ohledně Intelu nemám co dodat, ale trochu mě mrzí, že se stejnou měrou "neřeší" problémy se stabilitou nových ZENů. Po letech stabilního soužití s OC 2600K jsem si na vánoce postavil nový PC s 5800X, Asus Dark Hero. Výkon super, jen jsem se zařadil do nemalé skupiny uživatelů s problémem nečekaných rebootů v idle. Nepíšu to sem proto, abych byl zaplaven radami nebo urážkami (obojího se mi dostalo požehnaně), ale jen abych vyjádřil svůj osobní názor - klidně bych oželel pár procent výkonu výměnou za stabilní běh. Snad nová AGESA 1.2.0.1 pomůže, když u ní (jako obvykle) uvádějí Improved stability...
Tolik pro vtipálky s rychlým/špatným Intelem a pomalou/správnou Motorolou. V dnešní době bych tam se stejnou nadsázkou mohl přidat AMD, které by ani nedokončilo větu :)
Intel core s nVidiou zorganizujú súkromnú párty, pozvú aj v počítačovej brandži menej známu
dvojku Ryzena s Radeonkou.
Nálada je v plnom prúde, sovietske šampanské tečie potokem, čierny hrášek mizne na kilá,
proste pařba jak sviňa. Zrazu kohosi napadne, čo tak si zasexovať, všetci s nadšením prijímajú
a už aj idú na vec. Intel pojme nVidiu a šup do spálne vpravo, Ryzen schytí Radeonku a šup do
spálne vľavo.
Po dvoch hodinách nespútanej vášne a čísiel padajúcich jak v športke sa Intel s nVidiou rozhodnú
pre krátku osviežujúcu fajčpauzu. Príjemne orgiami znavení čakajú v objatí na Ryzena s Radeonkou.
Prejde hodina a po červených kremíkoch ani smrad, prejdú dve hodiny, stále nič....
Po troch hodinách vtrhne do haly nasraná Radeonka a zapiští –
„ tomu debilovi zas nefunguje usbpinďa „
To nechápete dobře - pokud Rocket Lake tímhle trpí, tak už je efekt teď zahrnutý v těch benchmarcích, které jsme viděli. Takže další snížení už nebude.
Mimochodem zvýšení výkonu v novějších BIOSech se už částečně potvrdilo (i když samozřejmě není úplně jasné, jestli už ty změny nemohly do toho testu AnandTechu doputovat před jeho vydáním, ale spíš mi přijde, že ne). Zítra k tomu dám dohromady nějaký komntář :)
Faktem je, že Intel chyby okamžitě opravuje, a když si nikdo evidentně ničeho ani nevšimnul, tak to asi takový problém nebyl. No a pak tady máme AMD, které, po více než roce (možná dokonce 2?) oznámilo, že snad už v dubnu, s AGESA 1.2.0.2, opraví chybu s USB porty. Takže klasika. AMD nové kousky opravdu nenaučíš.
A ono něco takového je v článku napsáno?
Já to, co je v článku napsáno pochopil tak, že když mám za sebou instrukce:
MOV adresa v paměti, registr
MOV registr, něco
a registr je v obou případech stejný, tak ta druhá instrukce nemusí čekat, až je ta první instrukce dokončena, ale použije jiný virtuální registr.
Ale vůbec ne. Jen je vidět, kdo vlastní akcie AMD, a udržováním hype se stará o jejich zhodnocení. Mě jen mrzí, že jsem nezainvestoval před pár lety, kdy bylo AMD pár týdnů od krachu a akcie byly za babku. Teď už do toho vstupovat asi nemá cenu, AMD je teď topdog a nevím jak moc by se investice zhodnotila, jaký potenciál k růstu ještě má. Mě by teď přišlo dobré investovat do Intelu, ten už snad níž nemůže jít. Ale jak se znám, tak nakonec stejně nic nekoupím.
Nepáči ? Nevadí, v linku máš vtip od milovanej Rosalindy - sice netušíme v čem je problém, ale určite to opravíme a samozrejme nové chybky pribalíme:
https://videocardz.com/newz/amd-announces-agesa-1-2-0-2-that-solves-intermittent-usb-connectivity-issues
Jako AMD určitě není bez viny, ale evidentně jsi Intel fan, když nevidíš jak děravá byla a pořád je architektura Intelu - byly tu články snad každý týden o dalších a dalších chybách o kterých Intel věděl a řešil je prakticky až po uveřejnění (měl čas na opravu minimálně rok). Takže obě firmy mají máslo na hlavě, ale spílat jen jedné firmě moc fér není.
Ta Move elimination by byl případ MOV registr,registr
Teď teda doufám, že to chápu dobře, ale s tím, že přejmenování omezuje vylévání do paměti, jsem to myslel tak, že když jsou v kódu dvě jinak nezávislé sledy operací, kdy kvůli omezenému počtu architektonických registrů ty dva řetězy instrukcí jedou nad stejnými registry (ale datová závislost tam reálně není, je to prostoě proto, že registry došly), tak by jedna ta sekvence musela normálně čekat, až bude ta první hotová. Ale s přejmenováním registrů budou mít obě ten registr z svého pohledu pro sebe a CPU je bude moc provést paralelně.
za tou jednoduchostí je ale spousta let empirie. Chápu že jsi naštvaný, ale tohle se děje všude. Že Asus možná umí desky pro Intel neznamená, že je umí pro AMD.
Vybral sis gamesnickou desku od patlalů z Asusu (oni jsou tedy dnes patlalové všude, ale jen u Asusu to ženou vždy na ostří nože), ale může za to AMD. ????
edit: netvrdím, že AMD v tom nemá prsty, ale [zřejmě jsou|prokazatelně existují] desky, ve kterých ty Zen3 běhají spolehlivě, takže čistě procesorem to asi nebude.
To je spravne. Doufam, ze moc neslovickarim, ale nejak nevidim souvislost s vylevanim registru do pameti. Kdyz programatorovi dojdou registry, musi neco odlozit do pameti, coz se odborne jmenuje vylevani (register spilling), ale prejemenovani registru tomu nijak nezabrani. Jen spolecne s OOO engine pomuze kompenzovat latenci, pokud je to mozne (ale to je obecna vlastnost OOO i bez pametovych operaci). Ten zapis a nacteni do pameti/cache se musi "fyzicky" provest vzdy. Jen u Zenu 2 to za urcitych okolnosti funguje trochu jinak. Tohle je celkem neintuitivni vec, proto si hodne lidi mysli, ze vic fyzickych registru pomuze snizit pristupy do pameti a na poctu architektonicjych registru zase tolik nezalezi. Opak je ale pravdou. Proto se pravidelne zvysuje pocet arch. registru (z 8 na 16 u x64 a 32 u AVX512).
Teď se zpronevěřím svým zásadám a naprosto zbytečně zareaguju - co konkrétně může empirik Tynyt označit na Dark Hero jako dohnané na ostří nože? Nejlépe i s odborným rozborem (nemusí být vlastní).
Tím za sebe končím tuto offtopic odbočku a zase jen budu dál žasnout nad českými IT diskuzemi, všechna čest výjimkám.
Hmm, no tohle je pro mě už hodně tenký led, ale myslím, že eliminace toho zápisu/čtení zpátky by měla být možná i mimo tu feature u Zenu 2 ( počítám že je řeč o tomhle? https://www.agner.org/forum/viewtopic.php?t=41 ).
Myslím, že aspoň někdy by to měl umožnit store to load forwarding.
Taky si nejsem uplne jisty, ale myslim, ze store-to-load forwarding umoznuje jen cist ze store bufferu s latenci nekolik taktu (Intel tohle zvlada o dost lip). Teoreticky je mozne, ze data zustavaji nejakou dobu v registrech jako spekulace, ale tezko rict, moc bych na to nesazel, protoze by to odhalily benchmarky. Mozna tohle umi prave ten Zen2.