### Re: Performance of tables slower than built in?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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?

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