I wrote the algorithm that is there to sort the variables based on  
usage since I couldn't come up
with a nicer metric, because as you thought cache line placement could  
be important. 8 years back (or so)
it wasn't important, now it is, we noticed a 2% gain in a VM build by  
adding a single instance variable, which
changed placement of other variables on a cache line.

Hand sorting couldn't hurt, didn't want to do that at the time.

Isn't everything Intel now anyway? Alas...

The other magic that is lurking btw is if you shared a global between  
different routines and this variable(s) become
part of a sole routine after the merging of methods and inlining is  
done then the variable is moved out of the foo structure
and made a local.  There is a method where you can deny that behavior  
for a variable/routine if I remember.

The *most* important place this was effective in was the GC logic.   
The GC logic is split between various smalltalk methods, which
all get inlined together. So on the powerpc those globals sharing  
state between the 4-5 routines would all become local register variables
made quite a different in performance.

Andreas made a change a few years back to change scoping of local  
variables to the block they are used in, versus defining the locals
at the top level of the routine, that help register allocation.

Lastly I've a change set, well somewhere, that would extrude slang and  
say void foobar{} if in fact method foobar didn't actually return  
anything.
This was never accepted because we found certain methods in the  
VMMachine defs would return values, but in fact actually didn't return  
values.
however one can never tell what the compiler will do given int  
foobar{} versus void foobar{}


On Feb 28, 2008, at 8:34 PM, Igor Stasenko wrote:

> I just wondering, what if i place variables in interpreter struct in
> specific order,
> not in order, which code generator produces.
>
> Since speed impact expected to be very small (if any), i used
> following code to measure difference.
>
> [ 5 timesRepeat: [ 1 tinyBenchmarks] ] timeToRun
>
> This is HydraVM without attempts to arrange interpreters ivars:
>
> 28921
> 28863
> 28863
>
> This build shows a small slowdown (i placed all big-sized arrays at
> tail, and #stackTop #successFlag at head)
>
> 28938
> 28940
>
> With this build i placed methodCache ivar to come first.
>
> 28279
> 28264
>
> so, difference is small but noticeable. Placing methodCache first
> gives roughly 1-2% speedup.
>
> I don't really sure if this worth experimenting at all. And i'm
> lacking of knowledge of different CPU/compiler details to predict that
> these changes will take effect on different CPUs (mine is AMD Athlon
> series).
>
> If you having any ideas, concerning given changes, or any other
> optimizations which can probably improve speed, please feel free to
> uncover details/guidelines.
>
> -- 
> Best regards,
> Igor Stasenko AKA sig.
>

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