The Ghost of Christmas Future, II

[loftar]

what about these forums

Haha, well, I didn't write them myself, after all, and there is a reason why I don't modify them much. :)

[romovs]

• Has the better JIT,

N'est ce pas?

Huh? Both C# and Java have near identical performance (some things perform marginally better in C# others in Java). The superiority of one JIT over the other is not so obvious.

• Has a Linux implementation that doesn't suck, and
• Has an ecosystem that isn't Windows-centric.

The situation is finally bound to change in the very near future.
MS has open-sourced a lot of core components from the .NET framework (including the CLR, Web & ORM frameworks, build tools, etc.) and significant effort is being put into cross-platforming everything.
Mono has already started integrating the CoreCLR into their implementation, misc. .NET components will support Linux & OSX starting from the next release, and a cross-platform IDE preview has been released as well.

[loftar]

Huh? Both C# and Java have near identical performance (some things perform marginally better in C# others in Java). The superiority of one JIT over the other is not so

I guess we can both start cherry-picking benchmarks to prove the other wrong, but this and this appear to show Hotspot being fairly much better. Admittedly, the first one is Mono rather than MS .Net, but it is my understanding that they are comparable in performance these days. In the second one, Java on Linux is beating .Net by a fair margin, while .Net is beating Java on Windows by a fair margin. I'm guessing this is because their Java on Windows benchmark uses the client JIT, which noone should ever use (but 32-bit Java on Windows defaults to it).

This also meshes with my theoretical understanding of the two compilers, as the .Net JIT apparently can't even do dynamic decompilation. Makes one wonder what the point even was of using a JIT to begin with.

The situation is finally bound to change in the very near future.

That's fairly irrelevant, however, since the client is already written. I'm not going to rewrite it to another language which is basically the same thing anyway. :)

[romovs]

Admittedly, the first one is Mono rather than MS .Net, but it is my understanding that they are comparable in performance these days.

Mono always under-performed .NET implementation. Not sure about JIT but GC in Mono sucks in comparison to .NET, floating point operations are slower, string operations.
It would be interesting to see those benchmark's against .NET. I suspect the difference would be very minimal, similarly to the second .NET vs Java benchmark in your post.
Although now that I am thinking about it, how can you even quantify JIT performance in real world unless it's really utterly broken? There are tons of other things at play and differences in those benchmarks could be easily attributed to: Java allocates memory faster (at the expense of higher memory usage) so it makes sense for certain algorithms to execute faster there, C# .NET performs better when it comes to certain operation on collections, and plethora of other things unrelated to JIT...
Uh I guess you need to really dig into their JIT implementations in order to come with some sort of educated answer regarding JIT performance and I am way to lazy for that. Hence I'm maintaining my original position - they both equal in performance.

That's fairly irrelevant, however, since the client is already written. I'm not going to rewrite it to another language which is basically the same thing anyway.

Nah I was just putting it there for whomever might be interested in C#. Although would love if the client was written in C# Some of the Java lang features make me cry sometimes.

[windmaker]

this guys dont know the beauty of Ruby.

[loftar]

the difference would be very minimal, similarly to the second .NET vs Java benchmark in your post.

You mean that benchmark where Hotspot was consistently beating .Net by anywhere from 1.4× to 2.5× in all but one benchmark? :)

Uh I guess you need to really dig into their JIT implementations in order to come with some sort of educated answer regarding JIT performance

Was my statement on deoptimization not enough "digging" for you?

Some of the Java lang features make me cry sometimes.

In my mind, the "features" of both of those languages are pretty much the same to me. They both make me cry. Please don't interpret me as preferring or in any way liking Java as a language. As I said earlier, it just has a fairly nice runtime.

this guys dont know the beauty of Ruby.

I consider Ruby, Python, Perl, Lua &c&c to be pretty much the same language as well. I consider them to be the "we don't care about performance anyway, so we can invent whatever abstractions we like and yet kindasorta fail to do so anyway" group. Not that I dislike them or anything, and I enjoy writing in Python. I just don't find them particularly interesting from a "linguistics" point of view.

[romovs]

the difference would be very minimal, similarly to the second .NET vs Java benchmark in your post.

You mean that benchmark where Hotspot was consistently beating .Net by anywhere from 1.4× to 2.5× in all but one benchmark?

