Toekomstige Intel-processors gaan Java en .NET versnellen

Intels volgende generatie van processors bevat een techniek om het uitvoeren van managed software zoals Java en .NET te versnellen, zo schrijft The Inquirer. Deze Rockton Technology is een combinatie van een nieuwe uitbreiding op de x86-instructieset en aanpassingen aan de runtime omgeving van de respectievelijke talen. Programmeerplatforms als Java en .NET werken met extra laag tussen de broncode en rauwe machinetaal om applicaties te krijgen die geschikt zijn voor meerdere platformen. Pas op het moment dat een programma (voor het eerst) opstart wordt de vertaalslag gemaakt van de 'tussentaal' naar de instructieset van het systeem waar het op geïnstalleerd is. Omdat dit pas op het laatst mogelijke moment gebeurt wordt het programma dat dit doet een JIT-compiler genoemd; Just-In-Time. Deze compiler is onderdeel van een groter geheel: bij Java is dat de Virtuele Machine (JVM), en bij .NET de Common Language Runtime (CLR). De reden dat beide talen managed worden genoemd is omdat deze runtime omgevingen een hoop extra functionaliteit aan boord hebben om code minder gevoelig te maken voor menselijke fouten. Denk hierbij aan technieken om crashes, buffer overflows en geheugenlekken te voorkomen.

Het idee is nu dat deze runtime platforms heel vaak dezelfde soort bewerkingen uit moeten voeren (namelijk de executie van code in de gaten houden), en dat proces wil Intel dus gaan versnellen door nieuwe instructies in zijn processors te bakken. Programma's zullen deze instructies natuurlijk wel moeten gaan gebruiken om er voordeel van te hebben, maar het feit dat .NET- en Java-software eigenlijk pas vlak voor het opstarten zijn uiteindelijke compilatie ondergaat betekent dat er bijna geen nieuwe software voor nodig is; alleen een runtime die de techniek ondersteunt is al voldoende. Aan de .NET-kant wordt al samengewerkt met Microsoft om dit voorelkaar te krijgen. Over de Java-kant bestaat minder duidelijkheid, maar Apache wordt getipt als organisatie die de techniek in open-sourcevorm gaat implementeren.

Rockton Technology zal voor het eerst worden ingebakken in de Merom-core, die voor de tweede helft van 2006 staat gepland. De techniek zal dus ook in de desktopversie Conroe en serverversie Woodcrest terechtkomen, maar het is nog niet duidelijk of deze ook meteen ingeschakeld wordt. Het is namelijk Intels beleid om nieuwe technieken pas vrij te geven als het 'ecosysteem' (lees: de software) er ook klaar voor is, dus als Microsoft en Apache/Java niet klaar zijn om de nieuwe instructies te gebruiken zal het waarschijnlijk ook uitgeschakeld blijven.

Reacties (37)

[martijnvanegdom]

Ik denk eerder dat ze bepaalde functies die honderderden keren worden uitgevoerd in de JVM (Zoals bv een carbage collector) willen gaan 'inbakken' (oke carbage collector is misschien niet het beste voorbeeld) in de core

[Wouter Tinus]

Ik denk dat de garbage collector juist wel een goed voorbeeld is. Want wat doet dat ding? Het hele geheugen nalopen op zoek naar referenties naar een bepaald object (om te bepalen of het veilig weggegooid kan worden). Dat is een eentonig klusje wat aan de lopende band uitgevoerd moet worden. Ik kan me goed voorstellen dat hulp van de hardware daarbij winst op kan leveren.

[Vaudtje]

Alleen jammer dat de garbage collection niet zo vaak uitgevoerd wordt. In principe vindt het alleen plaats als de VM toch uit zijn neus staat te vreten (dan is versnelling ook niet echt belangrijk) en als er geheugen gealloceerd moet worden, maar het is niet beschikbaar (komt niet zo heel vaak voor als het goed is)
Dingen als de security checks aan de rand van de sandbox lijken me interessanter.
Volgens mij is bij alle programmas wel het geval dat bepaalde code vaker draait dan de rest (soort van 80/20), alleen heb je bij JIT-compiled languages de unieke mogelijkheid om alleen de JVM te optimaliseren met speciale calls, waardoor ineens alle denkbare applicaties in de JVM versneld worden.
Op deze manier hoeft Intel niet te wachten tot alle applicaties in de wereld zo geoptimaliseerd zijn, er hoeven alleen een Java VM en een .NET Runtime gefixt te worden.
/megapost

[Verwijderd]

