Mersenne Digest Tuesday, 12 May 1998 Volume 01 : Number 359 ---------------------------------------------------------------------- From: Sam Laur Date: Tue, 12 May 1998 10:49:27 +0300 (EET DST) Subject: Mersenne: CPU years, PrimeNet Did the calculation formula for CPU years (factoring) recently change in PrimeNet? Yesterday, I had 0.271 P90 CPU years of factoring and today I have 0.644 P90 CPU years' worth. It's fairly impossible that I could have done such a leap with a class of 11 K6/166's :-) ------------------------------ From: "Brian J Beesley" Date: Tue, 12 May 1998 09:02:01 GMT Subject: Re: Mersenne: program > In a 64 bit (IEEE) double, yes, but Intel CPUs have a larger floating > point type that has 64 bits of mantissa within a 96 bit "long double". > I'm pretty sure that George Woltman's programs use this long double > type; I know that the mers package LL testers use it when they can. Errr ... the Intel FPU internal representation always has 64 bit mantissa, 1 sign bit and 15 bit exponent - single (longword) and double (quadword) are automatically converted to/from this 80-bit internal format during memory write/read cycles. You can also store "long real" (80-bit) quantities directly. In the Good Old Days when we had only i286 processors and DRAM was fast enough that cache wasn't neccessary, doing this Made Sense. I'm not sure that it does any more. You're *bound* to introduce at least one extra clock for every 80-bit read/write compared with the same operation on a 64-bit real (Pentium memory bus is 64 bits wide) - - more than one clock if you have slow memory and the whole item isn't already in cache. Probably it would be better to store the 80-bit format padded to 16 bytes with filler in a structure, but you'd be doubling the memory usage overhead, and you'd *still* need at least one extra clock for each read & write. In some special cases you may need to store error quantities like +/- infinity (divide by zero, tan pi/2 etc). There are special codes for this (using the most significant bit of the mantissa set to zero) which can't be represented in the 32-bit and 64-bit formats - they don't actually store the mantissa MS bit, always assuming it's 1 - so, if you wish to store these special values outside the FPU, you *have* to use the 80-bit representation. I haven't actually disassembled George's code, but I'm truly amazed at how much performance it delivers, I'd be amazed if you could get any really significant improvement using current Intel CPUs. The argument started from the premise that perhaps the code could be tweaked a bit to improve Prime95's performance on AMD CPUs. Well, perhaps it could. But I'm afraid that the currently available AMD processors will always deliver disappointing floating-point performance compared with the nearest spec Intel chip. This doesn't mean that I'm opposed to AMD CPU's - for general usage, the K6 is certainly worth considering as an alternative to an equivalent spec Intel MMX, being much cheaper and arguably even a little faster for integer work - but, considered purely as a platform for running Prime95, the Intel CPUs are clearly superior. Brian Beesley ------------------------------ End of Mersenne Digest V1 #359 ******************************