Closed xloem closed 4 years ago
There are certainly advantages if we'd move to C++. At the moment VOLK kernels etc. are written in C. In essence libvolk
can be used with C. Only some tools are written in C++. Your proposal implies a major shift. How would we maintain a C API?
One could make a C-language header file with C++ language implementation. The work here is highly conducive to templates, and projects like e.g. armadillo are inspiring to me for something so modular as gnuradio. But this issue does seem a little out of scope and you should feel free to close.
I can think of a few ways to use C++ templates that would be interesting and useful, but doing so would pretty much re-write Volk kernels to handle both the transition to C++ as well as the templates. That's not going to happen any time soon at least by me! While I like the concept, it's really not what Volk is about. Thanks for the suggestion!
Just want to add that instead of (in addition of) templates, the use of C++ lambda functions would be beneficial in order to use (hopefully) "zero-cost" abstractions, i.e., code which is completely optimized away by the compiler.
As an example, Intel SIMD kernels for aligned and unaligned memory access differ in only a few lines...
@hcab14 that's true. It would be interesting to see how far Volk programming could be stripped down by moving to a modern C++ standard & then making use of fun features such as templates and lambda functions. I don't have time to do this any time soon. If others do, I'd suggest doing just 2 kernels to show off the functionality, then creating a "WIP" PR to show off what's what. I'm not against doing this, but I know it would be a huge change for Volk & so it would take significant work, which mean significant time ...
VOLK would strongly benefit from beginning to migrate to C++ and templates.
This would radically reduce code duplication, improving maintainability, and allow far more complex parameterization of optimization options, increasing ability to inline and unroll loops. The number of kernels could increase due to the ease of instantiating new versions with slight changes.
EDIT: There might be existing libraries out there, already doing the above, that it could be good to consolidate work with.