AMD Opteron

[Prime95]

Originally Posted by ewmayer

Please correct me if I'm wrong, but I believe the SSE2 allows any combination of 2 fadd/fmul ops per cycle.

The P4's max throughput is one fadd and one fmul per cycle.

[ewmayer]

Originally Posted by Prime95

The P4's max throughput is one fadd and one fmul per cycle.

So the P4's SSE2 operations that operate on pairs of 64-bit doubles - which are the available ones (involving add or mul), and what is their latency/pipelineability?

This theme highlights one of the other reasons an integer transform is attractive - most CPUs can do 2 integer adds per cycle, so an integer transform optimized to minimize the number of muls should be able to come close in speed to a floating one, assuming integer muls and modulo operations are decently fast.

[Prime95]

An SSE2 add has a latency of 4 clocks and one can be started every other clock.

An SSE2 mul has a latency of 6 clocks and one can be started every other clock.

[Dresdenboy]

Originally Posted by ewmayer

This theme highlights one of the other reasons an integer transform is attractive - most CPUs can do 2 integer adds per cycle, so an integer transform optimized to minimize the number of muls should be able to come close in speed to a floating one, assuming integer muls and modulo operations are decently fast.

I'm working on that and my first step is implementing a FGT. Opteron has a fast 64bit mul and can do max. 3 integer adds per cycle. Unfortunately there is a limit of max. 3 issued macroOps to all units. But with SSE2 code this would look so:

[code:1]code:
...
addpd xmm3, xmm2
addpd xmm4, xmm2
mulpd xmm1, xmm0
...
The issued Ops:
(I don't consider the internal mapped regs now, xmmX is shortened to rX)
n+0: [fadd r3_lo, r2_lo] [fadd r3_hi, r2_hi] [-unused-]
n+1: [fadd r4_lo, r2_lo] [fadd r4_hi, r2_hi] [-unused-]
n+2: [fmul r1_lo, r0_lo] [fmul r1_hi, r0_hi] [-unused-]
(Here I'm not sure if it's possible for the decoder to split an double issued instruction - in that case the CPU would issue the 3 Ops in 2 cycles.)

The executed Ops:
m+0: [fadd r3_lo, r2_lo] [fmul r1_lo, r0_lo] [-unused-]
m+1: [fadd r3_hi, r2_hi] [fmul r1_hi, r0_hi] [-unused-]
m+2: [fadd r4_lo, r2_lo] [-unused-] [-unused-]
m+3: [fadd r4_hi, r2_hi] [-unused-] [-unused-]
[/code:1]
The free slots in this example show, that they won't be enough to make a full integer transform in parallel to the FP code (modulo etc.) but we could trade FP slots for integer if that transform allows us to do less FP calculations (due to more bits per input word or something else).

[QuintLeo]

As a thought, would it be possible (on the Opteron/Athlon64, and possibly on older CPUs) to keep the FP pipeline full and then use any "left over" instructions to run the Integer pipeline(s) for trial factoring on another exponent at the same time?

[Dresdenboy]

Originally Posted by QuintLeo

As a thought, would it be possible (on the Opteron/Athlon64, and possibly on older CPUs) to keep the FP pipeline full and then use any "left over" instructions to run the Integer pipeline(s) for trial factoring on another exponent at the same time?

This would be possible in a limited way. The problem here is to fit program loops of another code into the loops of the main code. Either we do it ourself (because we know, how the loops will look like - and use some automation) or we use SMT (what Intel calls "Hyperthreading"). SMT is not available in Opteron 1, so we would do it "by hand".

A parallel transform is a bit easier to fit since it has to handle similar data sets and the structure of the whole algorithm is similar - but not equal..