Hacker News Reader

Comment by _old_dude_ | Hacker News Reader

I expect Java to be slower, Optional was introduced as an afterthought not as a native construct like in Rust.

Sadly, the two benchmarks are not equivalent, the Rust version loop over ints, the Java version loop over longs.

Looping over longs is notoriously slow in Java, because there is no vectorisation and the JIT insert insert a GC checks because looping over longs may take a long of time.

Also one of the codes uses Optional<Long> instead of OptionalLong, so the code does a double boxing long -> Long -> OptionalLong.

View on HN

Rust doesn't have types named 'int' and 'long' out of the box. It does have types named e.g. i32, i64, u32 and u64.

Because the function get_int() takes a u64, Rust will conclude that the variable i must be a u64 so as to fit in that parameter.

It seems to me that "Java is bad at 64-bit integers" is also useful information but not pertinent to this benchmark, unless you assume it's trying to compare Java to Rust, at which of course Java will be far slower - but I don't think that's the point of the benchmark at all.

The Rust version iterates over u64, which is the same size as Java long, though it’s unsigned whereas Java long is signed.

> Sadly, the two benchmarks are not equivalent, the Rust version loop over ints, the Java version loop over longs.

I thought longs were 64 bit signed integers in Java, what's the difference with a u64 in Rust? Is it the signedness that affects performance?

> OptionalLong

Thanks for the info! I didn't know there were Optional primitive types in Java!

Well, it's not exactly a primitive (long) and instead it is an Object (Long), but I understand what you mean :)

OptionalLong is an object which optionally contains a value type (lowercase L) long. Optional<Long> is an object Optional which optionally contains an object Long.

Oh nice! I should have checked the docs or Intellij to see that it returns the primitive type ;)

Reply on news.ycombinator.com