Ohhhh.. Jakarta Tomcat servers on fire.....

[Verwijderd]

Ik ben toch wel benieuwd naar wat deze nieuwe techniek nu -exact- doet.

Instructies die speciaal VM achtige apps versnellen zijn heel goed denkbaar. Een eigenschap van een JIT is namelijk dat die in feite self-modifying code genereerd. Het wordt mischien niet als zodanig gezien door veel mensen, maar dat neemt nog niet het feit weg dat het zo is.

Veel CPU architecturen kunnen daar moeilijk mee om gaan. Voor gewone applicaties is het dan ook een antieke techniek die uit den boze is om te gebruiken. Het kan zijn dan deze chip iniedergeval instructies bevat (cache directives?) om hier beter mee om te gaan.

In het verleden heeft Sun ook al eens een general purpose cpu op de markt gebracht die de JVM versnelde. Dit werkte door het principe dat je normaal voor een CPU ontwerp tientallen belangrijke applicaties analyseer en de mix van instructies bekijkt (hoeveel % gebruikt een kleine displacement, hoeveel procent een middelgrote, hoevaak wordt een count-down loop toegepast, welke addressing mode is dominant, etc etc..)

Voor een JVM optimized architecture doe je die exact zelfde analyse, alleen beperk je je maar tot 1 applicatie: de JVM. Je hele hardware architectuur basseer je dus op exact die instructies (en combinaties daarvan) die deze ene 'applicatie' zelf gebruikt.

(ben overigens zelf een tijdje in de compiler bouw actief geweest als is dat weer wat langer geleden)

[Verwijderd]

Over de Java-kant bestaat minder duidelijkheid

