Om te voorkomen dat dit tot problemen lijdt, mogen de instructies niet dezelfde registers aanspreken, toegang zoeken tot exact hetzelfde geheugen-adres, toegang zoeken tot exact hetzelfde hardware poort of iets veranderen wat de ander zou kunnen beïnvloeden.
Het zijn juist de registers die dubbel uitgevoerd zijn. Alle data registers, debug registers, segment registers, control registers en debug registers zijn dubbel uitgevoerd alleen niet alle MSR's(machine specific registers) zijn dubbel uitgevoerd maar die worden toch niet zo regelmatig gebruikt dat het wat uitmaakt. Ook de APIC (interupt controller) is dubbel uitgevoerd. In de i7 schijnen nog wat meer gedeeltes er twee keer in te zitten maar daar heb ik nog geen ervaring mee.
Dat de registers er dubbel in zitten is ook wel logisch. De registers bevatten waarden die de staat van het programma bij houden zoals de PC(program counter) die bepaald waar het programma is in de programma code maar ook de data registers mogen niet zomaar van waarde veranderen alks een andere thread aan de slag gaat aan gezien veel compilers parameters en (tijdelijke)variabelen in de registers opslaan. Als de registers niet dubbel uit gevoerd waren zouden ze dus elke keer als een andere hyperthread een register gebruikt opgeslagen moeten worden en die van de nieuwe hyperthread moeten worden opgehaald als je dit doet heb je het niet meer over hyperthreading maar ben je eigenlijk gewoon taskswitches aan het doen. Bij een hyperthreadingachtige implementatie is dus het twee keer uitvoeren van de registers altijd de eerste stap.
(Bron: Intel 64 and IA-32 Archtitectures Software Development Manual Volume 1, Hoofdstuk 2.2.5)
@JoJo_nl:
AMD processoren ook hoor.
Ik snap dat je AMD heel geweldig vindt maar ze hebben niet alles wat intel heeft (en anders om). HTT heeft AMD in ieder geval nog niet, dus AMD proceccors zullen hier (voorlopig) nog geen baat bij hebben. Hoe stoer AMD ook is

. De vraag is ook of deze technologie bij AMD processors wel zo makkelijk toe te passen is en of die enigzins nuttig is, misschien maakt AMD al wel heel efficient gebruik van hun chips.
En hypervisors en hyperthreading hebben (behalve dan dat hun naam met hyper begint) niks met elkaar te maken.
@_js_
4. De source code moet juist wel speciaal voor threads worden geschreven, en als het kan moet de tweede thread zo geschreven worden dat die gecompileerd wordt als instructies die gehyperthread kunnen worden. De compiler is niet echt relevant. Tijdsduur van instructies is ook niet relevant, vooral niet op een OS dat multitasking is, want dan kan op elk moment een ander programma aan de beurt zijn.
Als je als programma baat wil hebben bij HT zal je zoals je al zegt multithreaded of multiprocess code moeten schrijven. Je zal in al je threads de basis regels van multiprocess en multithread programmeren moeten volgen maar je kan gewoon alle instructies gebruiken en je hoeft geen rekening te houden met wat je tweede thread is. Voor de processor is er geen eerste en tweede thread ook kan jou programma gewoon samen met een ander programma op de zelfde hyperthreading processor tegelijk draaien. Het af stemmen van de threads op elkaar op tijdsduur en dergelijken is compleet irrelevant. En een niet multitasking OS zal uberhaupt niks merken van HT.
Wel zijn er enkele optimalizaties die je compiler en je OS kunnen toepassen om wat meer performance winst te krijgen. Deze hebben vooral te maken met de gedeelde resources die de staat van de hele processor of core beïnvloeden zoals caches en enkele instructies.
(Bron: Intel 64 and IA-32 Archtitectures Software Development Manual Volume 1, Hoofdstuk 2.2.5)
(Bron: Intel 64 and IA-32 Archtitectures Software Development Manual Volume 3B, Hoofdstuk 7)
Voor geïntereseerden: Er zijn van deze boeken ook digtitale kopieën beschikbaar op
http://www.intel.com/products/processor/manuals/
[Reactie gewijzigd door jmzeeman op 23 juli 2024 03:50]