5 ms·

I've always wondered at the performance of Mono relative to the Real C#, but I suspect that Microsoft has language in the license to prevent such benchmarks (or

I've always wondered at the performance of Mono relative to the Real C#, but I suspect that Microsoft has language in the license to prevent such benchmarks (or something)... Some benchmarks are in the Game. Looking over the benchmarks, I realized that I shouldn't be comparing Mono to the Real C# since I wouldn't ever run Mono on Windows. I'd only ever run it on Linux, so, if you're running a Linux stack, Mono should be compared to its colleagues in the Linux space. Mono vs Java: http://benchmarksgame.alioth.debian.org/u64q/csharp.php Mono vs Go : http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=csharp&lang2=go Mono vs Rust: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=csharp&lang2=rust

pjmlp 12y ago
With the caveat language != implementation.
- bunderbunder 12y ago
  True, but FWIW that site is somewhat admirable for at least trying to cut implementation out & focus on language. For example, see the documentation for the binary-trees test: http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=binarytrees http://benchmarksgame.alioth.debian.org/u64q/performance.php... There are a bunch of notes trying to make it very explicit that this test is supposed to isolate the garbage collector's performance. So they discourage lazy evaluation on the grounds that it might not produce the kind of allocation pattern the test is supposed to generate, and there's that bold admonition against memory management hacks, and all of that. I'm sure there's still plenty room for gaming the system, but looking at the actual C# & Java implementations for the test reveal that by-and-large they really are roughly equivalent. In particular, the C# doesn't resort to any obvious dirty trick like declaring the tree node datatype as a struct rather than a class. The upshot being, what that particularly test suggests is something that probably shouldn't come as much surprise: Mono's gc, while good, isn't quite as performant as HotSpot's.
  - pjmlp 12y ago
    I am speaking about language implementation, not algorithm implementation. Most of those tests are using just one single compiler implementation per language. It would be much fairer to have multiple compiler implementations per language being used.

pjmlp 12y ago

With the caveat language != implementation.

bunderbunder 12y ago
True, but FWIW that site is somewhat admirable for at least trying to cut implementation out & focus on language. For example, see the documentation for the binary-trees test: http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=binarytrees http://benchmarksgame.alioth.debian.org/u64q/performance.php... There are a bunch of notes trying to make it very explicit that this test is supposed to isolate the garbage collector's performance. So they discourage lazy evaluation on the grounds that it might not produce the kind of allocation pattern the test is supposed to generate, and there's that bold admonition against memory management hacks, and all of that. I'm sure there's still plenty room for gaming the system, but looking at the actual C# & Java implementations for the test reveal that by-and-large they really are roughly equivalent. In particular, the C# doesn't resort to any obvious dirty trick like declaring the tree node datatype as a struct rather than a class. The upshot being, what that particularly test suggests is something that probably shouldn't come as much surprise: Mono's gc, while good, isn't quite as performant as HotSpot's.
- pjmlp 12y ago
  I am speaking about language implementation, not algorithm implementation. Most of those tests are using just one single compiler implementation per language. It would be much fairer to have multiple compiler implementations per language being used.