4 ms·

> The issue of primitive specialisation of generics is only tangentially related to type erasure, and run-time visible generics are actually much less useful th

by i_s 11y ago

> The issue of primitive specialisation of generics is only tangentially related to type erasure, and run-time visible generics are actually much less useful than Java folk wisdom insists. Run-time visible generics are pretty important because it lets us avoid boxing everything. In .NET, they don't have this problem, and as a result primitive dictionaries are ~17x faster [0]. Java folk wisdom seems pretty accurate to me in this case. [0] - http://fsharpnews.blogspot.com/2010/05/java-vs-f.html http://fsharpnews.blogspot.com/2010/05/java-vs-f.html

bad_user 11y ago
He's talking about reification versus specialization. The .NET runtime is specializing generics for value types and that's how you avoid boxing. For normal classes though, specialization would not have any benefit and the boxing argument goes away. Interestingly, specialization can be done at compile-time and doesn't necessarily have to be a runtime feature. Here's a Scala compiler plugin doing that: http://scala-miniboxing.org/ http://scala-miniboxing.org/
- masklinn 11y ago
  > He's talking about reification versus specialization. It's neither according to the usual (C++-inherited) lingo where specialisation is the userland override of generics reification. Refinement may be a better term for what the article is talking about (runtime-optimised instances without reified types). And refinements should already be doable in java today with no static type information, Pypy does it with list strategies, I expect Objective-C's hidden classes could also enable it (though I'm not aware of such a use). > Interestingly, specialization can be done at compile-time That's where they started...
hahainternet 11y ago
Did you read any of the comments? I did and I am certainly not qualified enough to know if the 17x faster claim holds up at all.
- i_s 11y ago
  I did now, and the only relevant retort I saw to this specific claim was that it is possible to work around it by using cern.colt.map.OpenIntDoubleHashMap (third party) instead of java.util.HashMap. So someone has worked around the problem by creating an implementation for a specific value type, but as the author explains, that comes with a big loss of genericity compared to the .NET solution.

by i_s 11y ago

bad_user 11y ago

He's talking about reification versus specialization. The .NET runtime is specializing generics for value types and that's how you avoid boxing. For normal classes though, specialization would not have any benefit and the boxing argument goes away. Interestingly, specialization can be done at compile-time and doesn't necessarily have to be a runtime feature. Here's a Scala compiler plugin doing that: http://scala-miniboxing.org/ http://scala-miniboxing.org/

masklinn 11y ago
> He's talking about reification versus specialization. It's neither according to the usual (C++-inherited) lingo where specialisation is the userland override of generics reification. Refinement may be a better term for what the article is talking about (runtime-optimised instances without reified types). And refinements should already be doable in java today with no static type information, Pypy does it with list strategies, I expect Objective-C's hidden classes could also enable it (though I'm not aware of such a use). > Interestingly, specialization can be done at compile-time That's where they started...

hahainternet 11y ago

Did you read any of the comments? I did and I am certainly not qualified enough to know if the 17x faster claim holds up at all.

i_s 11y ago
I did now, and the only relevant retort I saw to this specific claim was that it is possible to work around it by using cern.colt.map.OpenIntDoubleHashMap (third party) instead of java.util.HashMap. So someone has worked around the problem by creating an implementation for a specific value type, but as the author explains, that comes with a big loss of genericity compared to the .NET solution.