This is the first of a series of three blog posts, with quite an interesting conclusion in the final post[1]:<p>> On my 2012 desktop workstation with 3GHz Xeon W3550, the Java benchmark reports an average of 7.3 ns per getTransformed invocation. The Rust benchmark reports 128 ns in get_transformed, a whopping 17 times slower execution. [...]<p>This article was written five years ago and things may have changed for better or for worse. However, this is an obvious example of how using Rust can make your code slower: by making you implement all the nitty-gritty details yourself (i.e. multi-threaded locking mechanisms), getting everything right and up to speed is left up to you rather than to the standard library, like in Java, where dedicated people have been improving their solution to this problem for decades now.<p>Rust can be lightning fast compared to Java but it's worth considering using the "slower" alternative for certain workloads (in this case, many cross-thread operations) to get a performance benefit. All the talk about Rust's fearless multithreading does not necessarily make it a good language, merely a less correctness-bug-prone alternative to C++!<p>I've run the benchmarks on my machine with an up-to-date Rust install; to prevent library bugs, I've also upgraded Rusts's dependencies to the highest level they'll go. For the Java samples, I'm running Java 18 with the default GC (haven't set up 19 yet on my machine).<p>The results are kind of wild. On the Rust side, the consumers take 46-70ns/op on my machine while the producer takes 400-800ns/op. When I run the Java benchmark, the consumers take a mere 4.71-12.24ns/op (10-65x faster!) but the producer takes a whopping 15486-25810ns/op, 40-368x slower! I've run the benchmark on Java 8 and there the performance for consumers is even better (3.4-6.4ns/op) but the producers continue to be incredibly slow.<p>I'm not sure what's causing this massive difference in performance (the comments on the article suggest that the producing code is triggering GC, which might very well explain the difference) but it's an interesting result to note.<p>I'm sure Java experts and Rust experts will both have suggestions about optimizing this code further to make the samples go faster, of course. Rust's multithreaded workloads _can_ be a lot faster (the prime drag race proves that [2]) but I don't think that's the point of this benchmark.<p>[1] <a href="https://morestina.net/blog/784/exploring-lock-free-rust-3-crossbeam" rel="nofollow">https://morestina.net/blog/784/exploring-lock-free-rust-3-cr...</a><p>[2] <a href="https://plummerssoftwarellc.github.io/PrimeView/report?id=1997&hi=False&hf=False&hp=False&fi=java~rust&fp=st&fa=&ff=uf&fb=&tp=False&sc=pp&sd=True" rel="nofollow">https://plummerssoftwarellc.github.io/PrimeView/report?id=19...</a>