Vlákno názorů k článku
Procesory AMD Zen 1 mohly propouštět data po dělení nulou, oprava bude v Linuxu 6.5 od bez prezdivky ... - A o kolik(desitek) % padne vykon po aplikovani...

A o kolik(desitek) % padne vykon po aplikovani opravy?

Kdyz se podivate do patche, tak je tam uprava handleru vyjimky, ktera nastane pri deleni nulou.

Takze o kolik bude vykon stroje horsi zalezi jak casto nastava ve vasem kodu deleni nulou.

Prakticky to ale nedava smysl, protoze defaultni userspace handler (signal) kteremu se preda rizeni je nastaveny tak, ze program v momente deleni nulou skonci na obligatni hlasku:

Floating point exception (core dumped).

Sice to muzete odchytavat.. ale reknete mi.. jak to vyuzivate? :D
https://stackoverflow.com/questions/13563688/divide-by-zero-exception-handling-in-linux

Ja tam predevsim vidim hlasku, ze oprava vlastne nic neopravuje, rozmlatte ten CPU palici ...

"AMD Zen1 DIV0 bug detected. Disable SMT for full protection."

To je informace pri detekci mozne chyby. Pak se nainstaluje handler, ktery cisti registry a ten se aktivuje pri kazdem trapu v exception.

Ta hlaska jasne rika, ze ta oprava tu chybu neopravuje, jen mozna a kdovi jestli redukuje. Kdyby tam po zmene zadny problem nebyl, nebyla by tam hlaska rozmlatte to palici. Vypnuti SMT = pokles vykonu o 30-50% = rozmlaceni CPU.

Skoro bych se vsadil, že Java (aspoň teda JIT v C2 a GraalVM) to odchytávat budou, aby nebylo nutné pálit čas na dalších instrukcích, které by řešily kontrolu. Druhá věc je, že koncová aplikace asi typicky dělit nulou zkoušet nebude.

Aplikace zcela 100% delit nulou bude, protoze nekde bere data, a kontrolovat vstupy neni v mode.

OT: Před cca 25 lety jsem na dělení nulou postavil maskování proti heuristice a obecně krokování debuggerem. Vystačil jsem s tím na škole poměrně dlouho. ;-)

M.

Prakticky to ale nedava smysl, protoze defaultni userspace handler (signal) kteremu se preda rizeni je nastaveny tak, ze program v momente deleni nulou skonci na obligatni hlasku:

Floating point exception (core dumped).

Kdyz se clovek nad tim zamysli, tak zjisti ze to je nesmysl a takhle to fungovat nemuze. Program totiz nevi, jestli kernel ulozi coredump. Z cehoz vyplyva, ze tuto informaci vypisuje shell, ktery v navratovem statusu ma informaci jak o tom, ktery signal vedl k ukonceni programu, tak i tom, jestli byl ulozen coredump.