10 ms·

Mono's New .NET Interpreter

229 points by benaadams 9y ago

yodon 9y ago
It’s just mentioned as an aside in this article, but the work the Mono team is doing on WebAssembly is super exciting. Can’t wait to start messing with it.
- lewurm 9y ago
  check out https://twitter.com/kumpera/status/924007954696646656 https://twitter.com/kumpera/status/924007954696646656 and http://blog.stevensanderson.com/2017/11/05/blazor-on-mono/ http://blog.stevensanderson.com/2017/11/05/blazor-on-mono/
  - yodon 9y ago
    And WebAssembly support merged into Mono master branch last week https://github.com/mono/mono/pull/5924 https://github.com/mono/mono/pull/5924 (not available as a release build, but soon)
- akoeplinger 9y ago
  Great to hear that you're excited by it, we're too :) This blog post has a few more details and examples of the WebAssembly work: http://www.mono-project.com/news/2017/08/09/hello-webassembly/ http://www.mono-project.com/news/2017/08/09/hello-webassembl... Disclaimer: I'm working on Mono for Microsoft/Xamarin (primarily class libraries and tools).
gmaster1440 9y ago
Curious to see how this plays out with Microsoft investing in cross-platform development with .NET Core and .NET Standard. The consequences of having multiple competing cross-platform options are already evident when using tools like intellisense in VS Code where you can (or used to be able to) switch between Mono and .NET Core runtimes and certain libraries were only compatible with one. And then there are build tools like Paket which currently only support Mono even though Paket itself can provision .NET Core runtimes.
- maxxxxx 9y ago
  I agree that having mono and .NET Core being developed at the same time is not a good thing. How do you pick one over the other? There is way too much overlap. With .NET core being open source they should find a way to work with the mono team.
  - cptskippy 9y ago
    Isn't .NET Core a Subset of Mono? I though Mono was like a cross platform version of the .NET Framework, of which .NET Core is also a subset.
    - debacle 9y ago
      .NET Core is incompatible with the .NET Framework which Mono is the oss counterpart to.
      - memsom 9y ago
        I think it depends on what you are trying to achieve. They are all slightly incompatible to some degree. I've written quire a few libs in .Net Standard and had them work on all three platforms, as well as writing Core command line apps and ported them to .Net 4.5. The issue is more with stuff like ASP.Net Core etc, where the libraries are slightly different conceptually.
      - cptskippy 9y ago
        That's the official line but I honestly don't know anymore. We were trying to write a few cross platform libraries that we could also consume in Framework. We could not get .NET Standard libraries to import into Framework Apps without entering a dependency hell that made me long for the DLL Hell of the 90s. We discovered that re-targeting .NET Standard projects to .NET Core would allow them to be imported into .NET Framework projects without issue. Of course you can't import .NET Core libraries into .NET Standard so in the end we actually made projects for each of them with links back to the .NET Standard libraries' files.
    - 9y ago
alkonaut 9y ago
What is the main attraction of a proper interpreter vs. the with the compiler built into the platform (so static, but at runtime) that we have with Roslyn? I do some in-app scripting etc and I basically just compile/run code at runtime using Roslyn then. Performance is probably a benefit of doing that, but what is the drawback? is it more overhead e.g. in an interactive setting it might not be responsive for a REPL?
- chrisseaton 9y ago
  Roslyn is entirely unrelated. That's the compiler to CLIR. We're talking about the runtime interpreter and compiler to native code.
  - alkonaut 9y ago
    Yes? My question was "whats the benefit of an interpreter for runtime code exec, over using a compiler-as-a-service like Roslyn"
    - chrisseaton 9y ago
      You've asked what is the benefit of using apples over oranges. The two things are unrelated. When you use Roslyn you still need either a JIT or an interpreter to execute the output of Roslyn. You can't ask what is the benefit of using the interpreter over using Roslyn as you cannot do that. They don't fit into the same place in the system. They don't do the same job. They aren't alternatives. It's a nonsense question.
      - alkonaut 9y ago
        This is a somewhat better answer :) The reason I'm asking was because the interpreter was framed as a solution to in-app code execution (e.g like Lua in many game engines) - but this type of scripting is exactly what I use Roslyn for. So if I can rephrase it: what is the benefit of interpreted scripts vs dynamic compilation of scripts in the context of , for example, app scripting? Specifically in .NET apps. Not e.g. a C++ app (there it's obvious as a replacement for e.g Lua) > When you use Roslyn you still need either a JIT or an interpreter Yes: Assume I'm already in a .NET appxontext so yes I have the JIT available. Does that make the interpreter less attractive as I can just load compiled code there? I'm guessing then the benefit might be less initial overhead, but at the expense of slower execution?
