[C#] .Net waarom is IL code soms sneller dan native?

[Laurens-R]

Hallo allemaal,

Ik zit de laatste tijd me iets af te vragen met betrekking tot .net vs native performance.

In het boek Code Complete 2 word het nog eens duidelijk weergegeven in het hoofdstuk over code tuning. Het valt me namelijk op dat C# code (MSIL dus) vaak veel sneller uitgevoerd word dan exact dezelfde routine in native C++. Hoe kan dat?

Je zou toch zeggen dat MSIL trager zou zijn omdat het van MSIL nog eens een keer naar native vertaald moet worden? Wat ook opvalt is dat het vaak ook echt enorme performance verschillen zijn. Tot soms 60% sneller dan de native variant! (Als ik het boek mag geloven).

[MSalters]

Omdat je een in C# geoptimaliseerde routine vergelijkt met "exact" dezelfde routine in C++ ? Die is dan niet meer optimaal voor C++. Voor een juiste vergelijking moet je C# code vergelijken met C++ code die hetzelfde resultaat oplevert.

[FTL]

Veel kost vaak een fractie(of verwaarloosbaar) meer tijd in managed talen (zoals c# en java) op een uitzondering na: het alloceren van nieuw geheugen (nieuwe classe instanties aanmaken e.d.).

Managed talen gebruiken een garbage collector om geheugen schoon te poetsen en houden een 'pointer' bij naar de vrij geheugen ruimte (allocation pointer).

Omdat niet gebruikte ruimte niet direct wordt opgeruimd door de GC (dit opruimen is traag) kan hij heel 'goedkoop' nieuw geheugen alloceren. (Zodra geheugen vol zit zal de GC moeten opruimen, dit kost weer veel tijd).

Native (non-managed talen) alloceren in het eerste de beste vrije blok dat groot genoeg is. Dit zoeken naar vrij geheugen is 'duur'.

Meer info (en meer detail die ik achterwege heb gelaten) staat op
http://msdn2.microsoft.com/en-us/library/ms973837

[ Voor 6% gewijzigd door FTL op 06-02-2008 20:43 ]

[Laurens-R]

thnx! De link naar MSDN maakte het een stukje duidelijker

[EfBe]

tight loops zijn geen graadmeter. het punt is dat de CLR JIT at runtime meer informatie heeft dan de C++ compiler at compile time: hij weet bv dat bepaalde code niet gerunned wordt, of bepaalde variabelen niet gewijzigd worden, en die kun je dus wel/niet in de registers van de CPU laden, hij kan loops unrollen waar nodig etc. op basis van executie informatie at runtime.

Zodoende kan een tight loop sneller lopen op de CLR dan native C++ code dat lijkt te doen.

Maar maak je geen illusies: een grotere routine of een geheel programma is nog altijd een paar klappen trager dan in native C++. Dit komt omdat de JIT wel degelijk tijd kost en de JIT na een korte periode gewoon niet verder optimaliseert of bepaalde routines in zn geheel niet optimaliseert omdat ze te groot zijn en ze daardoor teveel tijd zouden kosten.

Waar veel van verrwacht wordt de komende jaren is graph transformations op de IL code: het programma wordt dan als een call graph gezien en door slimme transformaties kun je die code dan veel sneller maken, dit at compile time.

Ook het bijhouden van runtime statistics, iets waar Sun in Java gebruik van maakt, kan bijdragen tot een hogere performance. (De Java JVM bv gaat na een tijdje de statistics van de hotspots gebruiken om de al ge-jitte code opnieuw te vertalen naar native code). Ik heb echter het vermoeden dat een patent Microsoft in de weg zit op dat gebied, anders hadden ze dat wel ingebouwd in de CLR.

[.oisyn]

EfBe schreef op woensdag 06 februari 2008 @ 21:11:
tight loops zijn geen graadmeter. het punt is dat de CLR JIT at runtime meer informatie heeft dan de C++ compiler at compile time: hij weet bv dat bepaalde code niet gerunned wordt, of bepaalde variabelen niet gewijzigd worden, en die kun je dus wel/niet in de registers van de CPU laden, hij kan loops unrollen waar nodig etc. op basis van executie informatie at runtime.

Zodoende kan een tight loop sneller lopen op de CLR dan native C++ code dat lijkt te doen.

Wat met C++ ook kan als er gebruik wordt gemaakt van link time code generation en profile guided optimizations (hoewel dat laatste natuurlijk statisch is en je guide runs een goede weergave moeten zijn van het gemiddelde gebruik van je applicatie - bij ongemiddeld gebruik kan een JITer voordeel geven).

Overigens is het natuurlijk niet inherent aan C++ dat het naar machinetaal gecompileerd wordt, je zou ook best een C++ JITer kunnen maken.