"Core 2" GMPbench results

[Décio Luiz Gazzoni Filho]

On Aug 22, 2006, at 1:34 PM, Torbjorn Granlund wrote:

> I've had the opportunity to test GMP 4.2.1 on a new "Core 2" processor
> and also run GMPbench on it.  While the machine is very zippy when
> compiling things, GMPbench results are not all that great as one might
> had expected from the raving reviews of this processor.  Some GMP
> timing results are actually truly terrible.
>
> GMPbench results are here: http://swox.com/gmp/gmpbench.html
>
> One clear reason for the results is that the current mpn_add_n and
> mpn_sub_n loops run terribly, at 13.5 cycles/limb.  The multiply loops
> (mpn_addmul_1 and friends) run much faster, at between 4.5 and 7
> cycles/limb, oddly enough.
>
> This is the loop of mpn_add_n, which to my eye looks very innocent:
>
> .Loop:  movq    (%rsi,%rcx,8), %rax
>         movq    (%rdx,%rcx,8), %r10
>         adcq    %r10, %rax
>         movq    %rax, (%rdi,%rcx,8)
>         incq    %rcx
>         jne     .Loop

According to Agner Fog's table of instruction latencies,

http://www.agner.org/optimize/instruction_tables.pdf

there isn't anything out of the ordinary in these loops. Pentium 4  
had terrible timings for adc, but this was remedied in Core 2.

What if GMP is compiled in 32-bit mode? There were quite a few  
problems with Pentium 4 in 64-bit mode as well, which should have  
been remedied in Core 2 also.

I do remember, though, that AMD's botched job at a 64-bit extension  
of IA-32 invalidated certain opcodes, including that of inc. That'd  
be a terrible situation to be in, since the inc instruction doesn't  
update the carry flags while an addq %rcx, 1 would, which would ruin  
the algorithm. Still, could you try changing that instruction (even  
if it would purposefully insert a bug in the code) just to test this  
theory?

Finally, doing some profiling using Core 2's built in performance  
counters might reveal cache or similar problems, exceedingly unlikely  
as they may be.

Décio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://gmplib.org/list-archives/gmp-discuss/attachments/20060822/452b0d04/attachment.bin