mp_Sind is simply an array of doubles. This is the non-Lerp'd version and it is even slower than by an average of 1.5-2x than sin(x). I am quite surprised by this. Is there something in this code that stands out as a reason for it a table lookup being slower than a sin() function?
It might have something to do with the way you are determining your index. I'm sure sin implementations vary widely across platforms and depending on the chip support underneath, but if I run a simple test where I do the following:
for( int i = 0; i < 10000; ++i)
for (int j = 0; j < 100000; ++j)
double d = get_value (j);
I get wild results just by changing how the index is generated.
I get a runtime of ~8 seconds. For
I get a runtime of ~12 seconds. Seems to correspond to your 1.5x claim, though that is really more likely just a coincidence.
Well I'm looking into an embedded system project, that's why I was looking into lookup tables. I was going to write some a generic helper library while I wait on the chip because of Chinese New Years (Like a month from when I ordered it before they ship it).
However, I guess I'll have to do the test on the chip to determine whether it's because of code or hardware acceleration of the sin().
Converting a double to an integer is not a trivial operation because they are represented completely differently in binary. It is not like conversions between integer types where it's almost just a matter of changing the number of bits. Like L7Sqr has reported, I would expect the conversion from double to integer to be taking a lot of the computing time (we're only talking about a few clock-cycles here, of course). If you can get away with not using floating-point values at all (which is very common in embedded systems since many micro-controllers don't have floating-point modules on their CPU anyways, or very limited capabilities for floating-point operations), then it will be faster. If it is appropriate, consider perhaps using integers with a mapping like 1(integer) -> 0.001(floating-point) (or even a base 2 mapping) and do all your calculation with integers only and your transcendental functions with look-up tables.
And, I would expect that the code you have would be faster than the sin() on a micro-controller (if that sin() function exists).