Thanks Ian.
Forwarding to the list - John, the GCC 4.3 comments will be of interest.
----- Forwarded message from Ian Piumarta <
[hidden email]> -----
X-Sent-To: <
[hidden email]>
From: Ian Piumarta <
[hidden email]>
To: "David T. Lewis" <
[hidden email]>
In-Reply-To: <
[hidden email]>
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 -----
Locked
