Ontwikkelaars: performance HyperThreading slecht

HT-aware is iets anders dan het zien van 2 CPU's. Bij mij staan ook dubbele aantallen CPU's in task manager. Wat ik daarmee bedoel is dat het OS snapt dat de tweede (en eventueel vierde, zesde,...) processor geen volledige CPU zijn, maar slechts een extra set registers op hun maatje. Dat is iets dat ze bij WXP en W2K3 (en overigens bij vrijwel geen enkel OS) nog voor elkaar hebben.

Als je in je scheduling ervan uitgaat dat je 2 CPU's hebt en je hebt er inwerkelijkheid maar 1,2 dan kan je OS verkeerde scheduling beslissingen maken.

Maar je hebt gelijk, er is inmiddels een HT fix van MS, die zorgt er voor dat je in Task Manager 100% te zien krijgt als beide deel CPU's vol belast zijn. Helaas is dat een optische fix (of beter gezegd, een fix van HKEY_PERFORMANCE _DATA, die door taskman uitgelezen wordt) en heeft dit geen invloed op de scheduler.

Dat hebben ze bij XP en 2003 wel degelijk voor mekaar.
Maar dan met name in situaties waarbij je meerder HT cpu's hebt.

Bij een enkele cpu is er weinig aan te verbeteren. Het is voor het OS bijna onmogelijk om te bepalen in welke situaties er wel of niet een threads naar de tweede core moet gaan. Dat vereist zowel analyse van de threads dat je de voordelen van HT dan al weer kwijt bent.

Maar eh, kun je eens even onderbouwen dat het alleen om een optische fix zou gaan. (met name wanneer tests al lang hebben uitgewezen dat dat niet het geval is)

En kun je onderbouwen waarom HT maximaal een factor 1,2 zou bereiken wanneer tests op bv Exchange een prestatie winst van 30% laten zien?

