Jump to content
  • Advertisement
Sign in to follow this  
AlexandreMutel

Unity [.net] Faster game with NetAsm, a JIT Native Code Injection Library

This topic is 3794 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi,

I would like to share with the .NET community, the NetAsm opensource project available on codeplex.
NetAsm provides a hook to the .NET JIT compiler and enables to inject your own native code in replacement of the default CLR JIT compilation. With this library, it is possible, at runtime, to inject x86 assembler code in CLR methods with the speed of a pure CLR method call and without the cost of Interop/PInvoke calls. With this library, it is possible for example to inject highly optimized code (using SSE, MMX) inside a method, in replacement of the default generated native code by the JIT compiler.
This library could be particularly useful for game using .NET platform (XNA for example), as it provides a way to integrate fast native code for methods that need highly optimized native code. The current features of NetAsm are:

  • Runs on x86 32bit Microsoft .NET platform with 2.0+ CLR runtime (x64 may be supported in the future
  • Provides three different native code injection techniques: Static, DLL, and Dynamic
    • Static code injection: The native code is stored in an attribute of the method.
    • Dll code injection: this method is similar to the DllImport mechanism but CLR methods are directly bind to the DLL function, without going through the interop layers.
    • Dynamic code injection: you can generate native code dynamically with a callback interface that is called by the JIT when compilation of a method is occurring. It means that you can compile a method "on the fly". You have also access to the IL code of the method being compiled.
  • Supports for debugging static and dynamic code injection.
  • Supports for different calling conventions: StdCall, FastCall, ThisCall, Cdecl. Default calling convention is CLRCall
  • NetAsm can be used inside any .NET language (you can run assembler code inside VB!)
  • Very small library <100Ko.

For additional information and documentation, please visit the NetAsm codeplex site.

Alexandre

Share this post


Link to post
Share on other sites
Advertisement
Odd question, but is there any chance that the approach could be modified to work on the Xbox 360, which runs a version of the .net compact framework and omits the emit instruction, or does the approach rely on something x86 specific? I realize its a very different architecture, but the CPU is fairly well understood and if it were possible it would go a long way towards getting the most out of the 360 (such as the VMX128 units).

I'm not sure if there are other protections in place, in fact, there probably are, but it would definitely be something to look into.

Share this post


Link to post
Share on other sites
Quote:
Original post by Ravyne
Odd question, but is there any chance that the approach could be modified to work on the Xbox 360, which runs a version of the .net compact framework and omits the emit instruction, or does the approach rely on something x86 specific? I realize its a very different architecture, but the CPU is fairly well understood and if it were possible it would go a long way towards getting the most out of the 360 (such as the VMX128 units).

I'm not sure if there are other protections in place, in fact, there probably are, but it would definitely be something to look into.
Well, currently, NetAsm is supporting only x86 32bit .NET platform. NetAsm is not able to run on .NET CF on XBox360, as the Xbox CF doesn't allow the use of mixed library or native library. Although, technically, if the .NET CF on XBox360 was more open, NetAsm should be able to run with few minor changes...

Share this post


Link to post
Share on other sites
Very interesting.
Quote:
Original post by AlexandreMutelDll code injection: this method is similar to the DllImport mechanism but CLR methods are directly bind to the DLL function, without going through the interop layers.

Would it be possible also something like this with delegates? Like calling delegate would directly bind to given address of some native function without interop layers. I'm thinking here about usage of OpenGL extensions and wglGetProcAddress returned function pointer.

Share this post


Link to post
Share on other sites
Quote:
Original post by bubu LV
Would it be possible also something like this with delegates? Like calling delegate would directly bind to given address of some native function without interop layers. I'm thinking here about usage of OpenGL extensions and wglGetProcAddress returned function pointer.

If you think about something similar to Marshal.GetDelegateForFunctionPointer this is currently possible in NetAsm through Dynamic code injection (see TestDynamicCodeInjection.cs in NetAsmDemo sample on how to do dynamic code injection). I could add this delegate features if enough people are interested in (add this request to the Issue Tracker on codeplex).
However, NetAsm should not be considered as a replacement for Interop. There are some issues :
  1. The native code injected is considered as CLR code and not as unmanaged, so there are some restrictions when using external functions that could call OS functions (for example, even if NetAsm could call printf from msvcrt.dll, it prints nothing because the CLR is supposed to be in CLR mode and not unmanaged) : Interop has a different behavior as you leave the CLR runtime to the unmanaged runtime (the VM does a couple of things to insure the transition, thread contexts...etc.).
  2. Also, NetAsm doesn't fully support other calling conventions (StdCall, FastCall, ThisCall, Cdecl). The default supported calling convention is ClrCall - which doesn't do any conversion call between the CLR call and the code injected-

Currently, native code injection should be preferred when using CPU intensive calculation (for small routines for example).

Moreover, if you look at some benchmarks on NetAsm, you will see that when a method is CPU intensive and is running for a medium-time, the cost of calling through Interop is negligible to the cost of the method itself (See Matrix Multiplication sample using SSE2 : in this example, NetAsm is only 10% faster than fast interop - without security checking).

Share this post


Link to post
Share on other sites
This is extremely interesting!

A couple of questions:

Is there any chance that this could work on the Mono JIT? What would it take for that to happen?

How easy is it to add support for different platforms (e.g. x86_64)?

"The native code injected is considered as CLR code and not as unmanaged" - would this restrict calling e.g. OpenGL functions?

I am mainly trying to understand how/if this project could be used to speed up wrappers like Tao or OpenTK.

Keep up the good work!

Share this post


Link to post
Share on other sites
Quote:
Original post by Fiddler
Is there any chance that this could work on the Mono JIT? What would it take for that to happen?

We have to wait... i have just asked this to Miguel de Icaza. It would be nice but i'm not sure it's possible or even it would be made possible by Mono team dev...
Quote:
How easy is it to add support for different platforms (e.g. x86_64)?

I don't have currently any way to test such platform, although the port of NetAsm to x64 shouldn't be hard. If anyone is interested in helping me on this, i would appreciate.
Quote:
"The native code injected is considered as CLR code and not as unmanaged" - would this restrict calling e.g. OpenGL functions?

You have to test it. I'm not sure it's going to work.

Share this post


Link to post
Share on other sites
Quote:
Original post by AlexandreMutel
Quote:
Original post by Fiddler
Is there any chance that this could work on the Mono JIT? What would it take for that to happen?

We have to wait... i have just asked this to Miguel de Icaza. It would be nice but i'm not sure it's possible or even it would be made possible by Mono team dev...

Great! Going from posts on the mono-dev mailing for the debugging and profiler APIs, I suspect that it might be possible, but I'm nowhere proficient enough on the Mono internals to say for sure.

I also don't know how Mono plays with C++/CLI. There was some work on this front recently, but I don't think it's really supported at this point. (By supported I mean running C++/CLI assemblies, not compiling).

Going slightly off-topic now, but Mono takes a smaller hit than .Net when calling unmanaged code (about 6ns overhead versus 12ns for a simple function with one parameter and one return value, measured on x64 mode on a Core 2 @2.66GHz). The capability for dynamic injection through NetAsm is still awesome, though!

Quote:

Quote:
How easy is it to add support for different platforms (e.g. x86_64)?

I don't have currently any way to test such platform, although the port of NetAsm to x64 shouldn't be hard. If anyone is interested in helping me on this, i would appreciate.

If you point me to the correct direction, I could help with this. Is this as simple as adding a new calling to the CallingConventionHelper.h? How would the JIT hooks need to change?

Quote:
Quote:
"The native code injected is considered as CLR code and not as unmanaged" - would this restrict calling e.g. OpenGL functions?

You have to test it. I'm not sure it's going to work.
[/quote]
Fair enough :D I'll write a simple test to check this out.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!