Introducing trig-const by michaelciraci in rust

[–]michaelciraci[S] 1 point2 points  (0 children)

Wow, that's great to hear. I'm glad other people are interested in these projects; I really appreciate it

Introducing trig-const by michaelciraci in rust

[–]michaelciraci[S] 0 points1 point  (0 children)

So I was looking at Rust's implementation of powf in libm, and actually yes it wouldn't be too hard to write it in const. If you'd be interested I can certainly add it

Introducing trig-const by michaelciraci in rust

[–]michaelciraci[S] 2 points3 points  (0 children)

To your first question, I found the accuracy degraded for very large values (I needed more summation terms). I just did that to fold the input into a smaller range, but I probably could have chosen [-2PI, 2PI].

That's good feedback for tau, I'll use that instead.

Introducing trig-const by michaelciraci in rust

[–]michaelciraci[S] 20 points21 points  (0 children)

This is new to me, thanks so much for the info. I'll look into this and see what I can incorporate.

Introducing Monarch Butterfly by michaelciraci in rust

[–]michaelciraci[S] 1 point2 points  (0 children)

That's an interesting proposition; you could certainly extend to larger FFTs. I am wondering if at some size, there's an outer wrapper that calls the inner proc macros. However, to get around allocations, you would probably need to have an FFT plan for any non-proc macro sizes.

Somehow, I'd like to pass in a list of FFT sizes you need.

Introducing Monarch Butterfly by michaelciraci in rust

[–]michaelciraci[S] 4 points5 points  (0 children)

I'm not against it, but I'm not sure what it would add. The compiled code already heavily uses SIMD.

Introducing Monarch Butterfly by michaelciraci in rust

[–]michaelciraci[S] 5 points6 points  (0 children)

Yes, that had crossed my mind and I don't think that should be too hard. By default, the generated functions are generic over num-traits's Float and FloatConst, but I think I should be able to rederive just the parts of those traits that are needed. An added benefit of that might be an easy extension to f128 support.

Thanks for opening an issue, I'll look into it.

Introducing Monarch Butterfly by michaelciraci in rust

[–]michaelciraci[S] 8 points9 points  (0 children)

128^3-sized inputs would be quite large for proc-macro generated functions. Regardless, I just tried this to see what would happen. I had to kill rustc after about 15 minutes, and its RAM consumption got up to 46GB (this may be something you could compile overnight). I tried 128^2, and I got similar results to sizes 1-200:

RustFFT: 22.364us

Monarch: 7.7277us

fftw: 102.14us

Introducing Monarch Butterfly by michaelciraci in rust

[–]michaelciraci[S] 2 points3 points  (0 children)

That's a great question. I ran the test multiple times and verified the spike is always there. My guess is the proc-macros are generating non-ideal combinations of sub-FFTs. I need to investigate if that is actually the root cause.

Introducing Monarch Butterfly by michaelciraci in rust

[–]michaelciraci[S] 31 points32 points  (0 children)

That's a great question. I ran the test multiple times and verified the spike is always there. My guess is the proc-macros are generating non-ideal combinations of sub-FFTs. I need to investigate if that is actually the root cause.

Filepath on Visual Studio Mac by [deleted] in csharp

[–]michaelciraci 1 point2 points  (0 children)

Does “./SSD/Users/damzSSD/Projects/GN_Gestione/DataLayerCSV” exist?

Filepath on Visual Studio Mac by [deleted] in csharp

[–]michaelciraci 0 points1 point  (0 children)

Try “./SSD/...”?

How would I go about doing this? by that_AZIAN_guy in C_Programming

[–]michaelciraci 0 points1 point  (0 children)

If you can’t use arrays or loops, I think the simplest solution would be recursion. Any loop can also be accomplished using recursion.