GSoC writeup report
ckormanyos opened this issue · comments
Hi @ckormanyos. The report will not be included in boostorg/math, I think is not a good idea to write it in this repository. If we do so, then the report would have to be discarded by hand during merging. Is is ok with you if we write the report on a dedicated repository?
Is is ok with you if we write the report on a dedicated repository?
Sure Eduardo. Hi @Lagrang3 of course the report can be wherever you prefer. A separate repo is a great idea.
Basically the existence of the report and some small amount of sensible content is key in this particular issue.
That seems like a good location. If anyone complains, we can talk again. Maybe some others might even use a similar idea.
@ckormanyos, @cosurgi: first draft version is out
first draft version
Hello @Lagrang3 this is a great draft Eduardo. I really like the content which includes both theoretical aspects as well as interface details.
Just a few really minor suggestions...
In the preliminary chapter Implementation, I would encourage you to be rather terse and short instead of long and detailed, favoring brevity. I might suggest to rename that chapter to Implementation Details or Design Details accordingly, and keep it rather terse and fast-paced.
For the benchmarks, I would suggest one or at most two FFT forms available in all three backend types (BSL, FFTW, GLS) and show how these compare with each other. We can stress that the BSL version is at this stage very rudimentary and has not been subjected to dedicated optimization efforts or development activities of that kind.
The appoendix on Abstract Ring is in my opinion optional. Honestly, I am weak on that theory and, although I need such theory, this might not be the best place to spend time on its discourse. I consider a brief paragraph or two OK, but please I recommend save your time on that particular discourse.
Nice Work!
This draft looks really good! I will take time to read it carefully and report back.
@cosurgi, @ckormanyos:I produced some benchmarks for real and std::complex<double> transforms using the three backends with enforcing the various algorithms by choosing different sizes (powers of 2, powers of 10 and prime numbers), shown in the draft in the page with the six plots. Would you like me to include other benchmarks? Suggestions?
If we choose other complex types we have to leave out the GSL backend.
One comparison I have in mind is the real vs complex for our BSL backend, to see whether there's actually a factor of 2 in performance. And maybe do a benchmark of Number Theoretical Transform for different powers of 2 up to 10^6 to see how it scales.
I've just published a complete version of the report. It is not necessarily the final. See here.
@ckormanyos, @cosurgi: by the way. This week I was cleaning up the code a bit, adding or extending the examples and all this work is found is PR #28. However, the MSCV tests are failing. Can you help me figure out the problem so that we can merge these changes?
just published a complete version of the report
It is a fantastic report that summarizes your truly excellent work in GSoC '21. You can be very proud of these ground-breaking steps toward FFT in Boost. Good job, Eduardo!
the MSCV tests are failing. Can you help me figure out the problem
I will take a look and report what I find...
Cc: @cosurgi
@ckormanyos. Thanks
I fully agree with @ckormanyos , this report is so good, that when reading it I only found a couple of typos:
page 4, 3.3. missing 't': "Very of(t)en"
page 5, 3.4. missing 'e' "On(e) reason"
page 6, missing 'n' "once w is know(n) there are"
And only one remark on page 7 : "cpp_complex_50, cpp_complex_quad and mpc_complex_50" are just examples of handled cpp_complex types (based on cpp_bin_float real type), we also handle mpc_complex family based on mpfr real type.
Great work @Lagrang3 !
@cosurgi: can I write it like this: ?
"bsl_dft can handle, for instance besides the previously mentioned complex types, also the family of boost::multiprecision::cpp_complex and boost::multiprecision::mpc_complex based on cpp_bin_float and mpfr real types respectively; eg. cpp_complex_50, cpp_complex_quad and mpc_complex_50."
yes, it is perfect.
Small correction: the full name for mpfr is mpfr_float_backend.
Done. Thanks.
Hi uploaded a new version, with the text corrections suggested by Janek. Also in table 2. I added a column with the relative speedup of real vs complex algorithms, and in figure 2 I fixed the values of the time, they where in units of ns, instead of ms as the label shows.