Re: Performance of tables slower than built in?

2019-05-25 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
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.

Re: Performance of tables slower than built in?

2019-05-25 Thread NaN via Digitalmars-d-learn
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

Re: Performance of tables slower than built in?

2019-05-25 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
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

Re: Performance of tables slower than built in?

2019-05-25 Thread Danny Arends via Digitalmars-d-learn
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:

Re: Performance of tables slower than built in?

2019-05-25 Thread NaN via Digitalmars-d-learn
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

Re: Performance of tables slower than built in?

2019-05-25 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
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

Re: Performance of tables slower than built in?

2019-05-25 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
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

Re: Performance of tables slower than built in?

2019-05-25 Thread NaN via Digitalmars-d-learn
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

Re: Performance of tables slower than built in?

2019-05-25 Thread NaN via Digitalmars-d-learn
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

Re: Performance of tables slower than built in?

2019-05-24 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
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

Re: Performance of tables slower than built in?

2019-05-24 Thread Alex via Digitalmars-d-learn
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

Re: Performance of tables slower than built in?

2019-05-24 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
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] =

Re: Performance of tables slower than built in?

2019-05-24 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
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); }

Re: Performance of tables slower than built in?

2019-05-24 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
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

Re: Performance of tables slower than built in?

2019-05-24 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
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

Re: Performance of tables slower than built in?

2019-05-24 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
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

Re: Performance of tables slower than built in?

2019-05-24 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
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

Re: Performance of tables slower than built in?

2019-05-24 Thread Alex via Digitalmars-d-learn
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

Re: Performance of tables slower than built in?

2019-05-24 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
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

Re: Performance of tables slower than built in?

2019-05-24 Thread Alex via Digitalmars-d-learn
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

Re: Performance of tables slower than built in?

2019-05-24 Thread Alex via Digitalmars-d-learn
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

Re: Performance of tables slower than built in?

2019-05-24 Thread Alex via Digitalmars-d-learn
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

Re: Performance of tables slower than built in?

2019-05-24 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
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.

Re: Performance of tables slower than built in?

2019-05-24 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
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));

Re: Performance of tables slower than built in?

2019-05-24 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
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 -

Re: Performance of tables slower than built in?

2019-05-24 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
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:

Re: Performance of tables slower than built in?

2019-05-24 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
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.

Re: Performance of tables slower than built in?

2019-05-24 Thread Basilez B. via Digitalmars-d-learn
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

Re: Performance of tables slower than built in?

2019-05-23 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
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

Re: Performance of tables slower than built in?

2019-05-23 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
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.

Re: Performance of tables slower than built in?

2019-05-23 Thread Alex via Digitalmars-d-learn
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

Re: Performance of tables slower than built in?

2019-05-23 Thread Alex via Digitalmars-d-learn
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);

Re: Performance of tables slower than built in?

2019-05-23 Thread Alex via Digitalmars-d-learn
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

Re: Performance of tables slower than built in?

2019-05-23 Thread Ola Fosheim Grøstad via Digitalmars-d-learn
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

Re: Performance of tables slower than built in?

2019-05-23 Thread Timon Gehr via Digitalmars-d-learn
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

Re: Performance of tables slower than built in?

2019-05-23 Thread Alex via Digitalmars-d-learn
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

Re: Performance of tables slower than built in?

2019-05-23 Thread Alex via Digitalmars-d-learn
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,

Re: Performance of tables slower than built in?

2019-05-22 Thread Basile B. via Digitalmars-d-learn
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,

Re: Performance of tables slower than built in?

2019-05-22 Thread Basile B. via Digitalmars-d-learn
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

Re: Performance of tables slower than built in?

2019-05-21 Thread matheus via Digitalmars-d-learn
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

Re: Performance of tables slower than built in?

2019-05-21 Thread rikki cattermole via Digitalmars-d-learn
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

Re: Performance of tables slower than built in?

2019-05-21 Thread Adam D. Ruppe via Digitalmars-d-learn
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

Performance of tables slower than built in?

2019-05-21 Thread JS via Digitalmars-d-learn
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