CodeRefactor: Turning Microsoft's MSIL/CIL Into C++

[phoronix]

Phoronix: CodeRefactor: Turning Microsoft's MSIL/CIL Into C++

CodeRefactor is an open-source project aiming to take Microsoft CIL/MSIL bytecode and convert it into C++ for a native experience...

http://www.phoronix.com/vr.php?view=MTU5ODY

[e8hffff]

If you could intercept the true assembly code, then make an asm2cpp tool, would do the most of the job. You could even use the three levels for analysis for improving code generation.

[plonoma]

Don't forget that using CIL/MSIL instead of C++ or other is that the distributable thing is somewhat processor instructions et independent. Apps written in .NET can run on x86, x64 and arm. And as long as there is a .NET virtual machine, other processors.

[ciplogic]

Don't forget that using CIL/MSIL instead of C++ or other is that the distributable thing is somewhat processor instructions et independent. Apps written in .NET can run on x86, x64 and arm. And as long as there is a .NET virtual machine, other processors.

Hi, the programmer here.

Yes, distribution is independent but the performance is not. Especially on low end hardware.

If you can get a faster binary locally why not have it!? Also, on lower end hardware Jit-ting is slow somewhat, so you can have good startup + good performance without caring about VMs.

At last, but not at least, for me the reason to start this project is that the CR output is portable C++ 11 (excluding some dll/library loading mapping, which has to be platform dependent, there is no way to workaround it) so it can be used as code on all platforms without using that particular VM that may not be supported on that platform (for example Mono does not exist with a low cost on Android, when a C++ compiler does).

[smitty3268]

Hi, the programmer here.

Yes, distribution is independent but the performance is not. Especially on low end hardware.

If you can get a faster binary locally why not have it!? Also, on lower end hardware Jit-ting is slow somewhat, so you can have good startup + good performance without caring about VMs.

At last, but not at least, for me the reason to start this project is that the CR output is portable C++ 11 (excluding some dll/library loading mapping, which has to be platform dependent, there is no way to workaround it) so it can be used as code on all platforms without using that particular VM that may not be supported on that platform (for example Mono does not exist with a low cost on Android, when a C++ compiler does).

.NET already comes with a tool to AOT-compile the MSIL down to binary native code on a machine. So i'm a little skeptical of any claims this would boost performance, at least without some tests to back it up. Does Mono not provide it, and is that why you're working on this?

But i suppose it sounds like an interesting enough project to work on, and if you can improve portability somehow that's always good.

[ciplogic]

.NET already comes with a tool to AOT-compile the MSIL down to binary native code on a machine. So i'm a little skeptical of any claims this would boost performance, at least without some tests to back it up. Does Mono not provide it, and is that why you're working on this?

But i suppose it sounds like an interesting enough project to work on, and if you can improve portability somehow that's always good.

NGen and Mono --aot are a bit slower than JIT code. Is it by design (because functions of NGen images work like DLLs), but you're right they are not slow by much.

This is the NBody benchmark(right now Escape Analysis is implemented, and will make these numbers even better), so yes, it is a bit faster:

http://coderefractor.blogspot.ro/2013/09/nbody-can-c-be-fast.html

The other half of the reason is that both Mono --aot and MS' ngen do still depend on .Net. The final output binaries of CR do not depend on any runtime (excluding C++ runtime, which is included in any OS as for now) at all.