Results 1 to 6 of 6

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

  1. #1
    Join Date
    Jan 2007
    Posts
    13,469

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

    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

  2. #2
    Join Date
    Jan 2011
    Posts
    446

    Default

    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.

  3. #3
    Join Date
    Sep 2010
    Posts
    421

    Default

    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.

  4. #4
    Join Date
    Nov 2009
    Location
    Madrid, Spain
    Posts
    394

    Default

    Quote Originally Posted by plonoma View Post
    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).

  5. #5
    Join Date
    Oct 2008
    Posts
    2,913

    Default

    Quote Originally Posted by ciplogic View Post
    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.

  6. #6
    Join Date
    Nov 2009
    Location
    Madrid, Spain
    Posts
    394

    Default

    Quote Originally Posted by smitty3268 View Post
    .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/201...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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •