AMD Opteron

[dsouza123]

Could both the x87 and SSE2 be run in parallel/interleaved ?

I don't think there are any hardware dependencies ( registers ),
the x87 registers are separate from the SSE2 registers.

I am not sure about floating point pipelines if there would
be any resource contention.

Do both x87 and SSE2 use the same pipeline ?

If it works it would give an almost 2x improvement.

[ColdFury]

I don't think there are any hardware dependencies ( registers ),
the x87 registers are separate from the SSE2 registers.

There's a (relatively) lengthy mode change required when going from x87 to SSE code. This is because MMX, SSE, and (I think?) SSE2 all use the fpu registers aliased.

[dsouza123]

I know that MMX registers are the same as (aliased) x87 registers, but from what I understand the SSE/SSE2 registers are separate, using x87 along with SSE2 doesn't corrupt each other (registers or state).

Under 64-bit long mode there are 16 SSE2 registers but still only 8 x87 registers.

There still may be contention for the 3 floating point units ( not identical )
to do the calculations on using the x87 (64-bit doubles/80-bit extended) or SSE2 (64-bit doubles), maybe Dresdenboy knows.

May be there is some way of partially overlapping the code for both or even alternating, complete x87, complete SSE2, complete x87, etc and still getting a performance gain.

[Dresdenboy]

Originally Posted by dsouza123

I know that MMX registers are the same as (aliased) x87 registers, but from what I understand the SSE/SSE2 registers are separate, using x87 along with SSE2 doesn't corrupt each other (registers or state).

Under 64-bit long mode there are 16 SSE2 registers but still only 8 x87 registers.

There still may be contention for the 3 floating point units ( not identical )
to do the calculations on using the x87 (64-bit doubles/80-bit extended) or SSE2 (64-bit doubles), maybe Dresdenboy knows.

May be there is some way of partially overlapping the code for both or even alternating, complete x87, complete SSE2, complete x87, etc and still getting a performance gain.

The functional units are limiting here - you can't do more than one double precision mul and add (at same time) per cycle on Athlon/Opteron/P4.

And on AMD CPUs all these registers are mapped to the same internal FPU register file (with 88 regs).

[db597]

The functional units are limiting here - you can't do more than one double precision mul and add (at same time) per cycle on Athlon/Opteron/P4.

Looks like the only way an Athlon64/Opteron can beat a P4 is if it has dual SSE2 units (which it doesn't). Otherwise there's just no way to make up for the lack of clock speed.

[dsouza123]

It wouldn't even need that ( dual SSE2 units ) just a second set of the 3 FP (functional) units FSTORE FADD FMUL. Then 2 muls or 2 adds could be done in parallel using either SSE2 or x87.

[Dresdenboy]

Originally Posted by dsouza123

It wouldn't even need that ( dual SSE2 units ) just a second set of the 3 FP (functional) units FSTORE FADD FMUL. Then 2 muls or 2 adds could be done in parallel using either SSE2 or x87.

If we believe some specs which popped up somewhere on the net, the K9 will have 3 full FPU blocks :) But now we only have 1 FADD, 1 FMUL.. 1 64bit integer multiplier (with 128bit result) and 3 64bit integer adder. Unfortunately the decoder can decode only 3 instructions per cycle.

DDB

[db597]

It took them 3 years to go from the K7 architecture to the K8 (and it's still only in servers at this time). I'd not like to hold my breath for the K9 :(

Ironically, it's probably cheaper (in terms of silicon real estate) for them to implement just a 512Kb cache (instead of 1MB) and add those 3 full FPU blocks instead. More performance, yet more chips per waffer. Cache just uses up so many transistors.

Yet this is just wishful thinking... P4 seems to be the way to go for Prime95 in the near future.

[Dresdenboy]

Originally Posted by db597

Yet this is just wishful thinking... P4 seems to be the way to go for Prime95 in the near future.

Prime95 is a special case. It's so heavily optimized that it's close to the max. possible FPU throughput. In normal cases the K7 fpu is nearly always underutilized. Opteron helps by adding regs - for up to 32 double values. So instead of loading, storing, swapping (what you had to do without SSE2 when you wanted double precision, not SSE) you can do much more calculations at once. And the cache is even bigger and faster for steady delivery of numbers to the FPU.

Cache is useful if the memory is slow. But the wins by using cache are smaller the bigger the cache already is. The probability of cache hits are already high, so it is hard to get them much higher - by doubling the cache we won about 3-10% with Barton.

And although the P4 also can do 1 FADD/1FMUL per cycle, it has other limitations - no 64bit integer multiplier, no 16 SSE2 regs, and AFAIK it needs to load numbers from L2, never L1 (I'll check that).

DDB

[ewmayer]

Originally Posted by Dresdenboy

And although the P4 also can do 1 FADD/1FMUL per cycle, it has other limitations - no 64bit integer multiplier, no 16 SSE2 regs, and AFAIK it needs to load numbers from L2, never L1 (I'll check that).

Please correct me if I'm wrong, but I believe the SSE2 allows any combination of 2 fadd/fmul ops per cycle. For highly optimized FFT code, which tends to be add-dominated, being able to do 2 fadd per cycle is a huge gain. If the Alpha 21264 could do that, instead of merely being equal to the P4 in terms of per-cycle performance (the 21264's larger caches and such help make up for its lesser maximal FPU throughput), I'd be getting nearly double the per-cycle performance of the P4. (Though of course the P4's clock rates are much higher than those of any currently available 64-bit RISC chip)

To give you an idea of the impact of being able to do any two of (fadd, fmul, madd) per cycle: on a 550MHz HP PA-RISC (whose dual mul/add FPUs are similar to those of the Itanium) I get ~0.12 sec/iteration for a 1024K FFT length. That is only ~2x slower than my 2GHz P4 gets using Prime95, i.e. nearly double the per-cycle floating-point throughput. I'm not yet getting as good of performance from the Itanium (on that, I'm getting slightly better per-cycle performance than the Alpha 21264), but the compiler technology for the Itanium is not yet as mature.

[ColdFury]

AFAIK it needs to load numbers from L2, never L1 (I'll check that).

I believe that floating point automatically goes to the L2. Integer should use the L1 (otherwise the L1 wouldn't be used at all!) This isn't a problem in practice because most floating point working sets don't fit in the L1 anyways.