For everyone who is confused by what is going on, here's the explanation:
Today, there are 2.5 Mono's:
Mono that lives in https://github.com/mono/mono. This is the original Mono codebase that was written back then and was the .NET Framework for Linux, with corresponding compat. and such, pioneered by Miguel De Icaza, who now seems to be happier in Swift land. At the present day, it was receiving very little maintenance and I don't believe was actively used. Please correct me if I'm wrong.
Mono that lives in https://github.com/dotnet/runtime/tree/main/src/mono. This is the Mono that got merged into .NET, becoming the building block for multiple components and one of the official runtime flavours. It is actively maintained and is at relative feature parity with CoreCLR, predominantly serving mobile targets (iOS, Android) and WASM as well as exotic or legacy targets like ARMv6, LA64, s390x(?), ppc64. It is also useful for initial stages of new platform bring-up process. Note that you are not expected to use it for targets that support CoreCLR due to a massive rift in performance between the two. When you are using it, you do so as a part of standard .NET toolchain - it is picked automatically for appropriate targets, or can be opted into with some configuration.
Mono that lives in https://gitlab.winehq.org/wine-mono/mono which is a Mono fork actively maintained by Wine for its own usage. Going forward, any possible ambiguities regarding ownership and stewardship are considered resolved and the ownership of mono/mono and everything related to it is transferred to WineHQ.
Honorable mention also goes to private Mono fork used by Unity which they are (painfully) trying to migrate from.
The comparison we discussed was for unrepresentative code that used none of the features that make .NET fast (generics, SIMD, expected forms of inheritance and abstraction and devirtualization they enable, CoreLib APIs). The closest case in there was JSON serialization which CoreCLR was 385% faster at. It is unfortunate that you feel a need to say this, knowing that it doesn't even show a tip of the iceberg.
Please do not mislead casual readers here with such comments.
They will have a bad time running basic programs - the original Mono is outdated and cannot execute assemblies that target non-legacy versions, and the Mono that lives in dotnet/runtime (which you have to go out of your way to use on CoreCLR platforms) tends to have all kinds of regressions on user-provided code that is not as robust on runtime checks to ensure that Mono does not accidentally go onto the path that that it has especially bad regression on. Even CoreLib code nowadays uses more and more struct generics assuming monomorhpization which performs poorly on Mono. There is very little work done to improve performance on Mono with effort invested mostly in WASM area and to ensure it does not regress further. Major platforms like Android and iOS are in the slow but steady progress to migrate to CoreCLR/NativeAOT (there are other reasons not in the least much smaller binary size). And for WASM there is NativeAOT-LLVM experiment that is likely to make Mono obsolete for that target too.
The workloads that matter and are representative are the ones produced by C#, F# and VB.NET compilers as well as projects that care about exercising the standard library and/or produce recommended CIL forms (like https://github.com/FractalFir/rustc_codegen_clr).
Why so arrogant? The CIL is good enough. It's a promise of the ECMA-335 to cope even with unoptimized CIL, and Mono indeed includes many optimization steps. Your arguments - especially concerning SIMD and other features supported by CoreCLR - are absolutely not relevant in this context. CIL is always the same (regardless whether the CIL was generated by your big C# or my small Oberon compiler), and if I feed unoptimized CIL to CoreCLR, it still has the opportunity to make use of the SIMD features of the given CPU if need be. As already discussed it's even more interesting to base the performance comparison on unoptimized CIL, because by the end of the day we all want to know how good the optimizers of Mono or CoreCLR are.
And you didn't answer my question, so I assume you're working for Microsoft or some of their affiliates, and your claims are obviously biased by this.
Comparison against Oberon+ string primitives allocates a new char array every time. Other operations allocated it to just null-terminate it (string constants are null-terminated already for example, or can be done so explicitly by compiler instead, in any case this is an incorrect design). Somehow, it failed the basic task of modeling C behaviors on the one and only high-level bytecode target that comes to modeling C the closest. This was the very first thing I saw when I opened the compilation artifacts with ILSpy.
In any case, my goal was to post a disclaimer and it is fulfilled.
> string primitives allocates a new char array every time.
So what? What do you think do the dotnet string or marshalling classes internally? And how should that affect the performance comparison if we feed the same CIL to both - Mono and CoreCLR?
But we can leave it at this; people can read the arguments at the given link, we don't have to repeat everything again.
If we compare the last major release of Mono back in 2019, where there was a real improvement to the CLR (not just bug and security fixes), with the CoreCLR versions at that time, the factor is rather 1.1 (see e.g. https://www.quora.com/Is-the-Mono-CLR-really-slower-than-Cor...).
Today, there are 2.5 Mono's:
Mono that lives in https://github.com/mono/mono. This is the original Mono codebase that was written back then and was the .NET Framework for Linux, with corresponding compat. and such, pioneered by Miguel De Icaza, who now seems to be happier in Swift land. At the present day, it was receiving very little maintenance and I don't believe was actively used. Please correct me if I'm wrong.
Mono that lives in https://github.com/dotnet/runtime/tree/main/src/mono. This is the Mono that got merged into .NET, becoming the building block for multiple components and one of the official runtime flavours. It is actively maintained and is at relative feature parity with CoreCLR, predominantly serving mobile targets (iOS, Android) and WASM as well as exotic or legacy targets like ARMv6, LA64, s390x(?), ppc64. It is also useful for initial stages of new platform bring-up process. Note that you are not expected to use it for targets that support CoreCLR due to a massive rift in performance between the two. When you are using it, you do so as a part of standard .NET toolchain - it is picked automatically for appropriate targets, or can be opted into with some configuration.
Mono that lives in https://gitlab.winehq.org/wine-mono/mono which is a Mono fork actively maintained by Wine for its own usage. Going forward, any possible ambiguities regarding ownership and stewardship are considered resolved and the ownership of mono/mono and everything related to it is transferred to WineHQ.
Honorable mention also goes to private Mono fork used by Unity which they are (painfully) trying to migrate from.