4 ms·

The speed-up very much depents on the (micro)benchmark in use. I did some measurements using the Are-we-fast-yet benchmark suite which includes both micro and l

• jmkni 5y ago
  Would be interested to see this benchmark on M1 (Apple Silicon), are there instructions on how to run it on that?
  • Rochus 5y ago
    If you want to compare different .NET versions running natively on M1 such versions must be available as a precondition. If so, just download e.g. http://software.rochus-keller.ch/Are-we-fast-yet_CLI_2021-08-28.zip http://software.rochus-keller.ch/Are-we-fast-yet_CLI_2021-08..., update the included runtimeconfig.json file to the .NET version in use and run it (dotnet Main.exe).
    • jmkni 5y ago
      Ok nice, will give that a go, cheers :)
• rndgermandude 5y ago
  You're cross-compiling from the Oberon+ language to CLR IL bytecode using your own compiler... This isn't exactly something a lot of people would do. Most people would write more or less idiomatic C# and have the "official" compiler (Roslyn) produce the byte code. What I am saying, I guess, is that I am not quite sure how much of your benchmark results come down to the quality of IL your custom compiler spits out.
  • munchler 5y ago
    As an F# developer, I find it a little frustrating when people assume.NET = C#. If the blog post is about the speed of IL generated by the latest C# compiler, it should say so in the title instead of claiming to measure the performance of .NET in general.
    • ygra 5y ago
      The runtime team certainly looks at discrepancies where C# and F# generate different IL that should still run about the same when JIT-compiled. So while C# is the main focus (also since the runtime libraries are written in C#), F# is not forgotten and benefits from a lot of those improvements as well.
      • pjmlp 5y ago
        In what concerns .NET Native, F# was definitly forgotten, given that for a long time it did not compile MSIL required by F#. And even though it works today, it is more of an hack than anything I would thrust to sign into production with my name on it.
  • Rochus 5y ago
    > You're cross-compiling from the Oberon+ language to CLR IL bytecode ... It's just "compiling", not "cross-compiling"; using CLR/CIL as a language backend is an intended feature, that's why the CLR and IL are standardized in ECMA-335 and ISO 23271, and that's why it is called "common language infrastructure". > Most people would write more or less idiomatic C# You are welcome to write a C# version of the benchmark. > have the "official" compiler (Roslyn) It's not the "official" compiler, but just the C# compiler implemented by MS and community; there are a lot of other compilers too.
    • infogulch 5y ago
      You're arguing semantics. GP's point is that the compiler shipped with the platform may produce better byte code, which could have an affect on the benchmark results. This seems like a reasonable point to make.
• ripley12 5y ago
  It looks like you're not using the new dynamic PGO functionality (the OP is). I've seen throughput gains of ~15% from that.