I am trying to create some fast sin, sinc, and exponential
routines to speed up some code by using tables... but it seems
it's slower than the function itself?!?
The code below uses matplotlibd but is not necessary. The timing
code is lower.
Ideally I'd like to have quadratic interpolation an
On Wednesday, 22 May 2019 at 00:22:09 UTC, JS wrote:
I am trying to create some fast sin, sinc, and exponential
routines to speed up some code by using tables... but it seems
it's slower than the function itself?!?
There's intrinsic cpu instructions for some of those that can do
the math fast
On 22/05/2019 12:22 PM, JS wrote:
I am trying to create some fast sin, sinc, and exponential routines to
speed up some code by using tables... but it seems it's slower than the
function itself?!?
The code below uses matplotlibd but is not necessary. The timing code is
lower.
Ideally I'd like
On Wednesday, 22 May 2019 at 00:55:37 UTC, Adam D. Ruppe wrote:
On Wednesday, 22 May 2019 at 00:22:09 UTC, JS wrote:
I am trying to create some fast sin, sinc, and exponential
routines to speed up some code by using tables... but it seems
it's slower than the function itself?!?
There's intrin
On Wednesday, 22 May 2019 at 08:25:58 UTC, Basile B. wrote:
On Wednesday, 22 May 2019 at 00:22:09 UTC, JS wrote:
I am trying to create some fast sin, sinc, and exponential
routines to speed up some code by using tables... but it seems
it's slower than the function itself?!?
[...]
Hi, lookup
On Wednesday, 22 May 2019 at 00:22:09 UTC, JS wrote:
I am trying to create some fast sin, sinc, and exponential
routines to speed up some code by using tables... but it seems
it's slower than the function itself?!?
[...]
Hi, lookup tables ARE faster but the problem you have here, and
I'm su
On Wednesday, 22 May 2019 at 08:25:58 UTC, Basile B. wrote:
On Wednesday, 22 May 2019 at 00:22:09 UTC, JS wrote:
I am trying to create some fast sin, sinc, and exponential
routines to speed up some code by using tables... but it seems
it's slower than the function itself?!?
[...]
Hi, lookup
On Wednesday, 22 May 2019 at 00:55:37 UTC, Adam D. Ruppe wrote:
On Wednesday, 22 May 2019 at 00:22:09 UTC, JS wrote:
I am trying to create some fast sin, sinc, and exponential
routines to speed up some code by using tables... but it seems
it's slower than the function itself?!?
There's intrin
On 23.05.19 12:21, Alex wrote:
On Wednesday, 22 May 2019 at 00:55:37 UTC, Adam D. Ruppe wrote:
On Wednesday, 22 May 2019 at 00:22:09 UTC, JS wrote:
I am trying to create some fast sin, sinc, and exponential routines
to speed up some code by using tables... but it seems it's slower
than the fun
On Wednesday, 22 May 2019 at 00:22:09 UTC, JS wrote:
I am trying to create some fast sin, sinc, and exponential
routines to speed up some code by using tables... but it seems
it's slower than the function itself?!?
Not when I tried it with one of the online compilers, LUT is 3-4
times faster
On Wednesday, 22 May 2019 at 00:22:09 UTC, JS wrote:
xxx = 0;
sw.reset();
sw.start();
for(double i = 0; i < 1000; i++) xxx += sin(PI*i);
t = sw.peek().msecs;
writeln(t);
sw.stop();
}
What you are doing wrong is that xxx is never used..
On Thursday, 23 May 2019 at 15:20:22 UTC, Timon Gehr wrote:
On 23.05.19 12:21, Alex wrote:
On Wednesday, 22 May 2019 at 00:55:37 UTC, Adam D. Ruppe wrote:
On Wednesday, 22 May 2019 at 00:22:09 UTC, JS wrote:
I am trying to create some fast sin, sinc, and exponential
routines to speed up some c
On Thursday, 23 May 2019 at 19:17:40 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 22 May 2019 at 00:22:09 UTC, JS wrote:
xxx = 0;
sw.reset();
sw.start();
for(double i = 0; i < 1000; i++) xxx += sin(PI*i);
t = sw.peek().msecs;
writeln(t);
On Thursday, 23 May 2019 at 18:57:03 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 22 May 2019 at 00:22:09 UTC, JS wrote:
I am trying to create some fast sin, sinc, and exponential
routines to speed up some code by using tables... but it seems
it's slower than the function itself?!?
Not when
On Thursday, 23 May 2019 at 21:30:47 UTC, Alex wrote:
I don't see how that can necessarily be faster. A LUT can give
full 64-bit precision with one operation. The CORDIC needs
iteration, at least 10 to be of any use. LUT's are precision
independent assuming the creation cost is not included.
On Thursday, 23 May 2019 at 21:50:38 UTC, Alex wrote:
I've used very small LUT's like a length of 5 and it didn't
significantly change anything.
Use a size that is 2^n, then mask the index and hopefully that
will turn off bounds checks.
E.g. If LUT size is 16, then index the lut with "i&15"?
On Thursday, 23 May 2019 at 10:16:42 UTC, Alex wrote:
On Wednesday, 22 May 2019 at 08:25:58 UTC, Basile B. wrote:
On Wednesday, 22 May 2019 at 00:22:09 UTC, JS wrote:
I am trying to create some fast sin, sinc, and exponential
routines to speed up some code by using tables... but it
seems it's
On Friday, 24 May 2019 at 08:33:34 UTC, Ola Fosheim Grøstad wrote:
So the LUT is 3-4 times faster even with your quarter-LUT
overhead.
4-5 times faster actually, since I made the LUT size known at
compiletime.
On Thursday, 23 May 2019 at 21:47:45 UTC, Alex wrote:
Either way, sin it's still twice as fast. Also, in the code the
sinTab version is missing the writeln so it would have been
faster.. so it is not being optimized out.
Well, when I run this modified version:
https://gist.github.com/run-dlan
On Friday, 24 May 2019 at 08:33:34 UTC, Ola Fosheim Grøstad wrote:
https://gist.github.com/run-dlang/9f29a83b7b6754da98993063029ef93c
I made an error here:
"return s*((1 - f)*QuarterSinTab[ai&511] +
f*QuarterSinTab[(ai+1)&511]);"
Should of course be:
return s*((1 - f)*QuarterSinTab[ai&511
On Wednesday, 22 May 2019 at 00:22:09 UTC, JS wrote:
for(int i = 0; i < res; i++)
QuarterSinTab[i] = sin(PI*(i/cast(double)res));
Btw, I think this creates a half sine, not a quarter, so you want
(?):
QuarterSinTab[i] = sin(PI*(0.5*i/cast(double)res));
On Friday, 24 May 2019 at 08:33:34 UTC, Ola Fosheim Grøstad wrote:
On Thursday, 23 May 2019 at 21:47:45 UTC, Alex wrote:
Either way, sin it's still twice as fast. Also, in the code
the sinTab version is missing the writeln so it would have
been faster.. so it is not being optimized out.
Well,
On Friday, 24 May 2019 at 08:13:00 UTC, Basilez B. wrote:
On Thursday, 23 May 2019 at 10:16:42 UTC, Alex wrote:
On Wednesday, 22 May 2019 at 08:25:58 UTC, Basile B. wrote:
On Wednesday, 22 May 2019 at 00:22:09 UTC, JS wrote:
I am trying to create some fast sin, sinc, and exponential
routines t
On Friday, 24 May 2019 at 11:45:46 UTC, Ola Fosheim Grøstad wrote:
On Friday, 24 May 2019 at 08:33:34 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 23 May 2019 at 21:47:45 UTC, Alex wrote:
Either way, sin it's still twice as fast. Also, in the code
the sinTab version is missing the writeln so it
On Friday, 24 May 2019 at 11:57:44 UTC, Alex wrote:
On Friday, 24 May 2019 at 08:13:00 UTC, Basilez B. wrote:
On Thursday, 23 May 2019 at 10:16:42 UTC, Alex wrote:
On Wednesday, 22 May 2019 at 08:25:58 UTC, Basile B. wrote:
On Wednesday, 22 May 2019 at 00:22:09 UTC, JS wrote:
I am trying to cr
On Friday, 24 May 2019 at 12:01:55 UTC, Alex wrote:
Well, the QuarterWave was suppose to generate just a quarter
since that is all that is required for these functions due to
symmetry and periodicity. I started with a half to get that
working then figure out the sign flipping.
Sure, it is a t
On Friday, 24 May 2019 at 11:45:46 UTC, Ola Fosheim Grøstad wrote:
On Friday, 24 May 2019 at 08:33:34 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 23 May 2019 at 21:47:45 UTC, Alex wrote:
Either way, sin it's still twice as fast. Also, in the code
the sinTab version is missing the writeln so it
On Friday, 24 May 2019 at 12:24:02 UTC, Alex wrote:
So it seems like a quarter-wave LUT is 27 times faster than
sin…
If so then that is great and what I'd expected to achieve
originally.
I guess this is using LDC though? I wasn't able to compile with
LDC since after updating I'm getting l
On Friday, 24 May 2019 at 12:56:55 UTC, Ola Fosheim Grøstad wrote:
suggest above. Just beware that I haven't checked the code, so
it might be off by ±1 and such.
So before using such code for anything important, make sure that
it is tested for the edge cases, like denormal numbers (values
clo
On Friday, 24 May 2019 at 12:24:02 UTC, Alex wrote:
If it truly is a 27x faster then then that is very relevant and
knowing why is important.
Of course, a lot of that might simply be due to LDC and I
wasn't able to determine this.
Just one more thing you really ought to consider:
It isn't o
On Friday, 24 May 2019 at 11:45:46 UTC, Ola Fosheim Grøstad wrote:
const double sign =
cast(double)(-cast(uint)((mantissa>>63)&1));
Yep, this was wrong (0 or -1). Should be something like (1 or -1):
const double sign =
cast(double)(1-cast(uint)((mantissa>>62)&2));
You'll have to cod
This appears to get roughly the same results as sin(x):
__gshared double[512+1] QuarterSinTab;
void init(){
const auto res = QuarterSinTab.length-1;
for(int i = 0; i < res; i++)
QuarterSinTab[i] = sin(PI*(0.5*i/cast(double)res));
QuarterSinTab[$-1] = sin(PI*0.5);
}
With linear interpolation you get roughly the same result with
floats, a little more efficient too (half the memory and a bit
faster):
__gshared float[512+1] QuarterSinTab;
void init(){
const auto res = QuarterSinTab.length-1;
for(int i = 0; i < res; i++)
QuarterSinTab[i] = sin
On Friday, 24 May 2019 at 13:57:30 UTC, Ola Fosheim Grøstad wrote:
On Friday, 24 May 2019 at 12:24:02 UTC, Alex wrote:
If it truly is a 27x faster then then that is very relevant
and knowing why is important.
Of course, a lot of that might simply be due to LDC and I
wasn't able to determine t
On Friday, 24 May 2019 at 17:04:33 UTC, Alex wrote:
I'm not sure what the real precision of the build in functions
are but it shouldn't be hard to max out a double using standard
methods(even if slow, but irrelevant after the LUT has been
created).
LUTs are primarily useful when you use sin(x
On Friday, 24 May 2019 at 17:04:33 UTC, Alex wrote:
On Friday, 24 May 2019 at 13:57:30 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 24 May 2019 at 12:24:02 UTC, Alex wrote:
If it truly is a 27x faster then then that is very relevant
and knowing why is important.
Of course, a lot of that might s
On Friday, 24 May 2019 at 17:40:40 UTC, Ola Fosheim Grøstad wrote:
On Friday, 24 May 2019 at 17:04:33 UTC, Alex wrote:
I'm not sure what the real precision of the build in functions
are but it shouldn't be hard to max out a double using
standard methods(even if slow, but irrelevant after the LU
On Saturday, 25 May 2019 at 09:04:31 UTC, NaN wrote:
Its pretty common technique in audio synthesis.
Indeed. CSound does this.
What i've done in the past is store a table of polynomial
segments that were optimised with curve fitting.
That's an interesting solution, how do you avoid higher o
On Saturday, 25 May 2019 at 09:04:31 UTC, NaN wrote:
It's bit extra work to calculate the the waveform but actual
works out faster than having huge LUTs since you're typically
only producing maybe 100 samples in each interrupt callback
Another hybrid option when filling a buffer might be to fi
On Saturday, 25 May 2019 at 09:52:22 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 25 May 2019 at 09:04:31 UTC, NaN wrote:
Its pretty common technique in audio synthesis.
Indeed. CSound does this.
What i've done in the past is store a table of polynomial
segments that were optimised with curv
On Saturday, 25 May 2019 at 12:51:20 UTC, NaN wrote:
I used an evolutionary optimisation algorithm on the table all
at once. So you do a weighted sum of max deviation, and 1st and
2nd order discontinuity at the joins. And minimise that across
the table as a whole. It seemed you could massively
On Wednesday, 22 May 2019 at 00:22:09 UTC, JS wrote:
I am trying to create some fast sin, sinc, and exponential
routines to speed up some code by using tables... but it seems
it's slower than the function itself?!?
[...]
I'll just leave this here:
https://www.dannyarends.nl/Using%20CTFE%20i
On Saturday, 25 May 2019 at 14:58:25 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 25 May 2019 at 12:51:20 UTC, NaN wrote:
I used an evolutionary optimisation algorithm on the table all
at once. So you do a weighted sum of max deviation, and 1st
and 2nd order discontinuity at the joins. And mini
On Saturday, 25 May 2019 at 20:07:19 UTC, NaN wrote:
Its differential evolution, you can pretty much optimise
anything you can quantify.
http://www1.icsi.berkeley.edu/~storn/code.html
Thanks, they even have Python example code. Nice.
44 matches
Mail list logo
