🔒 Locked

WHAT??

Started by Catafriggm Jan 10, 2007 at 10:16 PM 9 replies 1.5k views

Original Post

Jan 10, 2007 at 10:16 PM

So, I was looking up instruction times for multiply and divide in the Intel optimization manual (Pentium 4 edition), to see if it would be worthwhile to convert this divide into a multiply and shift. What it listed was rather surprising. According to the manual, an integer divide takes 23/56-70 cycles (throughput and latency, respectively), while a floating point divide (double precision) takes 38/38. Okay, that seemed odd; but what really surprised me was that it lists unsigned integer multiply as 5/14-18, and floating point multiply as 2/7. Floating point multiplication is more than twice as fast as integer (and floating point divide has about half the latency of integer divide)? When did THAT happen? And does that mean it would be a good idea to convert to floating point, multiply by the reciprocal, and then convert back to integer (they don't even list the convert instructions in the manual)? :P [Edited by - Catafriggm on January 10, 2007 10:56:20 PM]

Wavarian

Jan 10, 2007 at 11:08 PM

Look up "FPU" on google.

StealthNinja

Jan 10, 2007 at 11:26 PM

P4s don't have integer multiplication hardware. Instead, it converts it to floating point, then uses the floating point multiplication hardware, then converts the result back. Hence why it takes longer. And just to let you know, what they call "throughput" is more like the reciprocal of the throughput.

ViperG

Jan 10, 2007 at 11:28 PM

/me converts all ints to floats

smr

Jan 10, 2007 at 11:54 PM

Quote:
Original post by Catafriggm
Floating point multiplication is more than twice as fast as integer (and floating point divide has about half the latency of integer divide)? When did THAT happen?

Welcome to 2002!

(I just picked a year completely at random)

Catafriggm

Jan 11, 2007 at 12:08 AM

Aha, thanks. That (StealthNinja) was enlightening. After that, I went and looked up the numbers for Core 2: 0.5/4 for integer multiplication, 22/22 for integer division, 2/5 for floating point multiplication, 32/32 for floating point division. Pretty sweet numbers for integers. Guess it would be worth my while to convert this division to multiply + shift.

ViperG

Jan 11, 2007 at 12:21 AM

don't most compilers nowadays change the division to multiplication?

RabblePants

Jan 11, 2007 at 12:28 AM

Quote:
Original post by StealthNinja
P4s don't have integer multiplication hardware. Instead, it converts it to floating point, then uses the floating point multiplication hardware, then converts the result back. Hence why it takes longer. And just to let you know, what they call "throughput" is more like the reciprocal of the throughput.

No integer multiplication hardware? That doesn't sound right. Integer handling is one of the most basic parts of any processing unit. Anything to support the no integer multiplication thing? (I couldn't find anything on a quick google search)

Nytegard

Jan 11, 2007 at 12:37 AM

Quote:
Original post by Grafalgar
Quote:
Original post by StealthNinja
P4s don't have integer multiplication hardware. Instead, it converts it to floating point, then uses the floating point multiplication hardware, then converts the result back. Hence why it takes longer. And just to let you know, what they call "throughput" is more like the reciprocal of the throughput.

No integer multiplication hardware? That doesn't sound right. Integer handling is one of the most basic parts of any processing unit. Anything to support the no integer multiplication thing? (I couldn't find anything on a quick google search)

While I wouldn't go as far as to say that, from the Pentium 4 Optimization Guide:

Quote:

Integer and Floating-point Multiply
The integer multiply operations, mul and imul, are executed in the floating-point unit
so these instructions should not be executed in parallel with a floating-point
instruction. They also incur some extra latency due to being executed on the
floating-point unit.
A floating-point multiply instruction (fmul) delays for one cycle if the immediately
preceding cycle executed an fmul. The multiplier can only accept a new pair of
operands every other cycle.
Assembly/Compiler Coding Rule 44. (M impact, MH generality) Replace integer
multiplies by a small constant with two or more add and lea instructions, especially when
these multiplications is part of a dependence chain.

It has been like that for awhile, at least since the Pentium 2. Go down to section 5.6.3.

[Edited by - Nytegard on January 11, 2007 1:37:06 AM]

iMalc

Jan 11, 2007 at 1:20 AM

Catafriggm, don't use such a ridiculous thread title. Use something meaningful please!

StealthNinja, It doesn't convert to floating point and back. Conversions between float and integer are slow, especially back to integer.
Floating point multiplication and integer multiplication must share some common part of the CPU to execute them. This makes sense as the multiplication instructions acting on the mantissa of say a double would be doing the same kind of thing as integer multiplications. But there is no conversion being done there at all.

RabblePants

Jan 11, 2007 at 8:14 AM

Quote:
Original post by iMalc
Catafriggm, don't use such a ridiculous thread title. Use something meaningful please!

StealthNinja, It doesn't convert to floating point and back. Conversions between float and integer are slow, especially back to integer.
Floating point multiplication and integer multiplication must share some common part of the CPU to execute them. This makes sense as the multiplication instructions acting on the mantissa of say a double would be doing the same kind of thing as integer multiplications. But there is no conversion being done there at all.

Ok that makes sense - thanks guys =D

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.