Intel werkt aan energiebewuste pipelines

Intel werkt aan een techniek om de prestaties van zijn toekomstige processors te verbeteren zonder daarbij meer warmte te genereren of een hogere kloksnelheid nodig te hebben. Het idee bouwt verder op het in de Pentium 4 geïntroduceerde trace cache, maar in plaats van de letterlijk naar microcode vertaalde instructies op te slaan en er verder niets mee te doen zal de processor deze actief gaan optimaliseren voor betere efficiëntie. Het concept is PARROT gedoopt: Power-Aware aRchitecture Running Optimized Traces. Tijdens het draaien van het programma houdt de processor bij welke code het meest gebruikt wordt. Hoe vaker bepaalde delen van het programma langskomen, hoe agressiever deze stukken herschreven worden om een maximaal resultaat te bereiken. Het volgende plaatje toont een boom van onderling afhankelijke instructies voor en na optimalisatie:

De reden dat niet alle code die aan de chip gevoerd wordt op dezelfde manier kan worden geoptimaliseerd is dat het vele honderen clockcycles kost om te doen, en het dus alleen echt nut heeft voor instructies die vaak genoeg gebruikt worden om de tijd die het kost om te optimaliseren terug te winnen. Ook kan het niet door een compiler gedaan worden, omdat deze van te voren niet kan voorspellen welke code veel gebruikt zal worden of op welke processor deze zal draaien. PARROT werkt nog een stap lager dan assembly en is dus echt een hardwarefeature.

Om deze technologie te implementeren wordt gebruikgemaakt van twee deels losgekoppelde pipelines. Deze zouden in theorie nog wel dezelfde rekeneenheden kunnen gebruiken, maar de manier waarop ze instructies gevoerd krijgen zal in ieder geval volledig anders zijn. De één voert "cold" instructies rechtstreeks uit het L1-cache uit, en is verantwoordelijk voor het herkennen van veel voorkomende patronen. Zodra een stuk programma eenmaal het stempel "hot" krijgt, wordt de gedecodeerde versie van deze instructies opgeslagen in het trace cache, waar de tweede pipeline zijn instructies vandaan haalt. Deze pipeline bevat tevens de optimizer en trace predictor om het maximale effect te bereiken.

Intel heeft verschillende simulaties gedraaid van theoretische processors met verschillende vormen van PARROT aan boord, die onderworpen werden aan bekende benchmarks zoals SPEC CPU en SysMark 2000. Hieruit is gebleken dat het gemiddeld aantal instructies dat per clockcycle wordt uitgevoerd dankzij de technologie stijgt met 17%, terwijl er maar 4% meer stroom wordt verbruikt. Wel neemt het aantal transistors in de core naar schatting met 30 tot 40% toe. Om een soortgelijke verhoging van IPC op de normale manier te verkrijgen zou het aantal transistors echter verdubbelen en het stroomverbruik maar liefst 70% omhoog gaan.

Of Intel PARROT daadwerkelijk gaat implementeren - en zo ja wanneer - is op dit moment nog onduidelijk. Er zijn echter vage aanwijzingen dat voor eind 2006 of begin 2007 geplande Merom-core voorzien zou kunnen zijn van de techniek. Dit is echter puur gebaseerd op het feit dat de processor die Intel beschrijft in zijn simulatie vier in plaats van de voor Pentium 4 gebruikelijke drie instructies per klokcycle kan overhandigen aan de pipeline. Dit geldt volgens eerdere geruchten ook voor Merom en zijn desktopbroeder Conroe.

Reacties (37)

[Steeph]

Code optimaliseren kan wel door een compiler, maar dan een runtime compiler.

Zie bijvoorbeeld:
http://arstechnica.com/reviews/1q00/dynamo/dynamo-1.html
en
http://arstechnica.com/cpu/2q00/x86future/isa-future-1.html
voor interessante lectuur

[WinL]

Neem nu de .NET JIT compiler van Microsoft. Dat is een super goed voorbeeld bij dit onderwerp. Hij optimaliseert de code zodanig dat hij lekker loopt op het betreffende systeem, mits natuurlijk de compiler de hardware herkent. En dat loopt echt heel gladjes. Het nadeel van JIT is het iets tragere opstarten van software.

[mdvmine]

Dat is toch wat anders denk ik. De JIT weet meer van je computer af, welke processor type je hebt bijvoorbeeld, daarom is dat beter dan een algemene build (bv. voor 386).

Wat intel hier doet, is on the fly tijdens executie bepaalde codepaden analyseren en optimaliseren! Dat kan je je met een VM niet veroorloven, zou veel te veel tijd kosten.

[Verwijderd]