peoplewindow 9y ago
It's interesting how .NET is converging on the same runtime techniques used in Java and yet how drastically far behind they are. The Java guys realised that an interpreter was still useful decades ago. Tiered compilation shipped in Java 8, and that was more complex to implement as there were two JITs, so JITd code still had to do profiling. It's also quite interesting that the interpreter was dropped due to the complexity introduced by having generics in the runtime. A long time ago I thought it was self evident that type erasure was a poor way to do generics, but Brian Goetz has been arguing persistently for years now that type erasure isn't necessarily a bug, just a different tradeoff. With runtime complexity being one of the factors that weighed into the decision ... something that's easier to understand now I read this blog post. There are some things I like about .NET though it was a long time since I did any, but HotSpot seems so dramatically far ahead and the distance is increasing. The major selling point of .NET over Java originally was supposed to be great multi-language support (well, and better Windows support), but there are way more languages targeting the JVM than the CLR these days. HotSpot does tiered compilation, it now does AOT compilation too, it has a new JIT called Graal that either matches or completely smokes the best available runtimes for almost every language, and IntelliJ is every bit the match for Visual Studio. And it's all cross platform. So what's .NET's major selling point these days?
- jackmott 9y ago
  >but HotSpot seems so dramatically far ahead and the distance is increasing. Benchmarkgame scores reached basically parity between java and C# once .net core 2.0 dropped .NET selling points: * you can do some SIMD explicitly, more is coming * you have control over when things are stack allocated or not. structs, stackalloc, slices * you have unsigned ints
  - peoplewindow 9y ago
    Hm, seems like the big win for C# was actually someone going in and optimising the benchmark programs themselves: http://anthonylloyd.github.io/blog/2017/08/15/dotnetcore-performance http://anthonylloyd.github.io/blog/2017/08/15/dotnetcore-per... The point of explicit control is usually performance though. So if Java can give you near equal or better performance but without the developer having to explicitly specify as much, isn't that a win? Benchmark game also lacks the benchmark the Mono blog post is all about - developer iteration time.
Annatar 9y ago
For example, some game developers like to adjust and tweak their game code, without having to trigger a full recompilation. The static compilation makes this scenario impractical, so they resort to embedding a scripting language into their game code to quickly iterate and tune their projects. There is a programming language where every new expression causes incremental compilation and linking inherently, natively: it’s called Lisp.
FrgmntnFatigue 9y ago
What is the rationale for keeping working on mono rather than just port its unique libraries (gtk# etc.) to coreclr ?

229 points by benaadams 9y ago

It’s just mentioned as an aside in this article, but the work the Mono team is doing on WebAssembly is super exciting. Can’t wait to start messing with it.

lewurm 9y ago
check out https://twitter.com/kumpera/status/924007954696646656 https://twitter.com/kumpera/status/924007954696646656 and http://blog.stevensanderson.com/2017/11/05/blazor-on-mono/ http://blog.stevensanderson.com/2017/11/05/blazor-on-mono/
- yodon 9y ago
  And WebAssembly support merged into Mono master branch last week https://github.com/mono/mono/pull/5924 https://github.com/mono/mono/pull/5924 (not available as a release build, but soon)
akoeplinger 9y ago
Great to hear that you're excited by it, we're too :) This blog post has a few more details and examples of the WebAssembly work: http://www.mono-project.com/news/2017/08/09/hello-webassembly/ http://www.mono-project.com/news/2017/08/09/hello-webassembl... Disclaimer: I'm working on Mono for Microsoft/Xamarin (primarily class libraries and tools).

gmaster1440 9y ago

Curious to see how this plays out with Microsoft investing in cross-platform development with .NET Core and .NET Standard. The consequences of having multiple competing cross-platform options are already evident when using tools like intellisense in VS Code where you can (or used to be able to) switch between Mono and .NET Core runtimes and certain libraries were only compatible with one. And then there are build tools like Paket which currently only support Mono even though Paket itself can provision .NET Core runtimes.

maxxxxx 9y ago
I agree that having mono and .NET Core being developed at the same time is not a good thing. How do you pick one over the other? There is way too much overlap. With .NET core being open source they should find a way to work with the mono team.
- cptskippy 9y ago
  Isn't .NET Core a Subset of Mono? I though Mono was like a cross platform version of the .NET Framework, of which .NET Core is also a subset.
  - debacle 9y ago
    .NET Core is incompatible with the .NET Framework which Mono is the oss counterpart to.
    - memsom 9y ago
      I think it depends on what you are trying to achieve. They are all slightly incompatible to some degree. I've written quire a few libs in .Net Standard and had them work on all three platforms, as well as writing Core command line apps and ported them to .Net 4.5. The issue is more with stuff like ASP.Net Core etc, where the libraries are slightly different conceptually.
    - cptskippy 9y ago
      That's the official line but I honestly don't know anymore. We were trying to write a few cross platform libraries that we could also consume in Framework. We could not get .NET Standard libraries to import into Framework Apps without entering a dependency hell that made me long for the DLL Hell of the 90s. We discovered that re-targeting .NET Standard projects to .NET Core would allow them to be imported into .NET Framework projects without issue. Of course you can't import .NET Core libraries into .NET Standard so in the end we actually made projects for each of them with links back to the .NET Standard libraries' files.
  - 9y ago

