4 ms·

C# doesn't "execute on a VM layer". It's compiled to native code before execution, in a process known as JIT. http://www.telerik.com/blogs/understanding-net-ju

by jaked89 11y ago

C# doesn't "execute on a VM layer". It's compiled to native code before execution, in a process known as JIT. http://www.telerik.com/blogs/understanding-net-just-in-time-compilation http://www.telerik.com/blogs/understanding-net-just-in-time-...

srean 11y ago
Given the scarcity of non-scripting language VMs that do not use JIT, this is what I mean by VM layer nowadays. There is whole lotta difference between execution of a "AOT compiled to machine code, potentially profile guided if need be" program and a "selectively compiled under severe time pressure that precludes deep compiler optimizations" one, much that JIT camp would like to brush under. There is still a substantial gap between the pregnant promise of a JIT and its delivered performance. The gap that needs to be bridge does gets narrower by the year though. [Mono does have AOT compilation, but I had given up on a then buggy Mono and haven't found enough motivation to go back. Should I ? A non bugged F# on Linux would be really sweet.] Under circumstances JIT can, and do outperform, but those are not nearly the common enough cases and configurations, at least not in the number crunching world. And some of the scenarios that get held up in JIT's defense are plain hypothetical, 'for arguments sake only'. C# is much better than Java about interoperating across the managed - non-managed bridge, D is significantly better still. The poverty of the C# eco-system in number crunching libraries, or even production quality glues to native number crunching libraries, is really stark. I guess it was never an area they wanted C# to venture in. For example their standard math library does not work on float32. WTF! The first time I realized this, I couldn't believe it. By the way the author of the article you linked has this to say: JIT can generate faster code, because it targets the current platform of execution. AOT compilation must target the lowest common denominator among all possible execution platforms. This points to another bridge that needs crossing (the one between the AOT and JIT communities). Had there been a garbage collector for the web, that should have been history by now. Command line options for compilers have been a thing for quite a while.
- breischl 11y ago
  Actually you can AOT compile C# down to machine code. I haven't tried it, but they've been pushing it pretty heavily for a while now. https://msdn.microsoft.com/en-us/vstudio/dotnetnative.aspx https://msdn.microsoft.com/en-us/vstudio/dotnetnative.aspx
ygra 11y ago
Technically it's an ahead-of-time compiler, unlike Java's Hotspot which actually does just-in-time compilation.

by jaked89 11y ago

srean 11y ago

Given the scarcity of non-scripting language VMs that do not use JIT, this is what I mean by VM layer nowadays. There is whole lotta difference between execution of a "AOT compiled to machine code, potentially profile guided if need be" program and a "selectively compiled under severe time pressure that precludes deep compiler optimizations" one, much that JIT camp would like to brush under. There is still a substantial gap between the pregnant promise of a JIT and its delivered performance. The gap that needs to be bridge does gets narrower by the year though. [Mono does have AOT compilation, but I had given up on a then buggy Mono and haven't found enough motivation to go back. Should I ? A non bugged F# on Linux would be really sweet.] Under circumstances JIT can, and do outperform, but those are not nearly the common enough cases and configurations, at least not in the number crunching world. And some of the scenarios that get held up in JIT's defense are plain hypothetical, 'for arguments sake only'. C# is much better than Java about interoperating across the managed - non-managed bridge, D is significantly better still. The poverty of the C# eco-system in number crunching libraries, or even production quality glues to native number crunching libraries, is really stark. I guess it was never an area they wanted C# to venture in. For example their standard math library does not work on float32. WTF! The first time I realized this, I couldn't believe it. By the way the author of the article you linked has this to say: JIT can generate faster code, because it targets the current platform of execution. AOT compilation must target the lowest common denominator among all possible execution platforms. This points to another bridge that needs crossing (the one between the AOT and JIT communities). Had there been a garbage collector for the web, that should have been history by now. Command line options for compilers have been a thing for quite a while.

breischl 11y ago
Actually you can AOT compile C# down to machine code. I haven't tried it, but they've been pushing it pretty heavily for a while now. https://msdn.microsoft.com/en-us/vstudio/dotnetnative.aspx https://msdn.microsoft.com/en-us/vstudio/dotnetnative.aspx

ygra 11y ago

Technically it's an ahead-of-time compiler, unlike Java's Hotspot which actually does just-in-time compilation.