Re: [berman@example.com: LINUX on Alpha info]

[turnbull@example.com (Stephen J. Turnbull)]

Ted,

   Virtually the running of any 16 or 32 bit native application will run 
   slower [on a 64-bit machine.  

Yup, that's what I was thinking of---assuming that you are using
something like a 64-bit Windows that needs to be "thunked", or a
cross-platform emulation.  (What 16-bit apps are there for the Alpha?)
But otherwise, if there's a compatibility mode, I'm not aware of a
performance hit; an 8MHz Pentium <giggle> runs DOS programs just as
fast as an 8MHz 8086.  No?  Anyway, under Linux, that's not going to
be a problem.  You recompile the ones that matter.

   Where you are getting confused is clock speed.  Clock speed is what will 
   improve performance of apps not written to utilize 64 bit word sizes.

Apps don't have to be *written* to utilize 64-bit word sizes.  They
need to be compiled to use them, in general.  (A big win for Linux, if
it has the app you need.  For MS, you'll have to pay, and pay big, to
upgrade to the new machine.)  Network apps are one counterexample:
they *must* be written to use 32-bit ints (at least for addresses) and
also have correct endianness.  As far as I know, GCC has been ported
to the Alpha's 64-bit mode; if not, please tell me.  Most programs use
the local machine's standard ints.

To give you an example that would surely make a difference on a 64-bit
bus at the same clock speed, and might make a difference on a 32-bit
bus at the same clock speed (either way depending on how loads and
stores are optimized) is the use of word-size memory moves in
strcpy()-like functions.  This made a nearly 4:1 difference for the
DJGPP libc string and memory move functions for large (>1kB) block
moves.  These functions get used in most user applications.

Graphics (bitmaps, pixmaps), like net apps, must be rewritten to use
different word sizes efficiently.  But most modern graphics libraries
(ever looked at any X windows server source?) are extremely heavily
parametrized to deal with word size and endianness.

   George is probably not running any native 64 bit applications, so therefore 
   this affects George greatly.  Almost nothing will run faster with a 64bit 
   processor change only.

Depends on load/store optimization.  Unless you allow me the 64-bit
bus at the same clock speed.  Then memory moves will go double-quick,
improving most buffered software, which is just about everything that
reads the disk or blits graphics to the screen.

   DX-2, DX-4, these are not ;64 bit processors, these are double external 
   clocked versions of the DX-xx family.  Where did you think they were 64 
   bits?

They are bus-restricted, though.  Some 64-bit ops will be faster, for
example if you need big integers (a lot of financial software uses
64-bit integers; this would probably need a rewrite, though---I doubt
these programs are parametrized the way graphics software is).  It's
quite reasonable to suppose that a 64-bit load or store on a 32-bit
bus can be faster than two 32-bit accesses (only one instruction read
and address decode; on second thought, probably not in practice since
indexing will be done in a register on both architectures for block
moves).  64 bits will not give you anywhere near the improvement that
internal clock multiplication does.  But to the extent that it's
faster than 32 bits, it helps a little even on the same bus and clock.

As for slower, I just don't see it, unless you need to emulate a
different processor family, or use thunks to interface a 64-bit app to
a 32- or 16-bit library such as Windows, or vice-versa (for that
mythical 64-bit Windows; or is Alpha Windows NT 64-bit?)

Agreed, I can't see that the minor improvements I'm talking about will
do anything for the typical user.  It's the clocks that matter, and
will determine whether it's worth paying more.  Unless you use Linux,
and can recompile the whole lot to use the more efficient 64-bit
operations, or can afford to buy all your software again when the
vendor gets around to rebuilding them.  And even there, you really
need the 64-bit bus to buy any help from the 64-bit processor.

-- 
                            Stephen J. Turnbull
Institute of Policy and Planning Sciences                    Yaseppochi-Gumi
University of Tsukuba                      http://turnbull.sk.tsukuba.ac.jp/
Tennodai 1-1-1, Tsukuba, 305 JAPAN                 turnbull@example.com