Vlákno názorů k článku
Bug v implementaci hyperthreadingu procesorů Intel
od Rudolf Dvořáček - U Intel procesorů vypínám HT záměrně u každého...
-
JA (neregistrovaný)
Respektive ma se spustit na polovicnim poctu vlaken nez ma CPU, pokud je zaply HT. Jelikoz u HT jsou vsechny jadra ekvivalentni. Jedni pisou, ze si tu virtualizaci ridi CPU sam, jini, ze si to ridi scheduler (aspon ve windows, u linuxu to bude asi stejne). Tezko rict, jak to je. Dava smysl, ze si fyzicky jadra ridi CPU sam, uz jenom treba kvuli boostu, kdy pri zatizeni dvou jader vybere ty fyzicky nejvzdalenejsi, aby se co nejlip odvedlo teplo a pak je treba mezi sebou strida a OS o tom vubec nemusi vedet. Nicmene OS ma vlastni scheduler, takze by to u HT mohlo vest k propadu performance, kdyby si OS myslel, ze jsou nektere jadra nevytizene. Z tech polopravd a polomytu jsem dosel k pravdepodobnemu zaveru, ze hardwarove jsou jadra virtualni a CPU si je zatezuje podle potreby nezavisle na OS (ale OS muze patrne nejake konkretni jadro fyzicky vypnout, pokud by bylo treba spatne). A o HT ma OS povedomi, ktere je ktere a prirazuje to podle vytizeni, kdy HT virtualni jadra zacne pouzivat az kdyz je potreba a CPU HW si to zas rozdeli mezi jednotlive fyzicke jadra podle optimalizace. Takhle jsem pochopil, ze to funguje na windows, coz tak nejak dava smysl a pro SW jde o transparentni reseni. Jestli existuje nejaky prepinac, kdy se rekne, ze se chce, aby bezelo preferencne jen na fyzickych jadrech, jsem nenasel. Ale zas by to moc nedavalo smysl, protoze to stejne ridi scheduler.
Nicmene doted jsem zil v tom, ze kdyz pustim proces s /affinity 0xaa nebo 0x55, ze se pusti jen na fyzickych jadrech. Ale asi je to uplne jedno a bude to stejne jako kdyz se pusti jako 0xf, 0x17 atd .... -
Tento pohlad je viac menej uplne mimo. Pri HT procesore thready nie su virtualne, su plne realne, ale nie plne vybavene. Jeden par instrukcnych pipeline zdiela viacero vypoctovych blokov, ktorych je v modernych superskalarnych procesoroch tolko, ze ich prakticky nemozno vsetky vytazit naraz jednou pipeline. Dve pipeline to ale dokazu.
OS ma povedomie o tom, ze dve pipeline (navonok sa javia ako jadra) zdielaju vypoctove bloky, pretoze sa to da vycitat z topologie systemu. Uz som sa nezapodieval tym, kde je tato informacia k dispozicii, ale pravdepodobne to bude niekde blizko ACPI.
Kedze jadra su realne a OS ma povedomie o HT, ma nejaku moznost na vysokourovnove priradovanie vlaken na jadra, ktore nie su v jednom HT pare. Typicky Windows priraduje vlakna tak, aby sa najprv vytazili vsetky HT pary a az ked pocet vlaken prekroci pocet dostupnych parov zacne zatazovat aj sekundarne pipeline v pare.
To ale nefunguje na nizkej urovni, ak je raz nejaky kod vykonavany na nejakej pipeline je pomerne drahe ho prehodit na inu pipeline (lebo cache a context switch) a procesor sam o sebe to ani nemoze spravit. Takze ak si dve pipeline v ramci HT paru zacnu silne konkurovat a zacne superenie o vypoctove bloky, mozu byt instrukcie v pipeline prekladane NOPovymi cyklami a dojde k spomaleniu behu jedneho, alebo oboch vlaken (zalezi na strategii planovaca instrukcii). OS sa to v podstate nema ako dozvediet, pokial na to neexistuje v procesore nejaky velmi specificky counter a aj ten bude mat vysoku mieru neistoty (pretoze existuje viacero dovodov pre vlozenie NOP do instrukcnej fronty).
Hore popisane ale plati len pre 2x HT videne na platforme x86. Napr. SPARC riesi HT tym sposobom, ze viac (radovo 8) pipeline (ktore sa javia ako jadra) sa deli o jednu realnu pipeline a instrukcie z nich su do pipeline strkane systemom round-robin.
-
Topologie systému se vyčte z ACPI tabulek System Resource Affinity Table (SRAT) a System Locality Distance Information Table (SLIT), možná i z nějakých dalších.
NT thread scheduling je trochu popsaný třeba od Davida Proberta.
http://www.i.u-tokyo.ac.jp/edu/training/ss/lecture/new-documents/Lectures/03-ThreadScheduling/ThreadScheduling.pdfTen má mimochodem i zajímavé video tady:
https://channel9.msdn.com/Shows/Going+Deep/Windows-Part-I-Dave-Probert -
tom (neregistrovaný)
Nesmysl. Numerické aplikace např. často běží rychleji s polovičním množství threadů (jeden na jádro) než na HT se dvěma na jádro, protože jednak pak má každé jen poloviční L1 cache, jednak při suboptimálním škálování je režie poměrně větší. Stejně jako OP, HT je první věc, kterou vypínám.
-
Zrovna numerické aplikace, obzvlášť ty, které jsou na GPU rychlejší než na CPU, budou na CPU vypadat jako nějaká tight-loop a masivní zpracování dat v paměti, s častým využitím stejné oblasti paměti. Tedy jim bude vadit soupeření o L1 cache a nebude je moc zajímat délka pipeline. Pokud se takováto vlákna potkají v jednom core, tak budou velmi často soupeřit o stejné bloky procesoru, právě proto, že tělo smyčky je krátké. Nicméně jiné aplikace mohou vypadat jako delší kusy (delší kusy kódu než dojde ke smyčce), který používá paměť "náhodně", takže tam cache tolik nepomůže. Pak naopak více pipelines pomůže urychlit načítání kódu do procesoru a díky HT budou ty dražší části procesoru, kterých je tam jen tolik kolik je "fyzických jader", budou lépe (více) využité.
-
Pokud vím, tak při mnoha cache misses má HT šanci pomoci tím, že při čekání na paměť paměť vláknem se dostane ke slovu druhé vlákno. Je samozřejmě otázka, jestli to vyváží poloviční velikost cache. Záleží i na velikosti té malé oblasti paměti a velikosti L1 cache.
Při obtížně predikovatelném patternu přístupu do paměti je HT asi celkem win, ale to je trošku jiný případ než problémy typicky vhodné pro GPU a časté využití stejné oblasti.
-
To asi nebude moc typický scénář. Navíc algoritmy tohoto typu většinou mají zjednodušeně řečeno konfigurovatelnou velikost zpracovávaného bloku. Různé CPU mají různě velkou cache, a pokud chcete předejít tomu aby data vypadla z cache, tak není moc jiných cest. Pak není problém dynamicky nastavovat velikost bloku, nebo počet threadů. Pokud chcete optimální výsledek, chce to dedikované výpočetní nody, kde na každém jede jen jedna úloha (resp. část jobu), čímž mimo jiné minimalizujete cache miss rate normálně navyšovaný thready nesouvisejícími s vaší úlohou.
Na desktopovém PC ale CPU většinu času nic moc nedělá. Multicore CPU jsou pak využity spíš pro zrychlení okamžité odezvy, když jedno jádro přehrává MP3, druhé skenuje zaváděnou aplikaci pomocí antiviru, a další jádra se starají o inicializaci knihoven, správu resources atd. Na tenhle scénář jsou optimalizované třeba "mobilní a bezvětrákové" CPU Kaby Lake, které se po delším intenzivním běhu všech jader nestíhají chladit, a výkon jde prudce dolů. Současné vytížení všech jader "tvrdými" výpočty totiž na desktopu (nemluvě o notebooku nebo tabletu) nastane poměrně výjimečně, když se řekněme rendruje scéna v CADu, komprimuje video, kompiluje větší projekt, počítá se něco většího v Excelu apod.
Takže na typickém multipurpose PC (a to se bude týkat i velkého procenta serverů) HT ano. Na výpočetním clusteru záleží na úloze, ale nic nezkazíte když necháte HT zapnutý, a pohrajete si s "velikostí bloku" a počtem threadů.
-
FíkZlatý podporovatelVětšinou na HPC se HT vypínal, ale se zapnutým HT to může jet rychleji. Třeba lammps uvádí 10-30% rychleji s HT: http://lammps.sandia.gov/doc/accelerate_intel.html
ČLÁNKY DO MAILU