Hi John,

> What I found is that for the 2 at 3 benchmark I see
> 3.5.2b1  -> 164,850 alloc/sec
> Nofill,hashTable -> 172,998
> NoFill,NoHash -> 182,455
> 
> for the 1 asFloat
> 3.5.2b1  -> 124,870
> Nofill,hashTable -> 136,103
> NoFill,NoHash ->  137,669
> 
> The 1 asFloat is interesting because both "after" benchmarks 
> are close.

Strange. Considering that Float and Point are both compact, both 12bytes
large, I really wonder where this may come from.

> However what I do see is that I trade some shifts &
> multiplication/addition for a calculation for the  
> hasharray base & index and a load from memory for
> the values.  However that the number is 5-9% better than when 
> I started.

Interesting. I was aware that the load might hurt us but it seems that in
general it still improves matters slightly. I would expect the situation to
be slightly better on Intel but I haven't tested it.

> I'm of course curious about it's effect on machines where  
> multiplication isn't a one cycle operation, and it isn't done in  
> parallel with integer, also of course how it behaves on x86.

My guess is that the hash array change will benefit Intel slightly more than
PPC, but I'll wait and see ;-)

> Also, here are some macro numbers below. Most likely all 
> three within the range of error.

Thanks. I can't spot anything that indicates that there's a significant
improvement in general (not that surprising though I had hoped that we may
get a percent or two out of them).

Cheers,
  - Andreas