# HLSL - Division instead of Multiplication?

This topic is 2509 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi guys,

i have a wild question, i once read that divisions are faster then multiplication. Therefore in some relations

velocity *= delay;

could be transformed into

velocity /= velocity - (velocity / n)&nbsp; // where n = some power of 2

is this right, or is this old technology? Compilers more intelligent?

Thank you very much

schiho.com

##### Share on other sites
I have not heard of these cases. At any rate, the HLSL compilers always seems to prefer multiplication when possible and will potentially represent divisions in code as multiplications in assembly. I would imagine that if those cases did exist, either the HLSL compiler or the JIT compiler in the driver would try to handle it.

##### Share on other sites

i have a wild question, i once read that divisions are faster then multiplication.

I have no idea what your source is, but you need to completely forget this “nugget”. It is exactly the opposite.
Divisions are to be avoided whenever possible as they are up to 25 times slower than multiplies.

Hence the above post which explains that compilers always try to perform a multiplication instead of a division when possible.

L. Spiro

##### Share on other sites
In assembly division will translate to at least 2 instructions - rcp and mul (and rcp can only operate on scalar values so it may need up to 4 if you're using all register elements). Also - division is scary! You get nasty things like divide by zero to watch out for. So I don't really see how division could be faster.

##### Share on other sites
Hi guys, thank you for the answer

A: 100/2
B: 100*0.5
What is faster?

I got this from :

OR is CPU and GPU different?

i can agree with most of you, thats why i was asking the question.

thanks

##### Share on other sites
A is going to be faster on the CPU because the compiler can detect that it's integer division by 2 and convert it into a simple bitshift: 100 >> 1. A compiler might also be able to do the same for B but it might not - because we're into floating point country (where bit shifts don't exist) it might do the full thing.

A GPU will normally operate in floating point internally so B would be expected to be faster.

For a proper comparison you need to pick numbers that won't be susceptible to this kind of coptimization: 100.174 / 2.625 for example. Then you'll see the real difference.

##### Share on other sites
So,

having this texture lookups:
 //sample neighbour Pixels float4 colorLeft = tex2D(memTex0, biasedTex0.xy-float2(pixel.x, 0)); float4 colorTop = tex2D(memTex0, biasedTex0.xy-float2(0, pixel.y)); float4 colorRight = tex2D(memTex0, biasedTex0.xy+float2(pixel.x, 0)); float4 colorSub = tex2D(memTex0, biasedTex0.xy+float2(0, pixel.y));

And doing calculation by a division:
 buffer2.rgba = (colorLeft + colorTop + colorRight + colorSub) /2 - (currentbuffer2);

should be replaced by a more gpu friendly version ? (division replaced by multiplication)
 buffer2.rgba = (colorLeft + colorTop + colorRight + colorSub)*0.5 - (currentbuffer2);

Is this the bette way of writing hlsl code or will the compiler do that automaticly? I just want to make it a good habit, by choosing the "better way"

thank you very much all

##### Share on other sites
Checking in PIX, I tested "return color * 0.5f" and "return color / 2.0f". In both cases it translated the code to a multiplication by 0.5, so yes - when you're dividing by a constant value the compiler will automatically detect that and convert it to multiplication for you. If you're dividing by non-constant (the result of another calculation or lookup) the compiler won't be able to make this optimization.

##### Share on other sites
Thanks mhagain for the testing it with PIX, with non-constant you mean, when the value for the division variable is not hardcoded. I see...thank you a lot, that information was very usefull.

1. 1
2. 2
Rutin
19
3. 3
khawk
18
4. 4
5. 5

• 9
• 12
• 16
• 26
• 10
• ### Forum Statistics

• Total Topics
633769
• Total Posts
3013759
×