Re: MPQS behavior

["Chris Condrat" <chris.condrat@gmail.com>]

On 3/24/06, Justin C. Walker <justin@mac.com> wrote:
> For various reasons, I decided to compare my G5 PowerMac and my Core
> Duo MacBook Pro in the following computation: I computed the
> coefficients of> At this point, the PowerPC has been chewing on this for roughly twice
> as long as the Core Duo (the Core Duo has been sleeping a lot :-}).
> However, the PowerPC is up to n=193, while the Core Duo is up to n=204.

I think you have some misconceptions about the G5 processor.  It not
even close to equivalent to the performance of the Core Duo.  With few
exceptions, only applications which are not Universal Binaries (UB)
perform worse on a Core Duo compared to a G5
(http://www.barefeats.com/).  If you compiled PARI on the laptop, it
was compiled for native code, making it extremely fast, and I would
guess that your Macbook Pro, and the Core iMac, should you buy one,
would both perform better than your G5.  Apple was smart to bail on
the G5, because it was fast becoming forgettable.

For PARI, the performance loss on the G5 was probably exacerbated by
other problems as well.  For instance, the G5 is a 64-bit processor,
and if the binaries were compiled in 64-bit mode, they are nearly
always slower than the 32-bit equivalent (and the Core Duo is a 32-bit
processor).  Even if the Core Duo's potentially hidden EMT64
instructions were enabled, the Core Duo would gain performance as the
x86 is one of the only processors which derives benefit from 64-bit
instructions due to additional registers.  Type "precision(x)" in GP
if you want to see how many bits PARI was compiled for (2^31 is the
32-bit).  Apple also chose to go the way of parallelism with its G5
machines because of scalability problems with G5 processors from IBM,
and PARI is not designed with parallelism in mind.  Finally, many apps
on the G5 only performed well because they were optimized for the
AltVec units.  PARI does not support such SIMD instructions as far as
I know.