Juist een VM kan goed bepalen welke stukken code wel en niet moeten worden uitgevoerd! Door de kennis van de toestand van het programma op runtime, kunnen andere beslissingen worden genomen over executie dan op compiletime, waar je niet de kennis heb over run time states.

Deze ontwikkeling zorgt ervoor dat in de toekomst JIT + VM sneller kan zijn (in bepaaled taken uiteraard) dan conventioneel compileren en runnen

[martijnvanegdom]

<qoute>
Ik snap alleen niet waarom dit per se een hardware feature moet zijn. Je zou toch de software gewoon beter kunnen compileren voor p4's of amd's?
</qoute>

Het voordeel van dit in de hardware doen is dat het sneller is.. En dat je niet nieuwe compilers moet bouwen. Want een compilerbouwen die echt goed is en optimale code is 'one hell of a job'

[Verwijderd]

Nee, het aanpassen van deze architectuur doen ze in hun vrije tijd.

Wel mooi dat Intel ook een beetje aan het milieu denkt!

[Da_DvD]

Hieruit is gebleken dat het gemiddeld aantal instructies dat per clockcycle wordt uitgevoerd dankzij de technologie stijgt met 17%, terwijl er maar 4% meer stroom wordt verbruikt. Wel neemt het aantal transistors in de core naar schatting met 30 tot 40% toe. Om een soortgelijke verhoging van IPC op de normale manier te verkrijgen zou het aantal transistors echter verdubbelen en het stroomverbruik maar liefst 70% omhoog gaan

Dit lijkt me niet echt geloofwaardig. Een extra FP unit neemt niet zo veel ruimte in en kan de FP performance flink verhogen. iig meer dan 17%

En wat is een IPC verhoging 'op de normale manier'?? Alsof simpelweg transistors toevoegen de IPC verhoogd? Ik ga de bron maar eens even lezen geloof ik...

[Wouter Tinus]

Dit lijkt me niet echt geloofwaardig. Een extra FP unit neemt niet zo veel ruimte in en kan de FP performance flink verhogen. iig meer dan 17%

In theorie kan dat misschien wel, maar in de praktijk werkt het natuurlijk niet zo makkelijk. Het is extreem moeilijk om ILP (parallellisme op instructieniveau) te extraheren uit een x86-programma. Gemiddeld kunnen er minder dan twee instructies (1,2 of 1,3 geloof ik) tegelijk uitgevoerd worden vanwege onderlinge afhankelijkheden, en dat is dus ongeacht het aantal rekeneenheden dat de processor beschikbaar heeft. PARROT zoekt dat parallellisme op het niveau van de microcode, en dat is een tot nu toe grotendeels onbenutte mogelijkheid van optimalisatie. Extra voordeel is dat het voor alle code werkt en niet alleen voor speciaal gecompileerde software.

En wat is een IPC verhoging 'op de normale manier'?? Alsof simpelweg transistors toevoegen de IPC verhoogd?

Staat er dat dan? Neen. Het gaat daar om het verbreden van de processor van 4-issue naar 8-issue. Door meer instructies tegelijk te decoderen is de kans groter dat er instructies worden gevonden die tegelijk uitgevoerd kunnen worden omdat ze niet onderling afhankelijk zijn, en daardoor gaat de IPC / ILP dus omhoog. De decoder is echter een heel groot en complex onderdeel voor een x86-processor, en zo'n verbreding levert dus een hele grote en hete core op.

[Hielko]

In theorie kan dat misschien wel, maar in de praktijk werkt het natuurlijk niet zo makkelijk. Het is extreem moeilijk om ILP (parallellisme op instructieniveau) te extraheren uit een x86-programma.

Je hoeft ook niet perse je parallellisme op instructieniveau te gaan verhogen voor een hogere aantal instructies per clock uit te gaan voeren. De opkomst van multicore processors lijkt me daar het voorbeeld van. Maar als je strict kijkt naar single-core processors heb je gelijk dat het verhogen van parallelisme erg moeilijk is. De Itanium is denk ik wel het voorbeeld dat laat zien hoe moeilijk het is.

[Wouter Tinus]

Je hoeft ook niet perse je parallellisme op instructieniveau te gaan verhogen voor een hogere aantal instructies per clock uit te gaan voeren. De opkomst van multicore processors lijkt me daar het voorbeeld van.

Dat is zo, maar TLP (thread level parallelism) en ILP zijn natuurlijk wel makkelijk te combineren, omdat ze op een heel ander niveau werken. TLP is niet altijd beschikbaar, nuttig of mogelijk, terwijl ILP 'altijd' helpt (en dus ook threaded software nog een extra boost geeft qua IPC).

[Luxx]

Je hoeft ook niet perse je parallellisme op instructieniveau te gaan verhogen voor een hogere aantal instructies per clock uit te gaan voeren. De opkomst van multicore processors lijkt me daar het voorbeeld van.