Bij meer CPU's wordt het probleem niet kleiner dan bij 1 CPU. De scheduling beslissing om een thread op een 'mate' processor te zetten blijft een moeilijke. Het probleem wordt bij meer CPU's eerder groter omdat je twee threads beter op CPU 0 en CPU 2 kan zetten (twee verschillende fysieke CPU's) dan op CPU 0 en CPU 1 (twee mates op dezelfde fysieke CPU). Om maar niet te spreken van welke threads je het beste samen op 1 CPU kan laten lopen..... Neem van mij aan dat nog geen enkel OS dat kan, je moet namelijk in de toekomst kunnen kijken om de goede beslissingen te nemen.

Dat de scheduling voor de mate processor moeilijk is heb ik zelf al aangegeven. De enige echte HT scheduler die ik ken zit in Linux, en die geeft maar een zeer marginale verbetering t.o.v. de standaard SMP scheduler.

Aangezien HT ook bij Intel verdrongen wordt door echte multi core verwacht ik dat er nog maar erg weinig HT verbeteringen gaan komen in de toekomst.

Overigens heeft ook multicore zo zijn eigen code in de schedulers nodig, zo is het belangrijk om te weten of de cores op 1 die bijvoorbeeld een deel van de cache delen, en zo ja welk deel.

Het is een optische fix omdat het niets veranderd aan de aansturing van de CPU. Het geeft alleen een andere interpretatie van de getallen.

Een HT CPU kun je per definitie niet op 100% belasten op beide deel CPU's omdat ze de processorcore delen, en er kan maar 1 van beide deel CPU's echt bactief zijn. HT benut cycles die anders gemist zouden worden door cache misses e.d. waardoor de beide deel CPU's een deel van de tijd schijnbaar tegelijkertijd werken.

Ik ben trouwens wel benieuwd naar die tests, heb je een hyperlink?

Wat die factor 1,2 betreft, dat is eenvoudig aan te tonen door een programmaatje te schrijven dat twee CPU bound threads actief heeft. Dat bij individuele applicaties als exchange een factor bereikt wordt die iets hoger ligt kan er bijvoorbeeld aan liggen dat exchange op HT twee I/O threads actief kan hebben waardoor de I/O veel efficienter verloopt. m.a.w. die 30% hoeft niet geheel op het conto van de CPU te komen. Ook hier ben ik wel benieuwd naar de hyperlink.

Bij meerdere cpu's wordt het probleem inderdaad niet kleiner. Maar zoals je zelf al aangeeft moet je dan beseffen dat je beter twee threads op cpu 0 en 2 kan zetten dan op 0 en 1. En dat is dus precies wat ze in die versies verbeterd hebben. Dat is dan ook het enige wat je vrij makkelijk kunt verbeteren. Voor de rest blijft het verdelen uiteraard net zo moeilijk als bij 1 cpu.

Intel heeft nooit de illusie gehad dat HT te vergelijken zou zijn met multicore. Het is vanaf het begin af aan bedoelt geweest als een goedkope manier (heel weinig chip oppervlakte nodig) om de efficientie (en dus prestatie) van de cpu te verbeteren. Aangezien gemiddeld gezien de prestatie verhoging gunstig is tov de extra oppervlakte is erg weinig reden om aan te nemen dat HT verlaten zal worden in de toekomst. (tenzij ze uiteraard een totaal ander design gaan gebruiken)

Je herhaalt nu dat het alleen een optische fix is, maar ik zie nog steeds geen onderbouwing daarvoor.

Je kunt uiteraard een HT cpu wel 100% belasten op beide deel cpu's. 100% betekent dan gewoon dat de cpu op elke moment maximaal benut wordt en niet idle staat.
2x 100% is dan de juiste aanduiding voor de processor belasting.
Dat betekent echter niet dat 2x 100% benutting ook altijd dezelfde absolute prestatie betekent. Dat hangt immers af van de efficientie waarmee beide "delen" kunnen werken.

Maar processor usage gebruik je ook niet om prestatie te meten, maar om de belasting van de cpu te meten. En dat doet het dan juist uitstekend.

Overigens is het absoluut niet zo dat maar 1 van beide deel cpu's echt actief zijn. Ze kunnen wel degelijk allebei tegelijk actief zijn. Dat is nou juist het gegeven waar HT om draait.

Wat betreft die factor 1,2. Heb je een link naar zo'n programmatje? Ik ga er niet zelf één schrijven, en al helemaal niet als ettelijke tests al veel hogere absolute prestatie winsten hebben laten zien. (waarvan een aantal uiteraard best case scenario's die je niet vaak tegenkomt, maar die duidelijk maken dat die factor 1,2 niet klopt)

Wat betreft de link naar exchange tests: Hier is een goed voorbeeld van HP:
http://h71019.www7.hp.com..._ExchangeonHPProLiant.pdf

Neen, dat een Pentium 4 met Hyper-Threading te verkiezen is boven elke andere single-core CPU zonder Hyper-Threading (ook die van AMD).

Dat ik momenteel een AMD dual-core heb was enkel om aan te duiden dat ik geen "Intel lover" ben. Toch ben ik van mening dat HyperThreading een zeer mooi stukje technologie is en ik hoop dat AMD het ook ooit toepast.

Toch wel. Een thread kan wachten op IO, z'n timeslice afstaan aan de volgende thread (of erger, wachten tot het einde van de timeslice), en wanneer de volgende thread net gestart is komt de IO binnen en wordt weer de eerste thread gestart. Als de data dan incorrect blijkt stuurt die weer een aanvraag, etc.

Dat kan zo rond blijven gaan en uiteindelijk gaat de tweede thread maar héél langzaam uitgevoerd worden en lijkt je systeem vast te zitten (is ook zo). Met HyperThreading wordt dit voorkomen want de tweede thread kan gegarandeerd z'n instructies uitvoeren.