4 ms·

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

• 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.
    • neonsunset 2y ago
      I won't - already spent enough time on this and don't have more. My points were only that repurposing C emitter to target C# as well, with the same structs/pointers/memory management is likely both easier and bound to produce massively faster performing solution than something that has deliberately compiler-unfriendly IL. But even if you target CIL, intentionally using incorrect structures or the ones that are different to C back-end, especially around string comparisons, sounds like ignoring what the platform can offer. You can keep discounting my suggestions as something that is outside of ECMA spec and to be ignored, which it isn't. At least the cases like this one are few and far between and serious projects like IronPython3, ClojureCLR or Godot use appropriate runtime.
      • deleted 2y ago
        [deleted]
• kragen 2y ago
  that's exciting data!