Hoofdcategorieën

Intel werkt aan energiebewuste pipelines

Door Wouter Tinus, dinsdag 9 november 2004 20:22
Bron: Intel, submitter: FFWD, views: 8.087

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:

PARROT 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.

PARROT pipeline

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.

Volgende 20:27
Vorige 17:12

Reacties

«  1  2  »

Cool dit is bericht 35000
maar verder sinds waneer zijn meer pipe lines ziuiniger?
edit:
verkeerd gelezen de piplines zijn perstuk zuiniger

Intel werkt aan energiebewuste pipelines
Met een kraantje eraan :+

anders wordt de (water) rekening te hoog!
de spaar pipline!

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

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.)

Wat klopt er niet dan?

Sorry, maar bron ???

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

Komt dit ook de snelheid onder dos ten goede? :P

En dat is boeiend omdat...?

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

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.

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.

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

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 ?.

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?

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.

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.

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.

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).

<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'

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

Wel mooi dat Intel ook een beetje aan het milieu denkt! :)
«  1  2  »

Op dit item kan niet meer gereageerd worden.

Volgende 20:27
Vorige 17:12
VNU Media logo Powered by True

© 1998 - 2008 Tweakers.net - Alle rechten voorbehouden

Uitgever van: