[rescue] Solaris on a PPC

[Francisco Javier Mesa-Martinez]

On Thu, 6 Feb 2003, Stephen D. B. Wolthusen wrote:

>
> In many cases (with obvious exceptions being database-related work and codes
> that actually make use of larger integer and pointer ranges), 32 bit code is
> actually *faster* on machines that support both (such as Alphas and
> UltraSPARCs -- both of these support mixed operations, i.e. you typically have
> the OS running at 64 bit address width and applications running at 32 or 64).
> The reason for this is that moving instructions (think constants embedded in
> opcodes) and of course operands takes up a portion of the available memory
> bandwidth -- which is the limiting factor on most current CPU architectures,

Actually the instructions and operands are usually tied to the memory
access width. I.e. The instructions are still 32bits, 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.

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. The wider the
arithmetic/decodng HW the slower it is (due to carries and propagation
issues). This is one of the reasons why 64bit machines are harder to clock
higher (longer critical paths in the design). Basically a 32bit CPU
running at 2x the speed of a 64bit, could keep up with 64bit ops with
respect to the native 32bit machine w/o any problems. 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!)

> even on balanced system architectures that Alphas are typically part of.
> Similar arguments obviously also apply to other pathways such as prefetch
> queues (which can have devastating effects on tight loops) and caches.
> In memory, however, the story is different. Here, Alphas really like to have
> addresses aligned to the cache line size. That means a few hundred
> bytes wasted at most, and when performance matters that much, main memory is
> cheap (*).
>
> (*) Relatively speaking, of course. They could at least send memory kits in
>     the nifty little packages normally used for overpriced bespoke jewelry.
>
> --
>
>         later,
>         Stephen
>
> Stephen Wolthusen (stephen at wolthusen.com)
> _______________________________________________
> rescue list - http://www.sunhelp.org/mailman/listinfo/rescue