4 ms·

It was interesting to look at how .NET deals with arbitrary assemblies from something that isn't C# or F#. In the end, I did not bother with manually linking .d

It was interesting to look at how .NET deals with arbitrary assemblies from something that isn't C# or F#. In the end, I did not bother with manually linking .dll files for ILC so there will be only JIT results. In general, I do not think the CIL back-end for Oberon produces good code. It is compiler-unfriendly, ignores functions provided by .NET's CoreLib (available both under Mono and CoreCLR) to use its own poorly performing variants of them, makes everything virtual and etc. It does silly things like makes all references to a string literal into an array allocation ("test".ToCharArray()) to just do a comparison, then also treats such arrays as zero-terminated pointers despite, well, .NET arrays having length in them included already, and more. Overall, a disregard what CIL, CLI and CTS are and what they offer. What are you using .NET for if not for writing truly portable C-like? There are already pointers and manual memory management, the lowering strategy could have been much closer, and a lot of suffering is very much self-imposed. And the benchmark initially ran for so little time that it would give advantage to pure interpreter based runtime as long as it did very little, or natively compiled binaries. Surely your average program runs more than 200ms? Anyways, you can find these and a couple other notes with data and charts here: https://gist.github.com/neon-sunset/900bd310dc53dd88cbeddb5193d9104d#file-oberon-md https://gist.github.com/neon-sunset/900bd310dc53dd88cbeddb51... Geometric Mean (Mono): 1612026.37 microseconds Geometric Mean (.NET): 847482.65 microseconds Relative .NET advantage: 190.21% I did not have time to look closer in benchmarks with 1:1 numbers, but if you note things like JSON handling which is compiler sensitive, you'll note that the difference there was the biggest.

Rochus 2y ago
Apart from the unnecessarily arrogant remarks, which by the way are completely irrelevant since the same code runs on both measured VMs, no matter how you find it, I find the result interesting and thank you very much for your effort. I had never run CoreCLR on Apple M1 before. Apparently there was indeed a further improvement on this architecture, although still the overall difference is not that dramatic. If I analyze your numbers the same way I did before, I get a geometric mean factor of 1.8, which would almost make it worth switching to CoreCLR, at least on Apple M1. But there are other critical requirements, e.g. that CoreCLR does not support all the platforms I need, and that the debugging support, as far as comparable at all, requires a completely different integration. Just for the speed-up on Apple it's not worth switching. As soon as I find some time, I will try again on x86 and x86_64 and see how it looks there in comparison to my 2021 measurements.
- Rochus 2y ago
  Here are some comparisons to my 2021 measurements. - Mono 5 and Mono 6 on Windows 10 x86 achieved about the same performance (factor 1.04) - Taking Mono 5 as a reference on Windows 10 x64, CoreCLR 3 had about the same performance, CoreCLR 5 was factor 1.3 faster than Mono 5, and CoreCLR 6 was factor 1.2 faster than Mono 5. - The measurements done by neonsunset on Mac M1 show that CoreCLR 9 is factor 1.8 faster than Mono 6; therefore CoreCLR 9 (M1) seems to be around factor 1.4 faster than CoreCLR 5 (x64).
  - neonsunset 2y ago
    The issue of poor lowering strategy remains. The back-end should be using structs, pointers and manual memory management if this is what it does with C. C# supports full set of features to make it possible including (now) raw function pointers. Just no C macros, sorry. It should not even be close to Mono in performance. It should be close to C, given correct back-end output, which it isn't. At this point, outputting C# would have produced much better results that do not defeat compiler optimizations, where CoreCLR performs rather well despite the CIL quality, not because of it. And even then, you can easily see that either computationally intensive or logically complex benchmarks show the biggest difference as they stress out compiler capability the most. In any case, the option to target C# instead would result in guaranteed correct CIL form, with loops written in a way that does not occasionally break loop recognition, does not introduce unnecessary memory and abstraction overhead and does not have the issues with the basics like that one with string comparison that allocates each time for no reason. Also note that compiler improvements are generic - most affect any platform supported, with platform-specific peephole optimizations responsible for cleaning up the codegen and eking out the last %. If-conversion pass for ARM64 is going to be an exception, but on the other hand x86_64 offers wider vectors which .NET makes use of.
    - Rochus 2y ago
      You are still clinging to the same misconception. I want to measure the CLR, not the frontend output. The CLR is by definition a "Common Language Runtime", i.e. it makes the promise to execute applications written in multiple high-level languages without the requirement that these applications have to take into consideration the unique characteristics of the specific CLR or environment. There is no requirement in ISO 23271 whatsoever that the CIL fed to the CLR must meet other requirements than the ones stated in the standard. There is especially no requirement in the standard that the bytecode fed into the CLR must be optimized or meet certain patterns so that loops are recognized. My code is perfectly compliant with the standard. The CLR is essentially a JIT processing a well-defined intermediate language. A JIT is all about optimization. In contrast to a static compiler, a JIT can also consider specific system and runtime information for this purpose. Mono is very good in both static and dynamic optimizations, and it is especially good in handling bytecode from other than the included C# compiler. Microsoft, for some reason, seems to have decided to move a lot of optimizations to their new C# compiler infrastructure, which also heavily uses inside knowledge of the CoreCLR, and generates patterns which the latter is looking for (e.g. for loop detection and the like). It is therefore not surprising if code compiled with Microsoft's own C# compiler runs faster on the CoreCLR than other code. However, I am only interested in the original purpose of the CLR. I don't want to have to use .NET or Microsoft's compiler framework in order for the CLR to achieve good performance. That is why I deliberately use unoptimized code for the performance measurements, which in particular does not take into account any of the rules that Microsoft has introduced outside of the above-mentioned standard. Your arguments would be relevant if different C# compilers + CLR were to be compared with each other, or to my Oberon+ compiler. That is a different use case. As a language developer and not equipped with the resources of Microsoft or the CoreCLR team, I have been able to save a lot of effort by profiting of the CLR standard and of Mono in particular, as forseen by the original purpose of the CLI/CLR. My measurements and claims represent this original purpose and use case. If I had supplied highly optimized bytecode instead, I would - besides my much larger effort - to a large extent be measuring the compiler frontend (or its consideration of the many, sparsely documented rules that the bytecode must take into account beyond the standard in order for CoreCLR to run optimally), not the CLR. That said, if you want to immortalize yourself in the Are-we-fast-yet community, you could contribute a C# implementation of the benchmark suite. This would be a good way to measure the influence of the frontend on CLR performance, which would also be very interesting.