alkonaut 9y ago

What is the main attraction of a proper interpreter vs. the with the compiler built into the platform (so static, but at runtime) that we have with Roslyn? I do some in-app scripting etc and I basically just compile/run code at runtime using Roslyn then. Performance is probably a benefit of doing that, but what is the drawback? is it more overhead e.g. in an interactive setting it might not be responsive for a REPL?

chrisseaton 9y ago
Roslyn is entirely unrelated. That's the compiler to CLIR. We're talking about the runtime interpreter and compiler to native code.
- alkonaut 9y ago
  Yes? My question was "whats the benefit of an interpreter for runtime code exec, over using a compiler-as-a-service like Roslyn"
  - chrisseaton 9y ago
    You've asked what is the benefit of using apples over oranges. The two things are unrelated. When you use Roslyn you still need either a JIT or an interpreter to execute the output of Roslyn. You can't ask what is the benefit of using the interpreter over using Roslyn as you cannot do that. They don't fit into the same place in the system. They don't do the same job. They aren't alternatives. It's a nonsense question.
    - alkonaut 9y ago
      This is a somewhat better answer :) The reason I'm asking was because the interpreter was framed as a solution to in-app code execution (e.g like Lua in many game engines) - but this type of scripting is exactly what I use Roslyn for. So if I can rephrase it: what is the benefit of interpreted scripts vs dynamic compilation of scripts in the context of , for example, app scripting? Specifically in .NET apps. Not e.g. a C++ app (there it's obvious as a replacement for e.g Lua) > When you use Roslyn you still need either a JIT or an interpreter Yes: Assume I'm already in a .NET appxontext so yes I have the JIT available. Does that make the interpreter less attractive as I can just load compiled code there? I'm guessing then the benefit might be less initial overhead, but at the expense of slower execution?

peoplewindow 9y ago

It's interesting how .NET is converging on the same runtime techniques used in Java and yet how drastically far behind they are. The Java guys realised that an interpreter was still useful decades ago. Tiered compilation shipped in Java 8, and that was more complex to implement as there were two JITs, so JITd code still had to do profiling. It's also quite interesting that the interpreter was dropped due to the complexity introduced by having generics in the runtime. A long time ago I thought it was self evident that type erasure was a poor way to do generics, but Brian Goetz has been arguing persistently for years now that type erasure isn't necessarily a bug, just a different tradeoff. With runtime complexity being one of the factors that weighed into the decision ... something that's easier to understand now I read this blog post. There are some things I like about .NET though it was a long time since I did any, but HotSpot seems so dramatically far ahead and the distance is increasing. The major selling point of .NET over Java originally was supposed to be great multi-language support (well, and better Windows support), but there are way more languages targeting the JVM than the CLR these days. HotSpot does tiered compilation, it now does AOT compilation too, it has a new JIT called Graal that either matches or completely smokes the best available runtimes for almost every language, and IntelliJ is every bit the match for Visual Studio. And it's all cross platform. So what's .NET's major selling point these days?

jackmott 9y ago
>but HotSpot seems so dramatically far ahead and the distance is increasing. Benchmarkgame scores reached basically parity between java and C# once .net core 2.0 dropped .NET selling points: * you can do some SIMD explicitly, more is coming * you have control over when things are stack allocated or not. structs, stackalloc, slices * you have unsigned ints
- peoplewindow 9y ago
  Hm, seems like the big win for C# was actually someone going in and optimising the benchmark programs themselves: http://anthonylloyd.github.io/blog/2017/08/15/dotnetcore-performance http://anthonylloyd.github.io/blog/2017/08/15/dotnetcore-per... The point of explicit control is usually performance though. So if Java can give you near equal or better performance but without the developer having to explicitly specify as much, isn't that a win? Benchmark game also lacks the benchmark the Mono blog post is all about - developer iteration time.

Annatar 9y ago

For example, some game developers like to adjust and tweak their game code, without having to trigger a full recompilation. The static compilation makes this scenario impractical, so they resort to embedding a scripting language into their game code to quickly iterate and tune their projects. There is a programming language where every new expression causes incremental compilation and linking inherently, natively: it’s called Lisp.

FrgmntnFatigue 9y ago

What is the rationale for keeping working on mono rather than just port its unique libraries (gtk# etc.) to coreclr ?