Nejsem CPU HW Engineer, ale kdyby to bylo tak jak říkáš neměly by mít snad ARM RISC takřka stejný výkon jako mají X86 CPU, které jakty tvrdíš běží vnitřně stejně jako RISC a čili stejně jako ARM ?

Jak je potom možné, že Snapdragon 835, což je Qualcomm® Kryo™ 280 CPU, Octa-core, 2.45Ghz, 64bit, má problémy pořádně vůbec rozjet už upravený Windows pro ARM ?

Na ARM CPU si dneska zahraješ akorát tak Starcraft 1 nebo Heroes 3, ale ten výkon tam prostě není. Mezi architekturou ARM a x86/x64 je propastný rozdíl ve fungování a bude trvat ještě velmi dlouho než se to vyvine do opravdu plnohodnotné formy, která dokáže v mobilní sféře plně nahradit jakákoliv mobilní CPU (tím netvrdím, že by ARM nebyl už dneska vhodný do malých notebooků, které jsou určené pouze na youtube a emaily)

> A kvůli překladu CISC->RISC má větší spotřebu a větší počet tranzistorů. ARM je RISC rovnou, takže jsou porovnatelné

Placate tady oba dva blbosti.... za prvni, ze "x86 je komplexni a ARM je orezavatko" je blbost. Za druhe, ARM uz davno neni RISC. Nedavno ARMv8 ziskal instrukci na dekodovani floating-point cisla ve formatu JavaScript: https://stackoverflow.com/questions/50966676/why-do-arm-chips-have-an-in...

Realne x86 a ARM procaky dnes jsou vic podobne nez rozdilne, teoreticka vyhoda ARM je akorat v tom, ze dekoder je jednodussi (protoze instrukce maji fixnou velikost).

ARM licenci dostane kazdy ? O tom by ti mohl vypravet Huawei, kterymu ji sebrali...

"- X86 je CISC, ale vnitřně kvůli výkonu běží jako RISC"
To je bezny omyl. x86 je CISC a smytec. To ze ma velmi pokrocily dekoder, ktery optimalizuje na vnitrni instrukce ktere jsou jakoby RISC neznamena, ze to je RISC, nebo ze to vnitrne bezi jako RISC.

"- X86 je zabržděné díky tomu, že Intel nikomu nedá licenci. Není volná soutěž, není zlepšování."
To je take omyl. x86 licenci ma i VIA. A je velkym hracem? Neni. A proc neni? Kdyby to bylo lukrativni, pak by se jiste nasel silny investor. Duvod je ten, ze delat x86 dobre neni o tom vlastnit licenci.

Navic x86 neni zabrzdene. Nove CPU vznikaji, nove instrukce vznikaji, nebo se rozsiruji, vykon jde nahoru. Ekosystem operacnich systemu a programu take nijak nezpomaluje, superpocitace se na tom stale stavi... Mozna se vam to tak jevi z velmi omezeneho pohledu, doporucuji rozsirit obzory a krapet analytickeho mysleni. Napr. pokud vam imponuji pokroky v ARM, tak nejsou zaprve nijak zazracne, zadruhe neni zadna garance, ze ten prinos bude nadala takovy. Limity ma kazda architektura, ARM neni vyjimkou.

Na tomhle omílání, jak je ARM pomalý ve WindowsARM je krásně vidět právě to, jak Wintel (v tomto bodě spíš jen Win) blokují trh CPU...
To přeci není pravda, že to chodí pomalu, výsledky těch WinARM notebooků byly vesměs dobré a ve vazbě na odběr dokonce výtečné, jenže jaksi pouze v aplikacích, které už byly psané pro WinARM. Podstata problému je ale v tom, že Windows za sebou táhnou neskutečnou řadu aplikací vzniklých už někdy v době 80386, které už nikdo nepřepíše a CPU s jinou architekturou je dokáží zprovoznit jen dost divokými postupy emulace, což v reálu znamená, že se 50% (a někdy i více) výkonu doslova promrhá na emulaci či případně prostě zahodí tím, že se něco z nového CPU nevyužije.
Tohle je podstata problému - přechod na jinak pojaté CPU (ať už to bude ARM nebo něco jiného) v prostředí WIndows bude narážet na zpětnou kompatibilitu a v podstatě na to není řešení...

