Optional is being being converted to a value class as part of Project Valhalla.
I reran the benchmarks with the latest Valhalla branch [1] and added a test that used OptionalLong instead of Optional<Long>.<p>Without Valhalla<p>- OptionBenchmark.sumSimple avgt 5 328,110 us/op<p>- OptionBenchmark.sumNulls avgt 5 570,800 us/op<p>- OptionBenchmark.sumOptional avgt 5 2223,887 us/op<p>- OptionBenchmark.sumOptionalLong avgt 5 1201,987 us/op<p>With Valhalla<p>- OptionBenchmark.sumSimpleValhalla avgt 5 327,927 us/op<p>- OptionBenchmark.sumNullsValhalla avgt 5 584,967 us/op<p>- OptionBenchmark.sumOptionalValhalla avgt 5 572,833 us/op<p>- OptionBenchmark.sumOptionalLongValhalla avgt 5 326,949 us/op<p>OptionalLong is now as fast as simple sum. And SumOptional is now as fast as SumNulls. So the overhead of using OptionalLong and Optional<Long> seems to have gone away with Valhalla.<p>It would be great if boxing could be eliminated as well. But few people writes code like what is being benchmarked (in hot loops) in practice.<p>[1] <a href="https://github.com/openjdk/valhalla">https://github.com/openjdk/valhalla</a>
I think in general these types of benchmarks makes boxed numbers look bad only because they're being compared to <i>adding integers</i>, which is a ridiculously fast operation to start with. Accomplishing half that speed despite "dereferencing a pointer" is kinda insane in the light of 'Latency Numbers Every Programmer Should Know'.<p>(The reason it works is because Java doesn't actually allocate new Longs for small numbers, it fetches them from a table of constants; it's always the same 256 objects that are being dereferenced. I don't know their memory layout, but I'd half expect them to be sequential in memory as that's would be much a low hanging fruit optimization. Optional<Long>'s performance is what you'd expect without these optimizations. Also in this scenario you really should use OptionalLong instead of Optional<Long> but that's beside the point ;-)
I think part of the problem is that Java’s Optional isn’t a<p><pre><code> Either[null, T]
</code></pre>
but a<p><pre><code> Either[null, boxed T, boxed null]
</code></pre>
‘Boxed null’ is what the documentation (<a href="https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html" rel="nofollow">https://docs.oracle.com/javase/8/docs/api/java/util/Optional...</a>) calls “an empty Optional”<p>That means that, for example, an <i>Optional[Byte]</i> can have 258 different values and cannot, in general, be compiled to a ”pointer to byte” because that has only 257 different values.<p>Edit: reading <a href="https://news.ycombinator.com/item?id=35133241" rel="nofollow">https://news.ycombinator.com/item?id=35133241</a>, the plan is to change that. I fear that, by the time they get around to that, lots of code will handle the cases <i>null</i> and <i>Optional containing null</i> differently, making that a breaking change.
> A special “I would never write Rust like that” variant that returns the value in a Box on the heap. This is because a friend of mine, after seeing my results, told me I was cheating, because all Rust versions so far used registers/stack to return the value, and Java was at a disadvantage due to returning on the heap (by default). So here you are.<p>Why would Rust be cheating here? Java cannot make these types of optimizations yet (though they are likely coming with Project Valhalla) but that doesn't mean Rust should be similarly handicapped in benchmarks.<p>Java has many smart optimizations and advantages over Rust (being garbage collected for one, making it much easier to write code in, and runtime reflection, a blessing and a curse) and with tricks like rearranging objects to make more effective use of CPU caches you can end up writing Java that's very close in performance to native, precompiled code.<p>However, when it comes to raw performance, you shouldn't expect the standard JVM to come close to Rust. There is inherent overhead in the way the language and the runtime are designed. There is no "cheating" here, the algorithms are the same and some languages just produce more efficient code in these scenarios. You wouldn't slow down the JVM to make the benchmark fair for a Python implementation either!<p>A more interesting comparison may be compiling Java to native assembly (through Graal for example) so Java too can take advantage of not having to deal with reflection and using SIMD instructions.<p>Alternatively, a Java vs C# rundown would also be more interesting, as both languages serve similar purposes and solve similar problems. C#'s language-based approach to optional values has the potential to be a lot faster than Java's OOM-based approach but by how much remains to be seen.<p>Java vs Kotlin may also be interesting to benchmark to see if the Kotlin compiler can produce faster code than Java's Optional; both run inside the same JVM so the comparison may be even better.
Rust has an interesting optimization for Option<T> when T has enough "room" for encoding a marker for "None": <a href="https://google.github.io/comprehensive-rust/std/box-niche.html" rel="nofollow">https://google.github.io/comprehensive-rust/std/box-niche.ht...</a><p>e.g. Option<NonZeroU64> is effectively encoded and operated on as u64, but it gives the type system a way to make sure you correctly handle the case where "0" means something special for you
The issue will probably be solved this year with value types in Java.
<a href="https://openjdk.org/jeps/8277163" rel="nofollow">https://openjdk.org/jeps/8277163</a>,
<a href="https://www.baeldung.com/java-valhalla-project" rel="nofollow">https://www.baeldung.com/java-valhalla-project</a>,
<a href="https://blogs.oracle.com/javamagazine/post/java-jdk-18-evolution-valhalla-panama-loom-amber" rel="nofollow">https://blogs.oracle.com/javamagazine/post/java-jdk-18-evolu...</a>
The rust NonZeroU64 solution has a subtle 'bug' that happens not to matter.<p>The function<p><pre><code> fn get_optional_non_zero(n: u64) -> Option<NonZeroU64>
let i = n & 0xFF;
if i == MAGIC { None } else { NonZeroU64::new(i) }
}
</code></pre>
Actually returns None for n = 0 or n is any multiple of 256.<p>The resulting usage in the sum still yields the same result, because skipping zeros in an addition doesn't matter, but it is a subtle difference between this get-function compared to all of the others. It also doubles the number of None cases the code needs to handle.
> A special “I would never write Rust like that” variant that returns the value in a Box on the heap. This is because a friend of mine, after seeing my results, told me I was cheating, because all Rust versions so far used registers/stack to return the value, and Java was at a disadvantage due to returning on the heap (by default).
Uhh, okay? This sounds a bit silly to me. It's good to add the additional comparison, sure, but "cheating" is just not the right word. The point of this article is ostensibly to compare the built-in Option types, not heap allocation. The fact that Java allocates any Options on the heap is part of that comparison (and reflects badly on Java, fwiw).<p>Either way, glad to see that Rust is doing a good job eliminating the overhead. I'm not sure if arithmetic is the right kind of benchmark here, but it'd probably be difficult to measure the performance overhead across "real" codebases, so focusing on a tight loop microbenchmark is probably fine.
Handling nulls by wrapping references in Optionals (at least if they can't be optimised away) is IMO strictly inferior to static analysis by the compiler as in Kotlin and forcing correct error handling. Its really all you need! The problem is not nullable references, after all Optionals can contain nulls, the problem is documenting if a value can be null via the type system and correctly handling those cases.<p>Hoping Java will get this one day, but probably not...
My guess is that C# will be much better, since it has support for Value types.<p>Wasn't Java supposed to get support for Value types some time ago?
Why is the author talking about null in the intro, which implied using pointers and thus boxed objects and then running benchmarks on integers? That makes no sense to me.
Note that Java’s <i>Optional</i> was never intended to be a general-purpose Maybe type or general-purpose replacement for <i>null</i>, unlike Rust’s <i>option</i>. As Brian Goetz explains in <a href="https://stackoverflow.com/a/26328555/623763" rel="nofollow">https://stackoverflow.com/a/26328555/623763</a>:<p>“<i>Our intention was to provide a limited mechanism for library method return types where there needed to be a clear way to represent "no result", and using null for such was overwhelmingly likely to cause errors.<p>For example, you probably should never use it for something that returns an array of results, or a list of results; instead return an empty array or list. You should almost never use it as a field of something or a method parameter.<p>I think routinely using it as a return value for getters would definitely be over-use.</i>”
It’s interesting to see how different languages deal with nulls and similar constructs.<p>In some languages like TS, PHP or Kotlin have proper unions that you just handle with branching.<p>Rust lets you pattern match againt a construct that holds a value or doesn’t. Option is an actual thing there that you need to unpack in order to look inside.<p>In Clojure nils are everywhere. They tell you that “you’re done” in an eager recursion, or that a map doesn’t have something etc. Many functions return something or nil, and depending on what you’re doing you care about the value vs the logical implication.<p>nils flow naturally through your program and it’s not something you are worried about, as many functions do nil punning. Well as long as you don’t directly deal with Java - then you have to be more careful.
Interesting.<p>This article resonate in me with the recent articles of Casey Muratori about non-pessimistic code:<p>Within the realm of the module, don't use pessimistic code (avoid Boxing) _but_ that doesn't prevent you to provide a safe API. E.g. the result of the loop could be wrapped if that made sense.