0
$\begingroup$

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?

$\endgroup$
6
  • 3
    $\begingroup$ 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. $\endgroup$ – Jason R Mar 11 at 14:20
  • $\begingroup$ Thank you and sorry for posting in the wrong forum $\endgroup$ – neolith Mar 11 at 14:24
  • 2
    $\begingroup$ Yes. For most platforms it's faster to multiply then to divide $\endgroup$ – Hilmar Mar 11 at 15:01
  • $\begingroup$ 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. $\endgroup$ – TimWescott Mar 11 at 20:51
  • $\begingroup$ Isn't that something that one could easily test with two loops? $\endgroup$ – M529 Mar 13 at 13:41
2
$\begingroup$

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

$\endgroup$
3
  • $\begingroup$ You pointed out something important: It depends on the compiler. Since it is technically the same operation, a good compiler would choose the best way of accomplishing it. $\endgroup$ – neolith Mar 13 at 14:20
  • $\begingroup$ See edits in my answer $\endgroup$ – Knut Inge Mar 16 at 20:27
  • $\begingroup$ Thank you for pointing that out $\endgroup$ – neolith Mar 16 at 22:59

Not the answer you're looking for? Browse other questions tagged or ask your own question.