(Citaat een beetje uit z'n verband gerukt. )

Nu maar hopen dat de optimalisaties voor zowel .NET als Java een goeie uitwerking hebben. Een gebrekkige implementatie wordt al snel niet gebruikt, en als één van de twee gebrekkig blijft, kan dit een behoorlijk voordeel opleveren. Niet erg gezond voor wat marktevenwicht. (Gelukkig hebben we ook nog Open Source helden om de boel een beetje recht te trekken.)

(Aan de andere kant: hoeveel invloed hebben deze optimalisaties op de snelheid van executie? 2%? 5%? 25%?)

(En aan nog weer een andere kant: Hoeveel inspanning vergt het om deze nieuwe instructies binnen .NET of Java te integreren.)

@Pietje Puk:
Ik doelde eigenlijk op aanpassingen binnen de Java VM en het .NET framework en niet op wijzigingen in code die die door de VM of CLR wordt uitgevoerd. Binnen zelf geschreven programma's verwacht ik inderdaad geen wijzigingen.

[Verwijderd]

(En aan nog weer een andere kant: Hoeveel inspanning vergt het om deze nieuwe instructies binnen .NET of Java te integreren.)

Als het goed is weinig tot geen. Dit lijkt iets wat puur door de VM geregeld moet worden. Je java programma zou zonder wijzigingen ervan moeten kunnen profiteren. Wat dat betreft is het ook raar dat apache dit voor Java moet gaan implementeren. Je zou toch meer verwachten dat Sun dat zelf (weliswaar niet als Open Source) zou doen.

Misschien dat je wel je code wat kan optimaliseren door bepaalde zaken anders aan te pakken maar de VM zorgt voor de vertaling van java bytecode naar een specifieke hardwarearchitectuur.

[Verwijderd]

Programmeerplatforms als Java en .NET werken met extra laag tussen de broncode en rauwe machinetaal om applicaties te krijgen die geschikt zijn voor meerdere platformen.

Is er dan een .NET framework voor een ander platform dan Windows???

[Jeroen V]

.NET is een implementatie van de Common Language Infrastructure (CLI) zoals die in ECMA-335 is beschreven. Deze standaard is door Microsoft gemaakt, en is in tegenstelling tot wat de meeste mensen denken Open Source. (dat wil overigens niet zeggen dat het volledige .NET platform Open Source is!) SSCLI draait standaard als op ik dacht MacOS, FreeBSD en Windows.

Projecten als Mono (er zijn er overigens meerdere) hebben de Shared Source CLI (SSCLI) gebruikt als basis en hebben het gedeelte dat Microsoft niet Open Source heeft gemaakt toegevoegd en is de SSCLI geoptimaliseerd.

[Verwijderd]

Nee, het is een open specificatie (afgezien van een aantal essentiele onderdelen die niet vrijgegeven zijn), geen Open Source. Als het Open Source was, had het Mono project niet jaren hoeven werken om het te implementeren, dan hadden ze gewoon de beschikbare code kunnen nemen en uitbreiden.

[dingstje]

Project Mono is een open source implementatie voor Linux, Mac OS X en Windows.

[Superstoned]

tja, mono. maar je hebt gelijk, .NET is voor windows.

typisch, als microsoft iets aanraakt verdwijnen vaak de voordelen... (Java - zou veilig (sandbox) moeten zijn, en overal draaien. tot microsoft zich er mee bemoeide, en windows-specifieke java dingetjes ging maken. Jammer dat Sun haar java beschermde, toen is microsoft .NET maar gaan maken)

[Verwijderd]

Waarom is .Net voor Windows terwijl je net Mono erkent? En hoezo zijn de voordelen van de Java sandbox verdwenen? En waarom is het zo betreurenswaardig dat MS .Net heeft gemaakt?

Wat wil je hier nou eigenlijk zeggen behalve die steek onderwater naar MS?

[SirBlade]

Wat is het voordeel van een JIT-compiler? Het lijkt mij toch logischer om al het zware compileer-werk te doen voordat je de applicatie aan de gebruiker geeft.

[Wouter Tinus]

Het zwaarste compileerwerk wordt ook wel gedaan, van de broncode naar de 'tussentaal' (intermediate language / bytecode). De laatste stap naar machinetaal is minder groot, maar biedt als voordeel dat je hetzelfde programma bijvoorbeeld zowel op x86 als op IA-64 kan draaien, of zowel onder Windows als onder Linux.

[Verwijderd]

Het zwaarste compileerwerk wordt ook wel gedaan, van de broncode naar de 'tussentaal' (intermediate language / bytecode).

Mwoah... of dat het zwaarste is betwijfel ik. Iniedergeval Java naar Java bytecode is redelijk recht toe recht aan. Waar traditionele compilers (bv voor C/C++) veel tijd aan kwijtraken is aan de optimalisatie fase. (optimalisatie an sich komt overigens dikwijls al in meerdere fases van het compile process voor)

De java compiler doet sinds een tijdje -helemaal- niks aan optimalisaties. Alles wordt aan de dynamische runtime compiler overgelaten. De -o opties zitten bijvoorbeeld nog wel in javac, maar zijn een noOp geworden.

[tjerkw]

De vertaalslag van broncode naar bytecode is wel de grootste stap, ik weethet niet zeker maar volgens mij wordt daar wel zeker geoptimaliseerd.

De vertaalslag van bytecode naar de machine instructieset is bijna een 1 op 1 mapping ( meestal een 1 op iets meer mapping).

De reden waarom java iets trager is, is deze vertaalslag die nog meot gebeuren en een boel checks die worden uitgevoerd.

[Verwijderd]

Een JIT compiler compileert alleen de code die op dat moment nodig is. Zo wordt de belasting van het compileren van de tussentaal (Java bytecode / MS Intermediate Language) naar machinetaal verspreid over het gebruik van de applicatie en zullen niet gebruikte classes niet gecompileerd worden, waardoor ook de totale belasting van het systeem minder wordt.

Dat heeft dus niets te maken met optimalisatie naar architectuur, want dat konden de niet-JIT-compilers ook doen. Tijdens de loop van je programma zal je architectuur ook niet veranderen. Tevens heeft het niets te maken met het managed zijn van code, want dat kan een niet-JIT-compiler ook prima.

JIT compilation is een ontwikkeling van na de introductie van Java, dus ook na de introductie van managed talen, waarvan de voordelen die hierboven genoemd zijn wel kloppen. Het is alleen een slimmere manier van een managed taal compileren.

[Verwijderd]

En een leuk weetje is misschien dat je je .NET applicatie ook kunt pre-compilen (als in je oude vertrouwde C++). Je hebt dan geen eventuele opstart-performance problemen, vanwege de JIT en je kunt sterker optimaliseren. Wat dan wegvalt zijn de processorspecifieke optimalisaties die de JIT juist zo interessant maken.

Ik moet er wel bij zeggen dat heb hebben van opstart-performance problemen wel heel uitzonderlijk is, dus ga als je blieft niet je website pre-compilen

[Verwijderd]

En je bent natuurlijk ook je platformonafhankelijkheid kwijt.

Maar opstartproblemen zijn eigenlijk niet relevant. Een applicatie start je meestal maar 1 keer op en laat je daarna uren draaien. (of in het geval van een website: dagen, weken) Dan maakt een winst van een minuut bij het opstarten natuurlijk niet echt uit.

Trouwens je kan ook je java applicatie native compileren wat dezelfde voor- en nadelen oplevert

[Jaco69]

De java compiler compiled de source naar java code, de JIT compiler vertaald stukjes java naar machine code. In plaats van een JIT compiler kan je daar ook een interpreter voor gebruiken maar dat is trager omdat dan de java code telkens opnieuw vertaald word zelfs in loops.
Een niet-JIT compiler om java te runnen bestaat volgens mij niet. (tenzij om eenmalig uit te voeren maar dan run je geen java meer). De JIT compiler doet natuurlijk de optimalisaties naar de archutectuur omdat de java zelf architectuur onafhankelijk is. (of zou moeten zijn)

[hiostu]

Een JIT compiler kan, buiten wat Wouter zegt, ook nog optimalisaties uitvoeren at runtime. Ook voert een JIT ook extra controles uit en voorkomt bv bufferoverflows omdat de code in een managed omgeving draait.

[Verwijderd]

Van nature ben ik geen pessimist, ik hou van .net, maar... Hebben we eindelijk de techniek om programmacode platformonafhankelijk te maken (IL), gaan we dit weer processor afhankelijk maken.

Slim van intel, jammer voor gebruikers met dan "tragere" processoren.

[Matthiasje]

Zeg maar optimalistaties. Uiteraard blijft de standaard JIT-compiler nog gewoon werken, maar als je de nieuwe instructies gebruikt, gewoon net wat sneller.

[Onno]

Hebben we eindelijk de techniek om programmacode platformonafhankelijk te maken (IL), gaan we dit weer processor afhankelijk maken.

Welnee, hoe kom je daar bij? Het enige wat hooguit verandert is dat er een JVM en CLR versie bijkomt voor deze hardware, net zoals je nu ook al versies voor IA32, IA64, AMD64/EM64T, enz. hebt.

[Verwijderd]

En de kans is natuurlijk groot dat andere processor-fabrikanten deze optimalisaties ook gaan inbouwen. (Net zoals met bijvoorbeeld met SSE en AMD64 is gebeurd.)

[Jeroen V]

Ik vind het eigenlijk niet echt een probleem, als de JIT maar wel goed blijft presteren op processoren die geen ondersteuning voor IL hebben.

[_Thanatos_]

Ik betwijfel of deze techniek handig zal zijn voor desktop bakken, maar servers die continu met Java of ASP.NET staan te buffelen, zullen hier ongetwijfeld voordeel van hebben.

Maar dan moet - neem ik aan - de runtime van Java of .NET deze nieuwe instructies wel ondersteunen.

[Verwijderd]

Dat is juist een voordeel van .NET. Als er een nieuwere betere runtime uitkomt hebben meteen alle applicaties er voordeel van, zelfs al zijn ze 2 jaar geleden gecompileerd.

Met C++ heb je toch dat je compileert voor iets wat oud genoeg is om compatibel genoeg te zijn met de rest. Het is nog niet zo lang geleden dat de meeste linux dingen voor de zekerheid met i386 gecompileerd werden, i586 (pentium 1) of i686 (pentium 2) wordt nu het meeste gebruikt. Optimaliseer je met wat MMX/SSE instructies dan worden er meestal verschillende binaries meegeleverd, een voor P2/3, een voor P4 en een voor AMD.

[robin1979]

En waarom zou dat voordeel alleen voor .Net zijn en niet voor Java?

Met 1.5 (of voor de mensen in de marketing: 5.0), zijn er toch ook gigantische snelheidswinsten (oa. door memory management, paralelle garbage collect etc) geboekt.. Ook voor applicaties die met een vorige versie van de runtime zijn gecompileerd...

[_Thanatos_]

Maar wie *garandeert* dan dat .NET 1.1 applicaties op .NET 3.0 (waarin dit wrs pas ondersteund zal worden, if ever) ook echt nog steeds werken?

Want als ik me niet vergis werken 1.1 applicaties al niet eens op 2.0...

[xaveriussmet]

Zouden de toekomstige Apple's (Intel-cpu) dan ook .Net gaan ondersteunen

[Verwijderd]

en dit heeft als meerwaarde?

[TD-er]

kortom, ze willen waarschijnlijk de gecompileerde code cachen, of een soort waarschijnlijkheidstabel opbouwen die de branch-prediction voor die runtime-environment kan optimaliseren.

[AvanCade]

Handig voor Azureus

[Targeter]

Ja, want dat is ook echt een mege app, iets wat echt versneld moet worden
Zeg dan niets.