7/16    I tried the mips3-sgi-irix6.2 and the mips4-sgi-irix6.2 versions of
        SETI@home on the same IRIX64 machine, and the latter only gives about
        5% higher speed over the former.  Anyone knows why a 64-bit version of
        such data-intensive program as SETI@home doesn't give much higher
        performance over its 32-bit counterpart?

        BTW, my 250MHz R10000 IRIX seems to be able to complete a work unit in
        about the same time as my 1.2GHz P4 NT.  Wow!
        \_ Why would it? A 64-bit architecture would only save you on a
           few instructions as you attempt to load the register file with
           64-bit values. That's about it. So even if SETI was using
           64-bit it wouldn't run much faster. SIMD extensions like AltiVec
           and MMX can derive some sub-word parallelism but MIPS isn't a
           SIMD extension. 64-bit versions of IRIX also have a newer ABI
           (n64) which could theoretically be more efficient (with register
           allocation rules and such) but I'm sure it'snot significant
           \_ But wasn't the selling point of 32-bit apps/CPUs over 16-bit
              apps/CPUs in the industry years ago that "your data-intensive
              applications will run much faster it can process thirty-two bits
              of data at a time instead of sixteen bits"?  The same doesn't
              apply to 32bit --> 64bit?  I understand that there are certain
              instructions that doesn't benefit from a bigger data size (like
              testing a boolean), but I was still expecting a difference bigger
              than 5%.
              \_ Probably because 16-bit programs attempted to mimic a 32-bit
                 computation by breaking it up into two parts and merging
                 the results together somehow. Plus, in the x86 world you
                 were limited to 2^16 bytes which meant that if you had
                 programs larger than 64K it would require that you use the
                 segment:offset addressing which isn't very efficient itself.