“17× Faster On .NET Than The JVM”?
Don points to the latest F# Journal article, Allocationless programming on .NET. The article is interesting, but has a curious statement:
“filling a generic hash table with float keys mapped onto float values is 17× faster on .NET than the JVM.”
I think today a larger percentage of sell-side low latency architectures are built using Java than .NET – best guess, with no statistical data 
– and possibly a reverse position on the buy-side. Hence I’d prefer the article to clearly show what testing was undertaken to identify the 17x delta. Was the standard JVM used? What about JRockIt/Azul?
Advertisement
I expect it to be because Generics in Java are just syntactic sugar/compile time help, but in order to maintain compatibility with previous JVM the generic argument type is translated to “Object”. I think the correct term is “Type Erasure”.
Take this with a grain of salt being myself a .NET guy
I, too, would like to see more evidence. Yes, in generics in Java use type erasure whereas type bounds are erased and replaced with casts, but how is it relevant? I’d like to understand how zero-allocation hashtables work and specifically how buckets are implemented.
Sorry for my “half-baked” reply. Type erasure probably affects a lot as value types are being boxed into Objects and unboxed back. Also no optimization can be made by the Jitter.
That’s my understanding, more less the same as comparing .NET Generics with .NET non generic collections, let’s hope someone with skills in Java can reply
PS: If the performance gain is because of the “zero – allocation” strategy then the “17x performance” statement would be pretty bold.
It might not hurt to post this question to Stack Overflow. Jon Harrop responds to F# related questions there fairly regularly.
The complete benchmark and results were described in the following article:
http://fsharpnews.blogspot.com/2010/05/java-vs-f.html
The difference boils down to boxing caused by type erasure for generics on the JVM vs reification on .NET and the lack of value types on the JVM. This culminates in a huge amount of boxing on the JVM compared to no boxing at all on .NET. Boxing is a problem not only because it is an inefficient data representation but also because writing references to the young generation into the old generation violates the generational hypothesis, hammering the write barrier and giving pathological GC performance characteristics. Moreover, the JVM’s GC must then traverse O(n) references in the heap whereas the .NET GC has only one reference to traverse.
The workaround is to hand-reify generics on the JVM by creating custom hash table implementations for all combinations of key and value types. Suffice to say, that is obviously a massive waste of time.