Are we referring to same benchmarks? In this one C# .NET beats Java in 6 out of 9 cases as far as I can see. Although it is 3am already and my retard mode might have kicked in so it's possible I am overlooking something...

Was my statement on deoptimization not enough "digging" for you?

It's wasn't. I presume JIT performance isn't determined merely by one feature or lack of thereof.
I am not familiar enough with CLR's JIT nor HotSpot's JIT, hence I was referring more about me digging into and not you
but lack of runtime profiling capability in CLR's JIT and as consequence lack of de-optimization doesn't seem like a flaw OR can be used to conclude with certainty that one is better than the other. CLR doesn't have de-optimization yet it performs equally well to HotSpot. So yeah perhaps it doesn't make much difference or perhaps CLR JIT excels in other things which negate this horrible lack of de-optimizer. I frankly still can't see how HotSpot JIT design is better than that of CLR. Maybe it is, maybe it isn't. On the surface both seem to perform on equal levels.

[loftar]

Are we referring to same benchmarks? In this one C# .NET beats Java in 6 out of 9 cases as far as I can see. Although it is 3am already and my retard mode might have kicked in so it's possible I am overlooking something...

In the second one, Java on Linux is beating .Net by a fair margin, while .Net is beating Java on Windows by a fair margin. I'm guessing this is because their Java on Windows benchmark uses the client JIT, which noone should ever use (but 32-bit Java on Windows defaults to it).

It's wasn't. I presume JIT performance isn't determined merely by one feature or lack of thereof.

Ah, well, the point about deoptimization is that it's the single underpinning of a whole plethora of optimization features. Only given that Hotspot can deoptimize, can it do such optimizations as currently monomorphic method inlining, interface devirtualization, null-check elimination, type-check elimination, killing of unlikely branches, and other such optimizations that depend on assumptions that are likely but cannot be strictly proven, especially in the face of dynamic code loading. Profile-guided reoptimization is just one small special case of all that. In fact, while I haven't seen the source code for the benchmarks I linked, I suspect (from their names) that most of them are fairly generous to .Net in being mostly numeric, whereas these kinds of optimizations shine much more on more "object-oriented" code.

On the surface both seem to perform on equal levels.

I do have to say that, "on the surface", Hotspot generally seems to perform better, and as I continue to Google for performance comparisons, I continue to get that general impression.

Either way, I dunno; the speed argument wasn't that important to me, and I don't doubt that .Net isn't slower by an order of magnitude, at least (not that it doesn't matter for a game engine, though). The argument about being more well-defined was the most important to me. (Not to mention that I once tried installing Mono, and it installed files with ".exe" and ".dll" names. That gave me such a sour after-taste that I haven't wanted to even look at it since.)

[MagicManICT]

In particular, I consider myself first and foremost to be using the Java VM before I'm using the Java language, and if I were to be using C#, I would likewise consider myself to be using the CLR rather than C# itself, and the JVM just seems to be so much better documented and defined than the CLR. I've still to find even a reasonable overview of the latter -- precisely like all other Microsoft tech that "isn't meant to be used directly", it seems to be quite obscure and hard to get at.

The Java VM was designed to be more or less open for any hardware vendor that wanted to adapt it to their processor/system, which is why you can find embedded Java in all kinds of devices, like DVD players, vending machines, etc. (I think Oracle would roll that one back if they could....) I don't think Microsoft intends on .Net being used with anything other than an MS implementation, though, so why does anyone need to know those kinds of details?

@YarPirate: there are plenty tools out there to reverse engineer software ran through an obfuscator. They don't get you the original code, but from what I've seen of them, it gets you workable code, and you don't need to know machine language. (If you can read that, all you need is a hex editor.)

[Myzreal]

Generally, my opinion of Java is that the VM is pretty nice (though it's not as if I couldn't find things to complain about if you wanted me to), but that the language sucks.

The language has gotten much better since Java 8. Any particular complaints?

@YarPirate: there are plenty tools out there to reverse engineer software ran through an obfuscator.

Obfuscation does nothing if someone can read assembly, and most of the "bad guys" do.

@loftar
Do you guys care to share any insight about how is the architecture achieved to support such a large world or is that a top-secret? I'm interested in world generation and large, open worlds. I'd link to my terrain generator but it was made a long time ago and it's utter trash, so I won't