4 ms·

> If this results in a useable, performant (e.g. NOT mono) C#/CLR implementation on *nix, that makes a lot of things very interesting. I'm not sure what yiou m

> If this results in a useable, performant (e.g. NOT mono) C#/CLR implementation on *nix, that makes a lot of things very interesting. I'm not sure what yiou mean by this. Do you mean you want a new implementation that inst' mono? or that you don't believe that mono is fast? if its the later then I'd have to disagree with you. We use mono for a real time trading system and find it to be more than capable of handling our needs.

friism 13y ago
This is a nit-pick of mine, but Mono seems to be always at the bottom of this benchmark: http://www.techempower.com/benchmarks/ http://www.techempower.com/benchmarks/ If you could share details on Mono tuning for server workloads, It'd be very interested.
- marshray 13y ago
  Looking at the error count column suggests that the benchmark setup is just plain broken. I can't imagine the times are accurate.
  - pekk 13y ago
    After many of its iterations have been posted to HN with little improvement in quality, it's clear that the point of the benchmark is to tout certain languages like Java, so this is not surprising
    - lmm 13y ago
      I don't think this is fair. Is there a better alternative available?
      - marshray 13y ago
        There's the old favorite http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php http://shootout.alioth.debian.org/u32/which-programming-lang... But it's down at the moment http://downforeveryoneorjustme.com/shootout.alioth.debian.org http://downforeveryoneorjustme.com/shootout.alioth.debian.or...
T-A 13y ago
My 2 cents: I recently needed to run some .NET code which (1) relies heavily on floating point math and (2) constantly creates and destroys lots of objects in the course of said number crunching. A typical run would take from several hours to more than a day. Doing this on Linux with the latest Mono proved painful: it kept crashing at random points, with native errors suggesting the problem was in Mono's memory management. The same code never crashes on Windows/.NET, and it runs 3-4 times faster (same hardware booting off a Windows partition instead of Linux). This is not what I would like to report, because I really like both Linux and .NET, and I would love for Mono to be competitive. Maybe today's news will contribute to that happening.
- sigzero 13y ago
  You should have brought that up to Xamarin. I am sure they would have liked to see what was going on to make mono better.
  - knocte 13y ago
    Exactly, one reports bugs in the bug tracker (with code that demonstrates the issue), not in HN. By the way, did you test with the new garbage collector? (Enabled by default in Mono 3.2.x)

friism 13y ago

This is a nit-pick of mine, but Mono seems to be always at the bottom of this benchmark: http://www.techempower.com/benchmarks/ http://www.techempower.com/benchmarks/ If you could share details on Mono tuning for server workloads, It'd be very interested.

marshray 13y ago
Looking at the error count column suggests that the benchmark setup is just plain broken. I can't imagine the times are accurate.
- pekk 13y ago
  After many of its iterations have been posted to HN with little improvement in quality, it's clear that the point of the benchmark is to tout certain languages like Java, so this is not surprising
  - lmm 13y ago
    I don't think this is fair. Is there a better alternative available?
    - marshray 13y ago
      There's the old favorite http://shootout.alioth.debian.org/u32/which-programming-languages-are-fastest.php http://shootout.alioth.debian.org/u32/which-programming-lang... But it's down at the moment http://downforeveryoneorjustme.com/shootout.alioth.debian.org http://downforeveryoneorjustme.com/shootout.alioth.debian.or...

T-A 13y ago

My 2 cents: I recently needed to run some .NET code which (1) relies heavily on floating point math and (2) constantly creates and destroys lots of objects in the course of said number crunching. A typical run would take from several hours to more than a day. Doing this on Linux with the latest Mono proved painful: it kept crashing at random points, with native errors suggesting the problem was in Mono's memory management. The same code never crashes on Windows/.NET, and it runs 3-4 times faster (same hardware booting off a Windows partition instead of Linux). This is not what I would like to report, because I really like both Linux and .NET, and I would love for Mono to be competitive. Maybe today's news will contribute to that happening.

sigzero 13y ago
You should have brought that up to Xamarin. I am sure they would have liked to see what was going on to make mono better.
- knocte 13y ago
  Exactly, one reports bugs in the bug tracker (with code that demonstrates the issue), not in HN. By the way, did you test with the new garbage collector? (Enabled by default in Mono 3.2.x)