4 ms·

I ran into stability problems with the Oberon+ FFI which I was not able to solve with the LuaJIT bytecode generator; so I switched to Mono, which even has a muc

by Rochus 2y ago

I ran into stability problems with the Oberon+ FFI which I was not able to solve with the LuaJIT bytecode generator; so I switched to Mono, which even has a much better debugging infrastructure, and for speed I also implemented a C transpiler, the result of which is very close to the native C++ implementation. SOM was mostly an effort to find out how close we can come to Cog with a LuaJIT backend, as a follow-up to my Smalltalk LuaJIT adventure.

kragen 2y ago
i see! hmm, are you going to have to switch to .net core now? or are mono users succeeding in banding together to handle security updates in precisely the way python 2 users have failed to?
- Rochus 2y ago
  I'm not using the dotnet framework, just the clr, and for the use cases covered by Oberon+ security is of little concern. The project is still regularly updated, see https://github.com/mono/mono/commits/main/ https://github.com/mono/mono/commits/main/.
  - neonsunset 2y ago
    Please don't use this Mono flavour as it is still outdated. If possible, please use the Mono runtime that lives in https://github.com/dotnet/runtime/tree/main/src/mono https://github.com/dotnet/runtime/tree/main/src/mono Ideally, CoreCLR will give you much better performance, ability to AOT compile your binaries to native executables and will remove the need for multiple back-ends.
    - Rochus 2y ago
      These are two different Mono implementations. The one maintained by MS has a different focus. I'm mostly interested in a lean, independent build and many different targets (e.g. Apple M1). The "much better performance" of CoreCLR is a fairy tale (see e.g. https://www.quora.com/Is-the-Mono-CLR-really-slower-than-CoreCLR/answer/Rochus-Keller https://www.quora.com/Is-the-Mono-CLR-really-slower-than-Cor...). Actually, Mono supported AOT even before the CoreCLR (but I don't need it, because I have a to C transpiler which produces cross-platform near-native performance).
      - kragen 2y ago
        this is fantastic information, thanks!
      - neonsunset 2y ago
        Unfortunately, there are a few issues with this quora post. First it is outdated - .NET is on an annual cadence and statements true for 3.1 or 5 have no impact on user experience today, second it focuses on edge case differences with log scale rather than the full picture. Also note that compiler improves significantly with each version - look at the difference between 3.1, 5 and 6. The differences between 6 and 8 are way more significant (DynamicPGO light-up, physical promotion for structs, etc.). And third there is more to the story than microbenchmarks. Again, there is a huge rift in performance between Mono and CoreCLR, and there are classes of optimizations Mono does not and will not do, like devirtualization. All optimization work goes into CoreCLR for multiple ISAs. Mono does not support AVX2 and AVX512, which core routines in .NET CoreLib rely on if available. It doesn't have a fancy if-conversion pass to merge branches and comparisons that CoreCLR does for ARM64, write barrier optimizations, etc etc. This is not a myth but what anyone who works closely with .NET or is a part of .NET teams will tell you. For example, look at https://aka.ms/aspnet/benchmarks https://aka.ms/aspnet/benchmarks select mono tab and pick coreclr and fortunes - you'll notice that Mono is more than five times slower than CoreCLR. And it is the Mono flavour which also sees performance improvements for the features that .NET adds or optimizations focused on targets served by Mono. Also, the independent build is not independent - it limps along Unity Technologies contributions until Unity finishes its move to CoreCLR, which they are in the process of.
        Rochus 2y ago
        The post is good enough, using recognized methods and allowing reproducability. It considers different CoreCLR and Mono versions, and there is no reason to assume big performance differences since. The raw data is referenced, you can use a different scale if you prefer, but the information is the same. If you are interested, take a look at the Are-we-fast-yet benchmark suite to see that it is well defined, not just a bunch of random micro benchmarks, but also includes a few larger programs (e.g. to exercise the GC). And again: this is about the CLR, not the framework. I'm not interested in the .NET framework implementation. The build works well on all platforms without any dependencies and without downloading and compiling several gigs of stuff.

by Rochus 2y ago

kragen 2y ago

i see! hmm, are you going to have to switch to .net core now? or are mono users succeeding in banding together to handle security updates in precisely the way python 2 users have failed to?

Rochus 2y ago
I'm not using the dotnet framework, just the clr, and for the use cases covered by Oberon+ security is of little concern. The project is still regularly updated, see https://github.com/mono/mono/commits/main/ https://github.com/mono/mono/commits/main/.
- neonsunset 2y ago
  Please don't use this Mono flavour as it is still outdated. If possible, please use the Mono runtime that lives in https://github.com/dotnet/runtime/tree/main/src/mono https://github.com/dotnet/runtime/tree/main/src/mono Ideally, CoreCLR will give you much better performance, ability to AOT compile your binaries to native executables and will remove the need for multiple back-ends.
  - Rochus 2y ago
    These are two different Mono implementations. The one maintained by MS has a different focus. I'm mostly interested in a lean, independent build and many different targets (e.g. Apple M1). The "much better performance" of CoreCLR is a fairy tale (see e.g. https://www.quora.com/Is-the-Mono-CLR-really-slower-than-CoreCLR/answer/Rochus-Keller https://www.quora.com/Is-the-Mono-CLR-really-slower-than-Cor...). Actually, Mono supported AOT even before the CoreCLR (but I don't need it, because I have a to C transpiler which produces cross-platform near-native performance).
    - kragen 2y ago
      this is fantastic information, thanks!
    - neonsunset 2y ago
      Unfortunately, there are a few issues with this quora post. First it is outdated - .NET is on an annual cadence and statements true for 3.1 or 5 have no impact on user experience today, second it focuses on edge case differences with log scale rather than the full picture. Also note that compiler improves significantly with each version - look at the difference between 3.1, 5 and 6. The differences between 6 and 8 are way more significant (DynamicPGO light-up, physical promotion for structs, etc.). And third there is more to the story than microbenchmarks. Again, there is a huge rift in performance between Mono and CoreCLR, and there are classes of optimizations Mono does not and will not do, like devirtualization. All optimization work goes into CoreCLR for multiple ISAs. Mono does not support AVX2 and AVX512, which core routines in .NET CoreLib rely on if available. It doesn't have a fancy if-conversion pass to merge branches and comparisons that CoreCLR does for ARM64, write barrier optimizations, etc etc. This is not a myth but what anyone who works closely with .NET or is a part of .NET teams will tell you. For example, look at https://aka.ms/aspnet/benchmarks https://aka.ms/aspnet/benchmarks select mono tab and pick coreclr and fortunes - you'll notice that Mono is more than five times slower than CoreCLR. And it is the Mono flavour which also sees performance improvements for the features that .NET adds or optimizations focused on targets served by Mono. Also, the independent build is not independent - it limps along Unity Technologies contributions until Unity finishes its move to CoreCLR, which they are in the process of.
      - Rochus 2y ago
        The post is good enough, using recognized methods and allowing reproducability. It considers different CoreCLR and Mono versions, and there is no reason to assume big performance differences since. The raw data is referenced, you can use a different scale if you prefer, but the information is the same. If you are interested, take a look at the Are-we-fast-yet benchmark suite to see that it is well defined, not just a bunch of random micro benchmarks, but also includes a few larger programs (e.g. to exercise the GC). And again: this is about the CLR, not the framework. I'm not interested in the .NET framework implementation. The build works well on all platforms without any dependencies and without downloading and compiling several gigs of stuff.