Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 98 reacties

HyperThreading aankondigingEr zijn de laatste tijd een aantal geruchten voorbij gekomen over een 'geheim wapen' van AMD, een feature die bij gebrek aan een (code)naam 'omgekeerde HyperThreading' wordt genoemd, refererend aan de marketingterm voor Intels implementatie van SMT in de Pentium 4. Uit de vage omschrijvingen die uit de geruchtenmolen zijn komen rollen kunnen we alleen het globale idee opmaken: het zou er op neerkomen dat twee (of zelfs meer) cores tegelijkertijd aan dezelfde thread kunnen werken. Hierdoor zou software die helemaal niet geoptimaliseerd is voor dual- of quadcoreprocessors toch sneller kunnen draaien op zulke chips. Er zijn verschillende manieren waarop zoiets in theorie bereikt kan worden. Een populaire - maar onwaarschijnlijke - verklaring is dat cores elkaars execution units kunnen gebruiken, met andere woorden: dat instructies naar een andere core geschoven kunnen worden op het moment dat het te druk wordt. In technische termen heet dat concept Cluster Multithreading.

Er zijn verschillende redenen waarom deze aanpak een onwaarschijnlijke is: ten eerste komt het niet vaak voor dat de prestaties van een core daadwerkelijk beperkt worden door een tekort aan execution units. De Athlon 64 heeft er bijvoorbeeld maar liefst negen aan boord: drie voor floating point (FPU), drie voor integers (ALU) en drie voor geheugenadressen (AGU). In totaal kan de processor dus aan negen opdrachten tegelijk werken. Helaas wordt dat in de praktijk vrijwel nooit gehaald: zo kan de architectuur bijvoorbeeld maar drie instructies tegelijk de pipeline ingooien en ook maar drie resultaten tegelijk wegschrijven. Verder is het zo dat de meeste software die drie nog niet eens haalt: het gemiddelde IPC (instructions per cycle) van x86-processors in de bekende benchmark SPECint2000 ligt in de praktijk maar net boven de één.

Intel Itanium 2-logoMeer parallellisme is zeker niet onmogelijk: een academisch onderzoek heeft aangetoond dat de Itanium met een geniale compiler richting de vijf kan gaan in dezelfde benchmark. We hebben het dan echter over een EPIC-systeem, waarbij al het mogelijke parallellisme per definitie al in de code zelf verwerkt zit. De processor hoeft dus niets anders te doen dan 'dom' het programma uitvoeren. x86 kent zoiets niet: de processor moet tijdens het uitvoeren van de instructies helemaal zelf uitzoeken welke opdrachten eventueel tegelijk kunnen draaien. Als een programmeur een halfuur moet wachten op zijn compilatie vindt hij het misschien wel veel, maar voor een processor is een microseconde al een eeuwigheid. Iemand met een praktisch idee dat kan helpen om de gemiddelde IPC met een tiende te verhogen kan goud geld verdienen bij Intel of AMD. De kern van het verhaal is dat het toevoegen van een paar extra eenheden veel makkelijker is dan het vullen ervan.

Waarom worden er dan toch negen execution units in de Athlon 64 gebakken? Ten eerste werkt een processor intern niet echt met x86-instructies, maar worden die vertaald naar een interne instructieset, zogenaamde micro-ops. Soms gaat die vertaling één op één, maar vaak heeft een x86-instructie ook twee of drie micro-ops nodig. In zeldzame gevallen kunnen het er zelfs honderden zijn, maar moderne software loopt daar met een grote boog omheen. Een instructie kan in sommige gevallen dus wel meerdere eenheden bezighouden. Dit komt bijvoorbeeld voor in code die geen registers gebruikt, maar een berekening rechtstreeks op een geheugenlocatie uit wil voeren. In dat geval moet een AGU eerst het fysieke adres berekenen voor een ALU of FPU de som kan uitvoeren. Verder hebben veel instructies meerdere kloktikken nodig, waardoor een eenheid een tijdje bezig kan blijven terwijl er geen nieuwe invoer binnenkomt. Ook hebben de eenheden verschillende specialismes: één van de floating point-eenheden kan bijvoorbeeld vermenigvuldigen, terwijl de ander kan delen.

AMD Hammer presentatie - core overview

Er zijn dus wel scenarios te bedenken waar extra eenheden kunnen helpen om de prestaties te verbeteren: als er bijvoorbeeld twee dezelfde instructies tegelijk uitgevoerd kunnen worden terwijl er maar één eenheid beschikbaar is om die specifieke instructie te verwerken. Dus waarom zou er dan niet even een tweede eenheid 'geleend' kunnen worden van een andere core? Het antwoord daarop is de latency: als de twee instructies op dezelfde core uitgevoerd worden gaat eerst de eerste instructie de pipeline in, en vervolgens de tweede. De vertraging is in dat geval maar één tik. Met een techniek als Cluster Multithreading zou de instructie eerst naar een andere core gestuurd moeten worden. Vervolgens moet die andere core de data krijgen waar mee gewerkt moet worden, en na de berekening moet het resultaat ook nog worden teruggestuurd. Dit alles kost een hoop tijd: de Athlon 64 heeft naar zijn eigen L1-cache al een latency van drie kloktikken, dus het zal niet sneller zijn om een andere core te bereiken. Al met al zal er dus een hoop tijd worden verspeeld puur aan communicatie, terwijl de tweede instructie anders gewoon vlak na de eerste had kunnen starten.


Lees meer over



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True