"Je pozoruhodné, že RDTSC trvá u některých Intelů až sto taktů. Přitom nevidím důvod, proč by musela být delší než jeden takt, když je to vlastně jen přečtení registru TSC čítače do %edx:%eax."
Důvod je ten, že ten registr TSC není připojen přímo do výkonných jednotek procesoru, takže za jeden tik do registrů ta data v žádném případě dostat nejdou. Připojit by tam sice šel, ale bylo by to zbytečné plýtvání plochou kvůli optimalizaci instrukce, která se vyskytuje v programech strašně málo.
Takže se takovéhle málo-se-vyskytující instrukce do procesoru hardwarově neimplementují, ale řeší se mikrokódem ... a ten pak až třeba těch 100 tiků trvá (na Pentiu 4 je mikrokód zvlášť pomalý).
Mikrokód je i důvod toho, proč NaN trvá tak pomalu --- holt se návrhářům Pentia 4 chtělo ušetřit pár hradel v koprocesoru, tak to udělali tak, že v případě nějakého málo častého stavu (generování NaN) spustí v procesoru mikrokód, který to dopočítá.
"Vypadá to, jako by ji Linux chytil a do správného FPU registru strčil NaN jako výsledek a zase se vrátil, čímž by emuloval IEEE aritmetiku."
Takhle funguje IA-64. Jeho koprocesor opravdu kvůli jednoduchosti neumí počítat s NaNy, nekonečny a nenormalizovanými čísly (to jsou čísla tak malá, že exponent obsahuje nejmenší záporné číslo a mantisa začíná nulovým bitem) a při jejich výskytu vyhodí vyjímku, kterou zpracuje operační systém a výsledek dopočítá.
Na X86 tyto typy vyjímek nejsou (Linux nic dopočítávat nemusí), nicméně v Intelu to udělali zjevně tak, že výsledek dopočítají pomocí mikrokódového programu uvnitř procesoru.
"Je to poměrně zrádné chování, představte si real-time program, který má zpracovávat nějaká data, ve kterých se občas objeví blok Infu nebo NaNu - rázem to běží tisíckrát pomaleji!"
Real-time programy hlavně nemají běžet na X86 a na Linuxu. Ale na počítačích k tomu určených (nejlépe bez cache) a operačních systémech k tomu určených (Vxworks, Qnx apod.).
X86 i Linux je prostě optimalizováno na minimalizaci průměrné doby výpočtu, nikoli na minimalizaci nejhorší doby výpočtu. Pokud tedy návrhář procesoru může zrychlit běžné násobení třeba o jeden takt za cenu, že zpomalí málo běžné násobení (NaN) o 1000 taktů, tak to klidně udělá, protože optimalizuje průměrnou dobu výpočtu.