The optimizations you're talking about are the JIT compilation it does on bytecode. But really, Sun Microsystems didn't do JIT right. You have to remember that Java bytecode is essentially assembly language for a nonexistent machine. So basically, the JVM is an emulator. If you add a JITer to an emulator (in this case, the JVM), you should see no more than a ten percent decrease in speed relative to native code. This means that if I write a program... GenPrime, for instance, the Java version should be no more than 10% slower than a C/C++ version. I'll do some benchmarks today to demonstrate Java's grotesque speeds relative to native code. But I can tell you right now that the JVM is running more than 10% slower than native code. Easily.
No, C# is portable. Ever heard of Mono? What's not portable is Microsoft's .NET framework. So you can write using the Mono framework and it'll run as C# code on any platform. Also, have you ever tried the GCJ compiler? The code it generates is both massive and slow. Slower than Java running through the JVM, even.
Ooh. I hate the crappy buffer overflow argument. I always hear C# programmers use this argument. "Just wrap it in a string class and it's safe from buffer overflows!" Sure, that's true, but consider the overhead. I've gone into how C# does this. It first does some calls into MSIL code in the .NET Framework to do bounds checking of a memory copy or string copy or whatever operation is pending, and then goes into some native code and does a few more calls until it finally gets to the memcpy() routine in the native runtime.

But that's C#, so how does that reflect Java? Well, Java can't be much different. In fact, it can only be worse. The JVM itself is written mostly in Java. There are bits of native code to do the translation and dispatch of machine instructions, but for the most part, the JVM is written in Java. I've already established that they're not doing JITing properly, and their code is, as a result, slow. So what's worse here is that to do a simple string copy or other manipulation, it's going to be doing it all in Java code. Slow, slow, slow, slow.

The people that argue that Java is so "easy" to write sockets in don't realize that they really aren't writing sockets, nor are they learning what those sockets are doing underneath. A C++ socket class could easily be written to provide the same functionality (and there are in fact libraries that already provide such classes), and it'd be many magnitudes faster.

Performance is incredibly important. You have a processor with a certain clock frequency and certain features. You have memory with a certain latency. You have a hard drive with a certain seek time and read/write speed. You have a graphics card or chipset with certain amounts of memory and clock rates. In a game, you have to accomplish so much every 1/60th of a second or the game will suck.

Sorry, but I can't see Uplink/Onlink written in Java and running nearly as fast, nor as well-implemented as Onlink is.

Yeah, some of C#'s bound protected stuff is inefficient, but thanks to a well implemented hotspot JIT compiler, it tends to not lose much there, as something that involves checking boundaries will actually be recompiled "inline" if it gets called more than a couple times through the execution of the program. The beauty of a hotspot compiler is that it can do just that, it can identify as a program is used where to optimize it. The first 3 or 4 times you run the program, it might not run so fast, but after that, the thing gets going pretty smooth.

As to the Java defenses, you are about 2 versions late. Java 1.4.2 was the lastest "fast" version I am willing to concede, and even that one I think was starting to bloat. Java is not made to be efficient. It was WRITTEN for the purpose of being able to run on any machine, specifically for the purpose of being able to be viewed on smartphones same as on PCs. The problem here is that Java doesn't use a full JIT compilation though they brag about doing so. Instead they use a partial JIT compilation and a partial translation. They JIT for the heavier code and translate for everything else, including a large part of the Java API. AWT was attacked early on in Java for spending too much time in native routines. What could POSSIBLY be wrong with that? So Swing came out and was designed to be almost exclusively java classes with little to no time spent in native libraries. This of course means that not only are we now getting a slower wrapper around native graphics engines, we are getting an entire graphics engine that is compiled to some random byte code that then generates the basic forms to send to whatever underlying native graphics are there. Instead of taking advantage of already existing graphics routines, we are writing ones that can't possibly be as efficient and using those. .Net is actually compiled directly to native code to begin with, and only applications that run on top of it need JIT compilation or any form of translation (which Microsoft intelligently refuses to use). Meanwhile, Java continues to implement most of it's runtime as a partially translated, partially JIT'ed package. This cannot have the same performance as the exact same code run in say .Net.

