[rescue] Solaris on a PPC
Francisco Javier Mesa-Martinez
lefa at ucsc.edu
Thu Feb 6 13:18:01 CST 2003
On Thu, 6 Feb 2003, Stephen D. B. Wolthusen wrote:
> 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.
Again that has nothing to do with the CPU being 32 or 64 bit.
> > 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 ...).
How can a VLSI critical path be taken care of during prefetch? This is a
physical limitation of the actual silicon. I do not think you fully
understand what the term critical path means here... I was referring to
the actual limiter on real clock speed for the design. I.e. your clock can
only be as fast as the slowest component on the actual layout. All things
being equal (i.e. same technology process), a 64bit ALU will be
significantly slower than a comparable 32 or 4/8bit unit. Which is fine if
most of you ops are going to use 64bit operands (i.e. the 32bit unit would
have to be clocked at least 2x as fast to get the same performance on
64bit code). However if most of you ops require 32bit operands, then the
64bit ALU is at a disadvantage... since by using the same technology the
32bit ALU can be clocked higher (shorter critical path)... Here is when
MHz actually matter :-)
More information about the rescue
mailing list