Hacker News Reader

Comment by foobarian | Hacker News Reader

The problem is that different languages do different things at runtime and this is part of the definition of the language. C has almost no runtime, while the JVM is allowed to recompile code at runtime using profiling data it has collected that very run. This is how it can beat C in certain workloads.

View on HN

But...since Java was(maybe still is) written in C, one could literally write the Java runtime and do the exact same things...in C.

I know it's a pedantic point, but one I stand by...that there's literally nothing Java can do that C cannot because C can write Java!

Theoretical max performance is different from actual performance - and since all code on a given machine ends up in machine code all languages are the same speed - which is obviously false.

Agreed. I should have added to my initial post that I think language speed comparisons are absolutely stupid for the reasons I mentioned.

I don't go around saying C is faster than Java. I just say Java cannot be faster than C.

But not all languages emit the same machine code. And I think performance is more sensitive to memory access than machine instructions, so I don't think this point is true.

The point is that a language can be faster than the language it is written in - all or for the most part - depending on how it is used. Saying "the theoretical performance of Java can never be faster than the theoretical performance of C" is a tautology and pretty useless - especially if in practice the Java libraries handle normal operations better than the average C programmer.

Okay big guy, show us your implementation of the JVM and we'll talk.

If I write an assembler in C, I could use it to write object files with fancy machine code that the C compiler would never choose. Same with HotSpot, it’s not limited by the code generator it was bootstrapped from.

But you see, you could use asm to then write a C that generates fancy machine code.

“Does my C compiler generate better code than HotSpot?” is a different question than “could I conceivably write a better code generator from scratch, in any language?”

This seems a bit wrong-headed. All code ultimately runs CPU instructions, regardless of the language a program is written in. It doesn’t matter if the Java compiler or runtime is written in C, because CPUs don’t run C. The Java bytecode compiler might be written in C, but it ultimately emits CPU instructions.

When talking about performance you say that “there's literally nothing Java can do that C cannot because C can write Java” but other than the tautology that they are both Turing machines, your conclusion doesn’t follow.

The Java runtime dynamically optimises based on the currently executing code, but C compiles to static CPU instructions. A C program is statically optimised so it’s possible that some optimisations in C will perform worse than those in Java because Java knows more about the actual code paths taken at runtime, and this can change between executions.

For C to be able to optimise itself the same way that Java does, it would need its own heavyweight runtime and bytecode, like Java does (as I think you suggest). But C doesn’t actually have such a runtime, and although I’m certainly no expert on the C language spec, I assume it has all sorts of runtime guarantees and a memory model that would preclude arbitrarily rearranging the executable code at runtime, so it arguable that the resulting system wouldn’t actually be “C” if it did this.

Put another way: although Java is/was written in C, the way Java works is fundamentally different to C, and because of this, certain optimisations are available to Java that are not available to C.

(All of that said, in my experience C code is always faster than Java code, these days I use Go and Swift, and I’m very happy to have seen the back of the JVM.)

This is what I used to think about JIT as well. That JIT would have more information than a static compiler to optimise the code better. However, it seems to me that most of the performance depends on how well we can exploit the cache lines and how many fewer instructions the cpu has to execute to get the job done. JIT could perhaps improve on the latter but in many cases it seems to me that it's generally very hard to be cache aware when programming in Java not to mention every user-defined type is allocated on heap. So, I feel like it's quite unlikely that there can be Java programs that outperform C and even then that it can't in principle be done better in C.

Actually, Java gets ridiculously close to C performance when you only do computations on primitives. Of course you do have some pointer chasing in most code bases but in my experience cache is mostly relevant for repetitive workloads. I’m not sure that a typical web application would win all that much from a C rewrite.

Yeah I don’t disagree with you, I was really trying to dispel the idea that somehow the implementation language puts an upper limit on the performance of the implemented language.

So, consider a perfectly spherical Java language… :)

Java is not being rewritten to C though. It is being rewritten to assembly (by a C++ program).

----

Also, by the same argument you're using, git should be faster if written in assembly; since assembly can do more than C can.

The tradeoff between performance and easiness to write the program has already been made by writing git in C. The only difference in using Java is a different point in that tradeoff.

I'd also contend that Java gives you much more bang for the buck in that tradeoff than C. Java is stupidly easy to write, especially if you want to do multithreading. With C you'd have to start writing some form of primitive GC, or have the disciplined paranoia of Rust's borrow checker yourself.

yeah you could, but nobody will ever actually do that, will they?

Ok I see. I still find that this kind of argument relies on hidden assumptions. By this argument we are saying that Java doesn't actually exist, and it's all C with a fancy DSL. :-)

You could maybe write some kind of translator in C to emit JVM bytecode, and have it recompile itself at runtime. The problem with that line is that it is a lot of work and then to be fair we should allow a similar effort to be applied to a JVM like HotSpot for an apples-to-apples comparison.

Then remember the original thesis, which is that we claimed Java was only faster for specific usecases. That is a very wiggly claim that I bet could nearly always be found true.

Anyway, fun to think about either way.

Reply on news.ycombinator.com