[rescue] Solaris on a PPC

[Stephen D. B. Wolthusen]

Hi,

On 06-Feb-2003 Francisco Javier Mesa-Martinez wrote:

> Actually the instructions and operands are usually tied to the memory
> access width. I.e. The instructions are still 32bits, 

Yes, that's why I specifically referred to embedded constants. 

> and the operands if they are 64bits are fed through a memory bus that is at
> least 64bits wide. Thus a 64bit machine is no less starved when running
> 32bit code.

I was referring to the aggregate memory bandwidth. The maximum bandwidth
(admittedly theoretical due to dependencies, stalls etc.) of the multiple ALUs
and FPUs on Alphas exceeds main memory bandwidth by quite a bit. 

Whether or not that matters is of course a different matter. If your code has
sufficient reference locality, then not. Largish matrix-heavy codes are quite
sensitive to the issue I described in my original post, though.

> The reason why 64bit machines are slower when executing 32bit code is the
> fact that their internal datapath is full 64bits. So for example a 32bit
> valued ALU op has to be fed to a 64bit ALU. 

That will already be taken care of during the instruction prefetch, and while I
wouldn't bet on it I don't think that there is a critical path along that line
in any Alpha (that would've been particularly daft since VMS at first ran at
straight 32 bits ...).

> So unless the
> desingers of the CPU were careful enough, 32bit code may be slightly
> slower than 64bit ops (see at the results of some modern processors when
> running single and double precission code. It turns out that some machines
> are actually slower when running single precission stuff!)

Well, the Alpha designers certainly were careful enough by that measure, as
were the UltraSPARC designers (do not have comparable figures for other modern
CPUs). And note that I was referring to integer performance, FPUs obviously
have their own quirks.

-- 

        later,
        Stephen

Stephen Wolthusen (stephen at wolthusen.com)