John Gilmore wrote: >First, long long C arithmetic data types occupy eight bytes of storage in >both an AMODE(31) and an AMODE(64) environment.
This is true, but I was talking about the 'long' data type, which does change in size. >Second, the machine instructions used by compiled C code to access >traditional shorter data types are significantly slower on an AMODE(64) box. Could you elaborate? From what our hardware folks tell us, the 32-bit arithmetic and 64-bit arithmetic instructions should be exactly the same speed (single-cycle) on z900 (and z990) ... (There are some cases where the compiler has to treat an array subscript of width less than pointer width somewhat less optimal w.r.t. loop optimizations due to the potential for overflow in the smaller type. But this is not a hardware problem.) >Third, my own measurements of two otherwise identical C packages that manage >circular lists have established that the 64-bit version is significantly >faster (13+ percent) than the 31-bit version on a z900 box, even though (as >Weigand points out) eight-byte instead of four-byte pointer pairs are used >in the former. This is very interesting. Did your measurements involve enough data to overflow the L1 cache? If everything fits into cache, the problems I've described don't apply ... In our measurements, based on the SPECint2000 test cases, the one test case that showed the worst degradation from 31-bit to 64-bit had pointer-chasing linked list accesses in its 'hot loop'. However, this application certainly overflowed all caches. Bye, Ulrich -- Dr. Ulrich Weigand [EMAIL PROTECTED]
