Hacker News Reader

Comment by LnxPrgr3 | Hacker News Reader

In theory Java can be more optimized than C—machine code generation benefits from knowledge of how the program actually executes. Just let the JIT figure out where you should've used C++ templates instead of dynamic runtime behavior.

In practice, it rarely happens even in micro-benchmarks like these. Though pointer aliasing rules are a special pain point. If you're sure you know what you're doing, restrict exists as a band-aid over this. Yay archaic language baggage!

LLVM's optimizer also doesn't help, as the post mentions—I have real-world code that runs at 1/3rd the speed just from compiling with clang instead of gcc. I love LLVM for what it's let people build on top of it, but it isn't remotely state-of-the-art in this department.

View on HN

> In theory Java can be more optimized than C—machine code generation benefits from knowledge of how the program actually executes.

I used to believe this, but I think the same level of theory that says a JIT can be sufficiently smart enough to figure everything out means that a compiler can be sufficiently smart enough to figure everything out as well. This is one of those areas that theory and practice are so far apart that theory should be accompanied with a context of "some day, in the future, if we're lucky..."

What we've seen in reality is that as JIT engines get better, compilers also get better, and retain their lead.

This is true. Compilers even sometimes act vaguely like JIT—see also speculative devirtualization. If your code really needs runtime profiling information to optimize well, we have profile-guided optimization too.

In theory your could still benefit from JIT if, say, you have a Java application that's half written in XML config files and always heavily customized for each deployment. But probably that application also needs 8 modern cores and 16GB RAM to start for reasons that aren't even Java's fault.

But I try not to write code like that.

No, even in theory there's an advantage to having information only available at runtime. Some optimizations depend on the probability distribution of data coming in (eg. an optimization for a CSV parser that makes it faster when dealing with well-formed CSVs that would slow the program down if it starts getting a lot of mis-formatted CSVs). The compiler can choose one or the other, but not both. The JVM can effectively choose both by deciding during execution.

If the compiler is allowed to embed a JIT or other runtime system, then all bets are off.

Yes I'm beginning to realize this. The number of tricks I had to use to convince llvm to optimize, when my c++ version just needed __restrict__ was disappointing. Likewise gfortran is way behind ifort.

Reply on news.ycombinator.com