r/programming • • 8d ago

Campfire port in Java is faster than Rust. Some thoughts about JEP 544 (AOT Code Compilation)

/r/java/comments/1x9s75g/campfire_port_in_java_is_faster_then_rust_some/
55 Upvotes

20 comments sorted by

74

u/renatoathaydes 8d ago

So much BS in that thread. I've measured Java VS Rust before. My bias was towards making Java as fast as possible. I also started with Java being faster, but that's almost certainly because the Rust code was extremely sub-optimal. If you measure optimal Java VS optimal Rust, you'll get Rust at least 3x faster, if you don't it's a great sign you're doing something wrong in your Rust code. In some very rare, very simple cases, Java may be almost as fast as Rust since the JIT ends up finding a hot path that can essentially be compiled to the same Assembly as Rust gives you from the start. But cases where the JIT can actually do something so smart that it's consistently faster are basically a myth that people have, for some reason, kept saying exist for the last 20 years but it just never holds after scrutiny. Here, I will take a $100 bet with anyone that that's the case too.

32

u/sweetno 8d ago

Please be more precise: how to deposit the bet, the clearing mechanism and conditions.

11

u/mikaball 8d ago

You're probably right on the Rust version being non optimized. But you are also underestimating the advantages of AOT, because...

Java may be almost as fast as Rust since the JIT ends up finding a hot path that can essentially be compiled to the same Assembly as Rust gives you from the start

This is not entirely correct. The AOT/JIT compiler can target the exact CPU architecture that may take advantage of specific CPU optimizations. As for Rust either you have to compile to the minimum common set of instructions or have multiple binaries for different targets.

It's possible to have Java with better assembly.

14

u/Restioson 8d ago

In any real program it's highly unlikely that the compiling for exactly the target CPU makes a difference on the order that's shown here. If you compiled the rust with --target-cpu=native it would probably get <5% perf improvement

→ More replies (4)

4

u/sweetno 7d ago

The idea is cool and I very much liked it in the SIMD context. However, as people out there told me, this is not what happens in practice. It's probably related to the fact that the JIT can't spend too much CPU on deliberating over ISA-specific instructions. There is a program to run out there, you know.

This Java port was discussed on r/java, and a lead Java architect pointed out that it's precisely the statistical profiling data that gives Java an edge.

→ More replies (2)

6

u/ketralnis 8d ago edited 8d ago

The thing is, if you’re an engineer this just doesn’t matter. If your code is fast enough, you’re fine. If your code isn’t fast enough you can microoptimise, or FFI out to rust, or C, or call your customer and ask them for more CPUs, or approximate, or rewrite in something else, or something. Lots of options.

It only matters if you’re a “Java programmer” or “rust programmer” whose identity depends on a language being “faster”. People who solve problems don’t worry about this language competition crap and get into arguments about it over the internet. The reason nonevangelists care about benchmarks is so that we can make those decisions towards problem solving but these intellectual children trying to justify never having learned a new tool after leaving school suck the air out of the room and distract with pissing contests

17

u/the_poope 8d ago

You are missing the point. The thread is not about which language does the job with adequate performance but comparison of the performance of AI generated code in different languages. So this os more of a benchmark of the AI model than the compiler. Apparently the AI model was not so good at generating optimal Rust code and the Java code is faster. It could be that Java is simpler to write and therefore easier for an AI agent to get right because there are fewer wrong ways to do the same thing. For instance it could be that the model makes unnecessary copies because it couldn't find other ways to get around the borrow checker.

→ More replies (1)

-3

u/raptor217 8d ago

That whole subreddit is a circle jerk.

3

u/sweetno 7d ago

That whole subreddit is a circle jerk.

FTFY

-8

u/vytah 8d ago

It really depends on what your data structures look like. It's not uncommon for Rust to grind to a halt because some destructor caused a cascade of cache misses.

13

u/vlakreeh 8d ago

Isn’t their point about comparing optimal Java vs optimal Rust? If it’s optimal then you wouldn’t have a struct with a drop impl that heavily impacts the cache hit rate.

7

u/colorfulchew 8d ago

It seems like more of a wholesale performance focused rewrite than a bones to bones comparison of Java run-times vs LLVM.

Might be interesting to ask an LLM to copy this implementation line for line with the same behaviors, like 10000 cached auth signatures, and tweaks to the SQL queries etc, it'd be a more interesting comparison. I think especially the benchmark-trained AOT would be interesting to compare to PGO+BOLT Rust code.