[Vm-dev] Is it important to fill identity-hash for Floats?

Igor Stasenko siguctua at gmail.com
Mon Jul 29 22:41:17 UTC 2013


On 30 July 2013 00:23, Bert Freudenberg <bert at freudenbergs.de> wrote:
>
> On 2013-07-29, at 23:59, Igor Stasenko <siguctua at 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 -
>
>



-- 
Best regards,
Igor Stasenko.


More information about the Vm-dev mailing list