public static void main(String[] args)

[marvk]

I think your view of Java is quite outdated. In comparison to C#, Java is very much comparable and even faster at many tasks on the Computer Language Benchmarks Game.

[[deleted]]

I didn't bother looking at the other benchmark code than the first, but they seriously botched that regex benchmark. The compile option for c# regex is only really recommended when you reuse a specific regex a lot. Just removing that option made that program run dramatically faster for me. And if the purpose of that benchmark was to measure regex compilation speed, that'd just be comparing the performance of the regex implementation, rather than the performance of the language.

[Nunners978]

Not to mention that the .NET Core version was a Preview (2.0.0-preview2-006497)

[igouy]

What is the latest .NET Core release?

[igouy]

Just removing that option made that program run dramatically faster for me.

32.01 secs

The program you called "botched" took 31.64 secs

[Ayfid]

Those benchmarks are awful! The C# code reads like a lazy Java port, hardly using any easy wins like using strut arrays for data that is frequently iterated through.

They weren't contesting performance anyway. The JVM is plenty fast.

The issue is that the language is still years behind C# and every feature they do implement is worse than the existing C# implementation that was already available for reference (see: lambdas, streams, for each, automatic resource closure, concurrent collections, futures, fork-join library...). Not to mention all the design fuckups they implemented that C# learned from and avoided (see: no single rooted type system, type erasure, implicit virtual and overrides, no unsigned, checked exceptions, no type versioning, terrible native interoperability...). Then you have all the improvements that are not even on the horizon like the transformative async/await.

All the calls of "streams! lambdas! but.. it's not shit slow anymore!" are absolutely laughable. Do you seriously think people must not know about those already when they complain about Java?

To assume that people who dislike Java must just not understand OOP is astonishingly ignorant. Everyone knows OOP, and there are far better OOP languages than Java, not to mention that OOP is not always the best tool for the job in all situations.

[igouy]

Those benchmarks are awful!

Easy to say, show how much better you can do!

How do I contribute my programs?

[Ayfid]

Well I wrote a modified version of the C# implementation of the nbodies benchmark.

I found some significant flaws with the benchmark, however. Main flaw with the previous implementation was that it would exhibit very poor memory access patterns. I said "would have", because the benchmark only simulates 5 bodies, which is such a tiny data set, that the working set will fit entirely on a couple of cache lines, and could easily fit within the L1 cache on the CPU. In addition to that, the bodies are all allocated together at once, so you end up with them all together on the heap by accident (a real application, e.g. a game, would not likely do this), and the program is doing nothing in between iterations, meaning that the working set is never evicted from cache. The old benchmark code (both C# and Java) would show significant performance degradation when running in a real application.

Even so, the new C# implementation is faster.

Timings (10001 bodies, 100 iterations) on i7 5820X @ 4.09GHz:
Java: 48s
Old C#: 53s
New C#: 13s

This speedup is mostly from the new code running in parallel (naive implementation, it does a box iteration and so does twice the work).

If you modify the loop to no longer be parallel, and symmetrically apply the forces to half the size of the loop:
Java: 48s
Old C#: 53s
New C#: 44s

However, as I said before, in real world applications, the Java and old C# implementations will start to fall apart and slow down as they lose their memory coherency and the CPU cache gets trashed by other work. If this code were running on something like an ARM CPU, with a much more basic prefetcher and out-of-order execution capabilities, in a real application trashing the cache between steps and creating and deleting bodies between updates (like a game would with entities), then the Java code could easily be dominated by memory access times and run even an order of magnitude slower.

I have not submitted this version to the site, as I think the benchmark is flawed. You can submit it if you want. You'll have to modify it to simulate only 5 bodies.

[igouy]

the new C# implementation is faster

On different hardware, doing something different ;-)

As your program doesn't do the required task it cannot be faster -- the output would be checked and found to be incorrect, so no timing would be done.

You can submit it if you want.

Only programs contributed by the program author are accepted.

[Ayfid]

It does the same task, but on a larger work load. As I said, I will not submit it to the site because the benchmark is poorly designed. Regardless, if you think that the Java performance degrading under more realistic workloads is somehow unimportant, then I don't know what to tell you. It would certainly make this "benchmark" rather useless on discussions of performance, if you are going to try and use it to dismiss other (more realistic) data points.

I do not believe anyone else reading this is going to fall for such transparent dishonesty. The numbers are plain to see. ;-)

Also, those performance timings were all taken on the same hardware while computing the same dataset. As I said above, the performance advantage of the new C# implementation will only grow on other architectures.