Rochus 2y ago

Apart from the unnecessarily arrogant remarks, which by the way are completely irrelevant since the same code runs on both measured VMs, no matter how you find it, I find the result interesting and thank you very much for your effort. I had never run CoreCLR on Apple M1 before. Apparently there was indeed a further improvement on this architecture, although still the overall difference is not that dramatic. If I analyze your numbers the same way I did before, I get a geometric mean factor of 1.8, which would almost make it worth switching to CoreCLR, at least on Apple M1. But there are other critical requirements, e.g. that CoreCLR does not support all the platforms I need, and that the debugging support, as far as comparable at all, requires a completely different integration. Just for the speed-up on Apple it's not worth switching. As soon as I find some time, I will try again on x86 and x86_64 and see how it looks there in comparison to my 2021 measurements.

Rochus 2y ago
Here are some comparisons to my 2021 measurements. - Mono 5 and Mono 6 on Windows 10 x86 achieved about the same performance (factor 1.04) - Taking Mono 5 as a reference on Windows 10 x64, CoreCLR 3 had about the same performance, CoreCLR 5 was factor 1.3 faster than Mono 5, and CoreCLR 6 was factor 1.2 faster than Mono 5. - The measurements done by neonsunset on Mac M1 show that CoreCLR 9 is factor 1.8 faster than Mono 6; therefore CoreCLR 9 (M1) seems to be around factor 1.4 faster than CoreCLR 5 (x64).
- neonsunset 2y ago
  The issue of poor lowering strategy remains. The back-end should be using structs, pointers and manual memory management if this is what it does with C. C# supports full set of features to make it possible including (now) raw function pointers. Just no C macros, sorry. It should not even be close to Mono in performance. It should be close to C, given correct back-end output, which it isn't. At this point, outputting C# would have produced much better results that do not defeat compiler optimizations, where CoreCLR performs rather well despite the CIL quality, not because of it. And even then, you can easily see that either computationally intensive or logically complex benchmarks show the biggest difference as they stress out compiler capability the most. In any case, the option to target C# instead would result in guaranteed correct CIL form, with loops written in a way that does not occasionally break loop recognition, does not introduce unnecessary memory and abstraction overhead and does not have the issues with the basics like that one with string comparison that allocates each time for no reason. Also note that compiler improvements are generic - most affect any platform supported, with platform-specific peephole optimizations responsible for cleaning up the codegen and eking out the last %. If-conversion pass for ARM64 is going to be an exception, but on the other hand x86_64 offers wider vectors which .NET makes use of.
  - Rochus 2y ago
    You are still clinging to the same misconception. I want to measure the CLR, not the frontend output. The CLR is by definition a "Common Language Runtime", i.e. it makes the promise to execute applications written in multiple high-level languages without the requirement that these applications have to take into consideration the unique characteristics of the specific CLR or environment. There is no requirement in ISO 23271 whatsoever that the CIL fed to the CLR must meet other requirements than the ones stated in the standard. There is especially no requirement in the standard that the bytecode fed into the CLR must be optimized or meet certain patterns so that loops are recognized. My code is perfectly compliant with the standard. The CLR is essentially a JIT processing a well-defined intermediate language. A JIT is all about optimization. In contrast to a static compiler, a JIT can also consider specific system and runtime information for this purpose. Mono is very good in both static and dynamic optimizations, and it is especially good in handling bytecode from other than the included C# compiler. Microsoft, for some reason, seems to have decided to move a lot of optimizations to their new C# compiler infrastructure, which also heavily uses inside knowledge of the CoreCLR, and generates patterns which the latter is looking for (e.g. for loop detection and the like). It is therefore not surprising if code compiled with Microsoft's own C# compiler runs faster on the CoreCLR than other code. However, I am only interested in the original purpose of the CLR. I don't want to have to use .NET or Microsoft's compiler framework in order for the CLR to achieve good performance. That is why I deliberately use unoptimized code for the performance measurements, which in particular does not take into account any of the rules that Microsoft has introduced outside of the above-mentioned standard. Your arguments would be relevant if different C# compilers + CLR were to be compared with each other, or to my Oberon+ compiler. That is a different use case. As a language developer and not equipped with the resources of Microsoft or the CoreCLR team, I have been able to save a lot of effort by profiting of the CLR standard and of Mono in particular, as forseen by the original purpose of the CLI/CLR. My measurements and claims represent this original purpose and use case. If I had supplied highly optimized bytecode instead, I would - besides my much larger effort - to a large extent be measuring the compiler frontend (or its consideration of the many, sparsely documented rules that the bytecode must take into account beyond the standard in order for CoreCLR to run optimally), not the CLR. That said, if you want to immortalize yourself in the Are-we-fast-yet community, you could contribute a C# implementation of the benchmark suite. This would be a good way to measure the influence of the frontend on CLR performance, which would also be very interesting.