Hacker News Reader

Comment by kevingadd | Hacker News Reader

Structs and erasure-free generics definitely make C# faster in principle, but I don't think that's necessarily enough to overcome the huge amount of work that has gone into making the JVM JIT fast code and giving it a world-class garbage collector. I don't think it makes sense to assume that it would be faster for 'big data' use cases unless you've tested it.

Furthermore, I doubt straight-line execution performance is really the biggest concern when choosing a language to use for a task like this. You probably want to prioritize being able to find people who know the language - or, if you're using existing staff, you pick something they either know or can learn easily. C#'s not hard to learn but the odds are better that your typical CS graduate knows Java. In particular, if you want high performance, high performance C# isn't particularly easy to write - you'll have to know the language well, just like in any other environment.

View on HN

Memory usage trumps all other optimizations for tasks that use a lot of memory, which is to say for almost all tasks. C# (both Microsoft and Mono) uses a lot less memory than Java in principle and in practice.

Not having structured value types was the most consequential mistake in programming language design since 1970-01-01 00:00:00. It's probably the most important reason why Java never took off on the desktop and why C++ is still widely used.

Java never took off on the desktop because people had to download a large VM to run it. Now it doesn't matter but in the beginning it was a huge deal. Secondly most Java developers concentrated on Enterprise Java and could not write nice GUIs that performed well.

I don't think that's necessarily enough to overcome the huge amount of work that has gone into making the JVM JIT fast code and giving it a world-class garbage collector.

The CLR doesn't have a well-tuned JIT compiler and a fast garbage collector? Give .NET 4.5 a try -- it included some improvements to the garbage collector that were quite well-received (and the JIT was already quite good from .NET 4).

I didn't say that the CLR's collector is bad, I just said I doubt that MS has put enough energy into it to compete on an even footing with the technologies being used on the JVM.

Last I checked the JVM is more aggressive about inlining, can do escape analysis on reference types, and has a more scalable parallel collector. There are also alternative JVMs that go even further - Azul has a theoretically pauseless collector, which is certainly not something .NET offers (though pause times are pretty short for gen 1/2 collections, at least!)

The lack of aggressive inlining in many scenarios is arguably a big issue for .NET due to the more pervasive use of IEnumerable and properties, both of which add the overhead of additional method calls. In particular, when those additional method calls don't get inlined and you're passing structs around, each one involves a full copy of your struct, because the people designing the standard library didn't use 'ref' anywhere.

Simple properties are nearly always inlined, in my experience. But you're generally right about IEnumerable, for which the biggest culprit is LINQ. The problem is that the JIT doesn't inline across code which is referenced through a delegate, even though the actual method being invoked is the same each time. So code like "foo.Select(x => f1(x)).Where(x => f2(x)).Etc()" ends up making two function calls for every element in foo.

> So code like "foo.Select(x => f1(x)).Where(x => f2(x)).Etc()" ends up making two function calls for every element in foo.

Which is okay because Linq queries are easily refactored into proper classes and methods.

Make it fast then make it fast.

You're right. But honestly I'd like to see these improvements trickle down to Mono. There's 2 things big things that combined could change this trend - (1) performance enhancements like this for Mono and (2) a lot of work being done on MonoDevelop.

I've been doing my part to work on #2. I've sent in some improvements to VI mode (https://github.com/mono/monodevelop/pull/247) because I think it's critical to convince myself to work in MD. It also needs a lot of work on the debugger end. If we can successfully get people to work on Linux, C# might actually become prevalent.

Reply on news.ycombinator.com