3 ms·

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 peopl

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.
  - Rochus 5y ago
    Don't forget that IL is not executed, but is just an intermediate representation, and optimizations are done by the CLR; e.g. Mono does the following optimizations (according to e.g. https://man.archlinux.org/man/mono.1.en https://man.archlinux.org/man/mono.1.en), regardless which compiler generated the IL: branch Branch optimizations cfold Constant folding cmov Conditional moves [arch-dependency] deadce Dead code elimination consprop Constant propagation copyprop Copy propagation fcmov Fast x86 FP compares [arch-dependency] float32 Perform 32-bit float arithmetic using 32-bit operations gshared Enable generic code sharing. inline Inline method calls intrins Intrinsic method implementations linears Linear scan global reg allocation leaf Leaf procedures optimizations loop Loop related optimizations peephole Peephole postpass precomp Precompile all methods before executing Main sched Instruction scheduling shared Emit per-domain code sse2 SSE2 instructions on x86 [arch-dependency] tailc Tail recursion and tail calls
    - forrestthewoods 5y ago
      I don’t think you’re being very reasonable here. You made a claim. Someone disputed the validity of your evidence. And your response is “well you can rewrite/replicate my entire project if you like”. I think most people are going to assume your claim is bullshit and move on with their lives. You made the unconventional claim so the burden of proof is on you.
      - Rochus 5y ago
        > You made the unconventional claim so the burden of proof is on you. My assertion is supported by sufficient evidence. The criteria of scientificity are fulfilled. You can repeat the experiment on your system yourself if you wish. Under the referenced links you will find everything necessary to do so.

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.
- Rochus 5y ago
  Don't forget that IL is not executed, but is just an intermediate representation, and optimizations are done by the CLR; e.g. Mono does the following optimizations (according to e.g. https://man.archlinux.org/man/mono.1.en https://man.archlinux.org/man/mono.1.en), regardless which compiler generated the IL: branch Branch optimizations cfold Constant folding cmov Conditional moves [arch-dependency] deadce Dead code elimination consprop Constant propagation copyprop Copy propagation fcmov Fast x86 FP compares [arch-dependency] float32 Perform 32-bit float arithmetic using 32-bit operations gshared Enable generic code sharing. inline Inline method calls intrins Intrinsic method implementations linears Linear scan global reg allocation leaf Leaf procedures optimizations loop Loop related optimizations peephole Peephole postpass precomp Precompile all methods before executing Main sched Instruction scheduling shared Emit per-domain code sse2 SSE2 instructions on x86 [arch-dependency] tailc Tail recursion and tail calls
  - forrestthewoods 5y ago
    I don’t think you’re being very reasonable here. You made a claim. Someone disputed the validity of your evidence. And your response is “well you can rewrite/replicate my entire project if you like”. I think most people are going to assume your claim is bullshit and move on with their lives. You made the unconventional claim so the burden of proof is on you.
    - Rochus 5y ago
      > You made the unconventional claim so the burden of proof is on you. My assertion is supported by sufficient evidence. The criteria of scientificity are fulfilled. You can repeat the experiment on your system yourself if you wish. Under the referenced links you will find everything necessary to do so.