Vlákno názorů k článku Test: paměti mají čtyřistakrát delší latenci než procesory od BLEK. - "Je pozoruhodné, že RDTSC trvá u některých Intelů...
-
BLEK. (neregistrovaný)"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. -
vtech (neregistrovaný)"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.)."
Jsou ruzne naroky na real-time. Pro realtime audio vyhovuje latence ~2ms, coz na Linuxu lze, ale pouze za predpokladu, ze si vsechny aplikace v audio retezci daji pozor prave na denormals.
Navic napr. takovy LinuxSampler bych na pocitaci bez cache asi zazit nechtel. -
Tak ale dnes se celkem běžně používá dělení na hard real-time a soft real-time, kde právě u toho druhého tu dobu zpracování obecně zaručit nelze (ale můžeme si např. experimentálně změřit, v kolika procentech případů nestihneme to zpracování dokončit včas a na základě toho se rozhodnout, zda je to pro naše účely dostačující, nebo ne). -
anonymníJestli to spravne chapu, tak Molnarovy realtime-preempt patche (ktere pouzivam) zarizuji presne ten horni limit. Mam v Jacku nastavenou latency 1.33ms (2.66 InOut) a nemam xruny. Mam nalezeny hardware se kterym to funguje (to chvilku trvalo). Pro mne to je realtime. Bouchnu do klavesy, zvuk je bez spozdeni, brnknu na kytaru, zvuk je bez spozdeni. Vic "real" ten cas nepotrebuju :-)
-
BLEK. (neregistrovaný)No, když ti real-time audio nestihne tu 2ms deadline --- tak co? Tak ti v té nahrávce cvakne.
Na druhou stranu, kdyby nestihnutí deadline mělo vést k pádu letadla, smrti člověka nebo výbuchu nějakého zařízení, tak tam Linux být nemůže --- ten linuxový kernel nemáš šanci zkontrolovat, že se tam nikde nedrží spinlock a nescheduluje po dobu 2ms (velmi pravděpodobně tam takové místo je) --- musí tam místo toho být jiný kernel, který je pomalý, jednoduchý, primitivní, bez featur --- ale který na rozdíl od Linuxu jde zkontrolovat, že tam nejsou zakázané interrupty nebo schedulování déle než předepsanou dobu. -
VM (neregistrovaný)Pokud to má mít opravdu jednoduchou funkci a být spolehlivé, tak se tam dá jednoúčelový kontroler, a počítač s Linuxem až za to. V opravdu kritických aplikacích je vhodné jej zdvojit.
Pro Linux existuje real-time patch, který by měl vyřešit základní problémy typu schedulování. S ním by real-time procesy měly teoreticky mít nízkou latenci i na vytíženém systému. Je ovšem nutné otestovat ji v praxi.
Problém bývá s hardware. Například nějaké BIOSy mají tendenci občas na zlomek vteřiny přepnout procesor do systémového módu, ve kterém se OS vůbec nedostane ke slovu. Na takovém hardware pak můžete na real-time zapomenout. -
vtech (neregistrovaný)Kdyz to nestihne, tak hodi XRun, coz se s MAudio Delta 1010LT, nv ovladaci a rt-preempt kernelem nedeje. Jack to hned hlasi (i kdyz je ticho, takze by sis cvaknuti nevsimnul), takze se system dobre ladi. Je ale pravda, ze musis dat bacha na hardware. NVidia ovladace = zlo, IBM ServerRAID = zlo (kupoval jsem si kvuli nemu board s PCI-X a ted tam mam potupne SATA disky :-( ).
Jo a dovolil bych si tvrdit, ze v nekterych nahravkach by mne cvaknuti stvalo vic, nez pad nakyho letadla :-D (Kdyz to clovek zahraje konecne po 50ty bez chyby) -
O procesorech nic nevim, ale kompilatory jiz dosahly takoveho stupne vyvoje ze jsou `poruchy osobnosti' schopny:
~> gcc malfunction.cc /tmp/ccohDlGj.o:(.eh_frame+0x13): undefined reference to `__gxx_personality_v0' collect2: ld returned 1 exit status ~> gcc --version gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-27) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-
Taky jsem si to tak nejdriv vysvetloval. Nez jsem to spusitl na GAIE. 1000 taktu je na me nejak moc. Nemuzu uverit tomu ze by to bylo implementovano mikrokodem.
A i kdyz je GAIA Intel tak nemyslim ze by to RDTSC zmeril nejak zvlast blbe. Na add daval rozumny hodnoty a koneckoncu kdyz meri ted wall time tak 1000 taktu jakekoliv periody je zkratka hodne.
Asi mam malou fantazii ale nedokazu si predstavit co by tam mohli delat takovou dobu. I kdyby to cislo sestavovali po jednotlivych bitech tak by to melo byt const*80 taktu, kde const <=4.
S real-time souhlasim, ovsem i soft real time (coz vlastne striktne neni realtime) dokaze nemile prekvapit kdyz bude znicehonic 1000* pomalejsi....
"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."
Chapal bych kdyby to bylo 1:10. Ale 1:1000 je moc. Krome toho AMD je na tom rychlosti (tradicni) FPU lepe (lepsi repeat-rate pro + a *) nez Intel a presto pocita s NaNy jen o takt dele.
Zkratka mi Intely prijdou menecenny. Duvod proc vychazeji mirne lepsi v aplikacnich testech lezi nejspis mimo jadro procesoru. Osobne podezrivam lepsi algoritmus pro plneni cachi.