Now as to the performance difference between .Net and native, I won't touch that. There is just too much attachment to native, some of it logical, some of it not, to get an accurate comparison. At this point, MSIL will always loose unless we sit here and benchmark it. In many cases will MSIL still lose after a benchmark? Sure. But the point is that it is capable of being as fast, and occasionally a little faster, than native.

Ah, but it might be better than vanilla Uplink. ;D

Well, yes. Well-written Java code could outperform vanilla Uplink. And that's scary.

I'm not contesting that Java is slower than native code -- of course it is. Every level of abstraction adds inefficiencies. I get that.

That said, I don't think it's too slow for a game such as Uplink. I never noticed any performance problems in the original Uplink -- not even in version 1.0. Maybe I just got lucky, but I tend to think that it's not a very demanding game, CPU-wise. (I have no knowledge of what the game does under the hood, as I've never seen the source. I'm just basing this on my observations over 5+ years of play.)

There's a difference between benchmark speed and speed of the resulting application. For any given number-crunching benchmark, Java will probably be destroyed by native code. No contest there. I fully expect that code running on a virtual machine will be eaten alive by equivalent C code, especially when that code is compiled with "-O2 -mtune=native". But for something like Uplink, exactly how many sqrt's per second you can do (or whatever) isn't all that critical -- what matters is the perceived performance. I use Eclipse daily, and have mucked about with its internals a fair bit. It's a pretty heavyweight Java app (I'd guess it's probably quite a bit heavier than a game like Uplink), yet its performance isn't all that bad. Is it slower than a native IDE? You bet. Does it use more memory? Yep. Does it feel too sluggish on a modern machine? Not really.

As for the quality of a Java implementation... well... that's entirely up the programmer. I've seen shitty Java apps, I've seen shitty C apps, and I've seen shitty C# apps. It's easier to write a crappy app in something like Java, as it can be much more forgiving -- but that doesn't mean that apps created with it are inherently more likely to suck.

I do know of Mono -- but as far as I know at the moment it's not a complete implementation. I guess I didn't count reverse-engineered implementations as "cross-platform support." I'm not a C# guy, so I don't know how much functionality it actually implements -- it might well be enough for an Uplink clone.

I do agree that games are probably best written in native code -- I'm just not convinced that Java would be nearly as poor a choice for an Uplink implementation as its made out to be.

For any programmer performs "well enough" should never be good enough. It should always be "Is the best go'rram program I can write to do this."

Java will never deliver that. C# may some day, and actually does in a couple specific areas (Especially in the area of like a server app which stays running for months at a time). The difference? C# Always ends up as native code. How that native code is defined relative to the native code the same program would produce in C++ is another topic (it really is a bit of a difference). Java rarely get's all the way to native code. Some of the Core API is "compiled to native" but very little executed code gets completely compiled. Seriously, you say you've gotten under the hood of Eclipse? Try getting under the hood of the JRE. It is not well implemented. It's fine for light weight applications that need to run in a browser. I've written my share of Java apps. I know what I'm talking about because I've used it, I've seen it's failings with my own eyes. I've had it shoved down my throat by a university. Seriously... Let it die.

Spot on! I had forgotten that C# has a precompilation technique (ngen.exe) that builds native code from MSIL. You are correct, C# could indeed end up being as fast as C++ someday if Microsoft or the Mono team focused heavily on optimization. The big issue is that Microsoft probably won't. I say this because their C/C++ compiler is terrible at optimizing. They basically removed the ability to target different processors (Pentium, Pentium Pro, Pentium III, etc), and instead force you to go with Pentium 4 optimization. And as a few of you are aware, the Pentium 4 requires very special optimization tricks which cause performance on older (and now, newer) P6-based processors to be hurt significantly.

Even if they decide to allow optimization for the P6 again, their focus has never really been optimization. I really think Microsoft's choosing the "It's good enough" path that they've chosen with so many of their products (Internet Explorer, Windows Vista, etc).

But Lassombra, while I certainly would love to see C# performing as well as natively compiled C/C++ code, I don't see it happening while Microsoft holds the reins.

We once performed a language benchmark on IRC, C# ended up being slower than PHP.

EDIT: My memory was mistaken :O:O, it was 3 times faster than PHP, and 43 times slower than C.

Just out of curiosity, was that a server or client? And which version of C# was that?