On 30 July 2013 00:23, Bert Freudenberg bert@freudenbergs.de wrote:
On 2013-07-29, at 23:59, Igor Stasenko siguctua@gmail.com wrote:
just a thought.. imo using identity hash field for instances of Float while probable, but in fact really impractical.
in that sense, what you think about removing filling the identity hash field and leave it always == 0.. saving some instructions to make float allocation a bit faster?
i am talking about genAllocFloatValue: dpreg into: resultReg scratchReg: scratch1 scratchReg: scratch2
IMHO, turning Floats into the only objects in the system that cause severe collisions in IdentitySets / Dictionaries should not be done lightly. It's a step away from "every object is equal" which I think is an important principle.
The VM should only "cheat without getting caught", as Dan put it. And there are options for that.
For example, the better our JIT gets, the less intermediate floats need to be allocated because you can avoid boxing/unboxing them altogether, so that's an even larger win.
And if we switched to immediate floats (e.g. in the 64 bit image format) the allocation issue would go away completely.
perhaps then it makes sense to also modify identityHash primitive to check if receiver is Float and use float value for it? Then there is no collisions/cheating, and little speedup in floats allocation? So identityHash primitive wear additional cost with checking that header is actually compactfloat. But given the amount of floats "floating around" :) comparing how often #identityHash is used, i think it is fair tradeoff.
I'm still curious: Assuming you tried it already, what kind of speedup do you get?
i did not tried.
- Bert -