HashBits, a lazy way

John M McIntosh johnmci at mac.com
Fri Jul 11 07:51:51 UTC 2003


> From:   Ned Konz < ned at b... >
> Date:   Fri Jul 11, 2003  5:00 am
> Subject:   Re: HashBits, a lazy way
>
>
> ADVERTISEMENT
>
> On Thursday 10 July 2003 08:45 pm, Andres Valloud wrote:
> > I don't understand. On one hand, the identity hash bits are in the
> > header so that access is super fast when they're needed (e.g.
> > method lookup). On the other hand, adding a conditional branch
> > seems like it will slow down every single access. ???... does that
> > pay more than calculating/storing identity hashes for all objects?
>
> No, he's saying that we don't need hash bits most of the time for most
> objects, so why bother to compute them?
>
> Doing a comparison with 0 on the hash (when asked for the hash) is
> very cheap. Computing the hash is not.
>
> In the case of symbols, we could skip the test if we could quickly
> tell if something were a symbol. I don't know if we have a flag bit
> for these. We could always compute the hash for symbols.
>
> --  
> Ned Konz

Well some/most smart CPUs can set a condition flag when you load a word  
to indicate if the word is
zero or not, so the test cost is free, and perhaps the branch test can  
get hidden.

But really as Ned points out the number of objects allocated, versus  
the number that actually uses
the idenityHash is what is of interest here.

So if I repeat a zillion times, 100 allocations of Object new in a  
while block.

The  time taken is 17% faster based on clock time for the deferred-hash  
case.
Not bad considering allocation is only 20ish % of total cycles.

In doing this I looked at
instantiateClass:indexableSize:doFill: &
allocate:headerSize:h1:h2:h3doFill:with:
and decided they are way too generalized. So I've been rewritting them  
to reduce the number of testing going on,
and streamline the execute paths based on type of object being  
allocated. Right now I've managed to bust
everything, but hope to reassemble it in a few hours then report on the  
results.

--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===


More information about the Squeak-dev mailing list