[piumarta@speakeasy.net: Re: [Vm-dev] Re: [squeak-dev] 64bit VMs some thoughts.]

[David T. Lewis]

Thanks Ian.

Forwarding to the list - John, the GCC 4.3 comments will be of interest.

----- Forwarded message from Ian Piumarta <piumarta at speakeasy.net> -----

X-Sent-To: <lewis at mail.msen.com>
From: Ian Piumarta <piumarta at speakeasy.net>
To: "David T. Lewis" <lewis at mail.msen.com>
In-Reply-To: <20091204014908.GA61467 at shell.msen.com>
Subject: Re: [Vm-dev] Re: [squeak-dev] 64bit VMs some thoughts.
Date: Fri, 4 Dec 2009 15:28:40 -0800
X-Mailer: Apple Mail (2.936)

Hi Dave,

>I think you can expect the 64 bit image (SQ_VI_BYTES_PER_WORD 8) to be
>relatively slow. Entirely aside from address calculation issues, the  
>image
>is going to be full of 64-bit integer arithmetic in places where 32- 
>bit
>arithmetic would normally be happening, and that is bound to take a  
>toll.

My experience with em64t has been entirely positive.  Programs  
consistently run faster in 64-bit mode than in 32-bit mode.  Much of  
the improvement is probably due to the 8 additional registers and the  
passing of the first few arguments in registers rather than on the  
stack.  The Squeak VM likely does not benefit the way most other  
programs do because of the aggressive inlining of methods in the C  
code generator, eliminating entirely the impact of a better argument  
passing convention.

I have to say I am disgusted at gcc 4.3 though.  Maybe replacing all  
the -O/-f options with '-Os -fno-cse-follow-jumps -fomit-frame- 
pointer' would help?  It has worked wonders for me on (non-Squeak)  
bytecode interpreters; the Core2 in particular seems hypersensitive to  
locality and alignment of loops/jumps at the start of cache lines.   
(Attempts to manually allocate machine registers to VM registers  
always reduce performance with gcc-4.3, but I haven't experimented  
with explicit register assignments in the Squeak VM on 64-bit hardware.)

Cheers,
Ian

----- End forwarded message -----