Maar een multicore processor levert je globaal gewoon 2x zo veel transistoren op... iit het verhaal van een extra execution unit toevoegen, dat eerder werd gesuggereerd. Daarnaast levert het je in een singel thread applicatie geen winst op.

Maar als je strict kijkt naar single-core processors heb je gelijk dat het verhogen van parallelisme erg moeilijk is. De Itanium is denk ik wel het voorbeeld dat laat zien hoe moeilijk het is.

De Itanium gebruik een totaal andere instructieset, een totaal andere architectuur, en daarmee lijkt het nu redelijk te lukken (de aankomen Itaniums lijken behoorlijk goed te presteren).

[Verwijderd]

De gemiddelde ILP van de meeste programma's is beduidend hoger dan 1,2. Getallen zoals 12 zijn echt geen uitzondering. Wat jij noemt is de IPC van de huidige generatie processoren. Een processor met twaalf uitvoeringseenheden van elk type, en onbeperkt vooruit lopen in het programma zou theoretisch tot een IPC van 12 kunnen geraken. Dit is echter practisch onmogelijk door de zeer grote toename in complexiteit als de pijplijnen breder worden gemaakt. Ook speelt het geheugen en sprongvoorspelling een limiterende rol.

Met het programma SimpleScalar kan je zelf eenvoudig een processorarchitectuur configureren. En daar kunnen indrukwekkende IPC's mee gehaald worden als men de elektronische complexiteit niet meerekent...

[Luxx]

De gemiddelde ILP van de meeste programma's is beduidend hoger dan 1,2. Getallen zoals 12 zijn echt geen uitzondering.

De K8 heeft maar 9 execution units, de prescott zelfs maar 7. Hier zitten nog verschillende in, voor verschillende type instcutie, het komt dus alleen in heeeeel bijzondere gevallen voor dat deze allemaal gebruikt kunnen worden. Hoe je hier 12 uit wilt halen???

Een processor met twaalf uitvoeringseenheden van elk type, en onbeperkt vooruit lopen in het programma zou theoretisch tot een IPC van 12 kunnen geraken.

12 per type is echt enorm hoog, 3-4 is meer realistisch. Om deze 3 of 4 gevuld te houden, moet je al heel veel "geluk" hebben, net iets meer dan 1, zoals wouter zegt, is overeenkomstig met de praktijk.

[Verwijderd]

Zucht. Ik zei dan ook dat de gemiddelde ILP van een -programma- op 12 of zo kan liggen, niet dat een praktische processor zoveel instructies per clock verwerkt. Wat Wouter zij is dat de IPC maar maximum 1,2 kan worden, onafhankelijk van het aantal rekeneenheden. Er is dus wél nog zeer veel verbetering mogelijk om van die ILP in programma's gebruik te maken, echter in de praktijk wordt dat zeer moeilijk omdat die onafhankelijke instructies zich ver uiteen kunnen bevinden en het geheugen en sprongvoorspelling ook niet ideaal zijn.

[Wouter Tinus]

Zucht. Ik zei dan ook dat de gemiddelde ILP van een -programma- op 12 of zo kan liggen, niet dat een praktische processor zoveel instructies per clock verwerkt. Wat Wouter zij is dat de IPC maar maximum 1,2 kan worden, onafhankelijk van het aantal rekeneenheden.

Nee, dat zei ik niet, ik had het over een gemiddelde, en daaruit volgt automatisch dat er hogere waardes mogelijk zijn (sowieso zou 2 mogelijk moeten zijn om ooit op 1,3 uit te komen). Verder zei ik dat het gemiddelde niet (merkbaar) hoger wordt door botweg meer executie-eenheden toe te voegen, niet dat dat er geen enkele manier is om dat gemiddelde omhoog te krijgen. Dit hele artikel gaat over zo'n manier, dus dat zou ook stom zijn om te zeggen .

[Verwijderd]

Lachen zeg, bijna een (co)processor in de proc. Maar is dit niet verkeerd om redeneren ? Kunnen ze niet beter aan de software-matige kant andere afspraken maken ? Als ze het allemaal compatibel willen houden een soort primary-code afspraken aan compilers toevoegen ?.

[Verwijderd]

De Pentium M maakt reeds gebruik van technieken om sommige instructies samen te nemen in complexere micro-instructies (ironie...) en in één klockcyclus uit te voeren.

Deze ver doorgedreven vorm daarvan lijkt me echter niet zo nuttig. De kost aan transistoren is gigantisch ten opzichte van de snelheidswinst. Intel's tactiek van telkens het ontwerp complexer te maken werpt niet altijd de beloofde vruchten af. Dit bericht lijkt dan ook eerder enkel vanuit de marketing te komen, om Intel's maandenlange achterstand te doen vergeten.

