I think I'll write a small test program for this. From what I've read this morning it might well be possible that the instructions of the P4 can specifiy how many of those 80 bits to use for calculations, as there are 3 different float formats possible for each register: 32 bit, 64 bit (double, same as MMX/SSE) and 80 bit (double extended precision). So it might be possible that multiplying two floats can be a little faster than multiplying two doubles.

I guess though, that the impact of this is small compared to the effects of pipelining instructions and branch predicition, as well as what is refered to as 'changing mode' of the fpu registers. This suggests (as is also recommended in the Optimization Guide) that you stick to one particular floating format and don't mix different bit length.

For 387 registers, the 32 bit float, 64 bit double or whatever is always treated as an 80 bit long double unless the precision in the control word has been altered from the default (which gcc does for compatibility for some old and IMAO broken programs). This is after loading the number from memory of course. IIRC, a double can be slower if it crosses some certain boundary, and of course if you're using an array bigger than cache size you're wasting a lot of time.

You can't take those Intel docs too seriously, back in the '90's I had an 8086/8087 Intel book of some kind, and it said the 8087 sped up floating point calculations from "10 to 100 times faster", but eventually I got an XP and clone 286 and my asm floating point stuff was faster on the 286 (fpu slowed down to 2/3 cpu speed) and only slightly slower on the XP (8 bit bus). Except for trancendentals of course