Tak já se teda rozepíšu, když to nestačilo v rychlosti.
Chyba v instrukci rdrand má širší okolnosti. Pokud používám funkci pro náhodné číslo, očekávám náhodné číslo. To rdrand nejen že neplní, ona dokonce vrací vždycky stejné. Takže by bylo lepší, kdyby tam ta instrukce vůbec nebyla. To je chyba. Ano, může se stát.
Protože procesy při vydávání nového procesoru s takovými věcmi počítají, provádí se testování. Změnit hardware je totiž mnohem obtížnější, proto máme možnost zavést do něj mikrokód a tím některé jeho funkce změnit. Nicméně je třeba podrobit takovou věc testování.
Tvrdím, že ten procesor je ofláknutý právě proto, že nebyl dostatečně otestován. Přitom se nejedná o žádnou okrajovou chybu. Jedná se o chybu, která:
1) nastává vždy
2) týká se většiny běžných linuxových distribucí
Stačilo by, aby někdo zkusil spustit tuhle instrukci dvakrát, a zkontrolovat, jestli nevrací stejné hodnoty. Generátory náhodných čísel jsou docela věda, pro účely tohoto příspěvku to zjednodušme do toho, že si to rozhodně zaslouží daleko hlubší testování než porovnávání dvou vrácených hodnot, aby se to dalo nazvat použitelným pseudonáhodným generátorem. Nebylo provedeno ani to. Přitom kvalita náhodnosti generátoru pseudonáhodných čísel je klíčová po kybernetickou bezpečnost, a rozhodně je lepší, když funkce vrátí chybu, než když vrátí vždy stejnou hodnotu a bude se tvářit, že je vše v pořádku.
Vaše softwarová oprava spočívá ve výměně mikrokódu. Což ale vyžaduje restart. Ať už aktualizací BIOSu nebo zavedením nového mikrokódu při startu operačního systému. Nevím jak vy, ale u Linuxu jsme si docela odvykli na potřebu restartu, protože se podstatně snižují příležitosti, kdy je nutné ho provést. V podstatě se to omezuje jen na problémy s hardware, prakticky všechen software umíme patchovat za běhu, jádrem operačního systému počínaje. Jenže vzhledem k tomu, že se jedná o bezpečností problém, ty restarty budou nutné. Ryzen je docela fajnová věcička např. na levný router s velkým počtem rozhraní a slušnou routovací kapacitou díky množství přerušení, který je se SMT schopný obsloužit, takže můžeme být jako uživatelé internetových přípojek za pár stovek, kde jsou tyhle routery typicky používané, rádi, že se na to přišlo dříve, než po tom malí ISP sáhli.
Přitom stačilo vzít Ryzen a nabootovat na něm Ubuntu. Ani o to se nikdo nepokusil?
Jediná distribuce, které se tohle nestalo, byla Mageia. A proč? Protože je napadlo to otestovat a opravit. Ano, ostatní distribuce zareagovaly velmi svižně. Ale jejich reakce nespočívá v opravě chyby ale v jejím obejití, tj. nepoužití rdrand.

Při vydání prvního ZENu jsme se potkávali s podobnými věcmi. Dovedu pochopit, že Microsoft do Windows udělal špatný scheduler. Co ale nedokážu pochopit, že scheduler a ACPI fungovalo špatně i na Linuxu, do kterého si AMD mohlo hrábnout, kdykoli se mu zachtělo. Což také po vydání začalo činit. Microsoft se vyjádřil v tom smyslu, že testovací vzorek ZENu nedostal včas, aby mohl scheduler udělat (tohle beru s rezervou, protože to bylo neověřené tvrzení a nechce se mi tomu věřit; Microsoft to mohl prohlásit i ve vlastním zájmu v rámci širší spolupráce s Intelem). A nezapomínejme na chybu šifrování paměti EPYCu, která v některých případech (VPS hosting) byla killer feature, a ukázala se jako naprosto zbytečná a nefunkční.

Chápu, že jsem slovíčkem "odfláklý" sáhl na vaše ego. Mně je jedno, která značka je na procesoru napsaná. Ale jsou to věci, které se dříve nestávaly, i za cenu toho, že procesory šly na trh později. Proto trvám na tom, že chyba rdrand je příkladem odfláknutí. Tedy vynechání některých jednotlivých podprocesů z celého procesu vývoje a vydání na trh nového procesoru za účelem jeho zrychlení.

Vzpomeňte si na vydání nové architektury u Phenomu, kde se vyskytovala chyba, která byla extrémně vzácná, a vedla jen k pádu operačního systému, ne transparentní chybě v běhu s velkým bezpečnostním rizikem. A Phenom byl najednou podle internetových diskuzí naprosto neprodejný. Od té doby se naše tolerance k chybám při vydání posunula o pořádný kus.

Abychu udělal vašemu egu dobře, kdybych se měl rozepsat o Intelu, opotřeboval bych při tom několik klávesnic.
A k tomu stihomamu se vyjadřovat moc nebudu. Nemá smysl vysvětlovat, že 5 > 2, nebo proč je více lepší než méně, případně jaké neduhy má závislost na jedné konkrétní omezené a nesvobodné platformě.