In de verre toekomst zie ik een betere samenwerking tussen de hardware en de software als zeer belangrijk voor verdere prestatiewinst. Men kan gemakkelijk tien Pentium 3 processorkernen op 90 nm technologie zetten. Indien programmeurs leren om hun software van in het begin te ontwerpen voor geavanceerde multi-threading spreken we niet meer over 17% snelheidswinst maar tot dicht bij 1000%!

Een radicaal andere aanpak, zoals we zien bij het programmeren van de grafische chip...

[lvh]

Heb je onderbouwing voor dat getalletje of ben je nummertjes uit de lucht aan het grijpen?

Er bestaan al langer goeie multithreading applications. Kijk voor de grap eens bij de betere open-source server software. Die zijn meestal enorm goed multithreaded zodanig dat ze ook op SMP goeie snelheden halen.

[Verwijderd]

Kijk even naar het aantal transistoren in de core van een Pentium 3 en van een Prescott. En dat is bij bijna gelijk gebleven functionaliteit.

Server software is inderdaad meestal goed multi-threaded. Het probleem ligt bij de 'eenpersoons' software. Maar ook daar is er een groot potentieel om vele threads te gebruiken. De programmeurs zijn momenteel echter gewoon dat alle code linear uitvoert. Spelprogrammeurs zijn bereid om de software op te splitsen in vele threads, maar momenteel heeft dat nog maar weinig zin. Vanaf dual-core processoren op de markt verschijnen gaat dat sterk veranderen...

[Verwijderd]

er i maar 1 echte pipeline in een procesor, het zijn geen video chips, mensen....

[Verwijderd]

Ook bij processoren kan onderscheid tussen verschillende pipelines worden gemaakt, bijvoorbeeld tussen de integer- en de floating point pipeline. Wel zijn de pipelines veel meer met elkaar vervlochten. Zeker in de eerste fase waar het initialiseren van de uit te voeren instructie plaats vindt. (Misschien is het beter te praten over 'sub-pipelines' die van elkaar onderscheiden worden.)

[Glashelder]

Wat klopt er niet dan?

[familyman]

Dit herken ik toch ook al van andere processoren? Was zo'n alpha risc processor, meen ik.

Ik snap alleen niet waarom dit per se een hardware feature moet zijn. Je zou toch de software gewoon beter kunnen compileren voor p4's of amd's?

[Atmosphere]

Ik denk dat jij net als mij ook aan die code-morphing software van transmeta denkt die X86 naar VLIW vertaald. Hierbij worden ook de meest gebruikte functie's opgeslagen als deze vaker voorkomen. Hierdoor hoeft er niet opnieuw een vertaling plaats te vinden en kan hij de instructie in 1 keer afhandelen.

[GaboonViper]

Is het niet de verantwoordelijkheid van de programmeur om zijn programma code zo goed mogelijk te optimaliseren? Als alle programma's nou wat beter geoptimaliseerd worden dan hebben we ook geen gigaherzen nodig alleen om bijvoorbeeld MS Word te draaien.

[Mantaray]

Ja, in een ideale wereld zou de programmeur zijn software zo optimaal mogelijk inelkaar draaien.

Heb zelf eens gewerkt bij een software huis waar we zeer grote catalogi + databases + informatie en bestel software op 1 tot 2 diskettes persten. Door deze ervaringen zoek ik zelf altijd de snelste manier voor code, maar ik zie tegenwoordig mede programmeurs er nog geeneens over nadenken. Funktieblok op functieblok, object op object stapelend...

Helaas zullen de meesten niet verder kijken dan hun eigen systeem aankan. Tot grote vreugde van hardware producenten.

[WinL]

Ik snap wat je bedoelt.
Het is altijd een kwestie van overwegen. Gebruik je wat meer functies en classen/objecten dan zal je ongetwijfeld ook wat meer overhead hebben in bepaalde software.
Maar OOP is voor een programmeur wel wat aantrekkelijker, zorgt er tevens ook voor dat de code wat beter leesbaar is. Het gevolg van dit alles is dan ook stabielere en betere, uitebreiddere code/software.
Het is maar waar je voor kiest.
Met ASM kom je super ver, als je het goed kent is het zelfs nog een hel, ik bedoel maar (een hel dus buggy code).

[mtak]

En wie zegt dat electronica niet intelligent kan worden? Jeremiah is mss niet intelligent, maar lijkt het wel, en dit lijkt er toch ook weer op.

[loekf2]

Sorry, maar bron ???

[GaMeOvEr]

Intel? Zoals bovenaan het nieuwsbericht, gelijk onder de kop staat?