0

Say fs = 1000 and Ts = 0.001. Would it be faster to compute Ts at the beginning and subsequently multiply by 0.001 instead of dividing by 1000 when computing frequency-dependent quantities?

neolith
  • 147
  • 5
  • 3
    This isn't really a signal-processing question per se; the answer to your question is going to depend on the characteristics of the computing platform you're using. In general, yes, multiplication is usually faster and less hardware-intensive than division. – Jason R Mar 11 '21 at 14:20
  • Thank you and sorry for posting in the wrong forum – neolith Mar 11 '21 at 14:24
  • 2
    Yes. For most platforms it's faster to multiply then to divide – Hilmar Mar 11 '21 at 15:01
  • Presumably you're using the $T_s$ to scale coefficients. If your sampling rate is fixed, it's faster to precompute your scaled coefficients. I.e., in your code don't use T_s * k_i * error; use k_i * error with k_i appropriately scaled. – TimWescott Mar 11 '21 at 20:51
  • Isn't that something that one could easily test with two loops? – M529 Mar 13 '21 at 13:41
  • @M529 I guess so. Or you could write both operations one after another and compare the disassembly. – neolith Mar 13 '21 at 14:22

1 Answers1

2

Generally, it makes sense to ensure that your code is logically correct, that it is numerically well-behaved, intuitive to read and tested. That is hard enough. Only when you observe that some innerloop or library call is a real hotspot, affecting the functionality of your software does it make sense to rewrite code for speed, and then you should always profile before and after.

If a constant is known compile time, the compiler may apply the inversion to substitute division for multiplication, if this is within precision constraints and runs faster for a given target. If ppssible, I would rather outsource that complexity to the compiler.

Edit:

It is not "technically the same operation". To see why, have a look at this MATLAB snippet:

a = single(10.0)
b = 1/a
c = 42/a
d = 42*b

c-d


ans =


single


-4.7684e-07

Since floating-point is operating with finite precision and intermediate rounding, the order of operations does matter. Depending on compiler flags, the compiler may be allowed to re-order floatingpoint arithmetic even though the result will differ to some degree.

If we look at the binary representation we see that they differ in the lsb:

dec2bin(typecast(c,'uint32'),32)
dec2bin(typecast(d,'uint32'),32)

ans = '01000000100001100110011001100110'
ans = '01000000100001100110011001100111'

-k

Knut Inge
  • 3,384
  • 1
  • 8
  • 13