Hi Johannes,
I, for one, like it :) Especially since I honestly find void
volk_32fc_x2_s32fc_multiply_conjugate_add_32fc to be a teeny tiny bit clunky and would
rather call a type-safe, overloaded function in a volk namespace called
multiply_conjugate_add.
Yes, that's kind of my fault. It was the best option we could come up with to be rigorously type-specific in C, kind of a bespoke implementation of name mangling. The original motivation, of course, was the VOLK dispatcher. C was a hard requirement at the time, and I confess I don't remember why. I think it came down from namccart's original donation of vectorized code.
I would be very happy to see VOLK move to C++ (or at least provide wrappers). I strongly advocate for using C++20 -- std::span, variadic arguments, lambdas etc. seem tailor-made for VOLK. Runtime dispatching could be positively elegant, compared to how it must be done in C. And C++20 finally makes C++ a much less Lovecraftian nightmare of a language than the one I learned from Stroustrop.
Nick
Re: RFC: can we have something like a wiki page (maybe on the VOLK repo?) to collect these
comments?
You mention spans, so C++-VOLK would be >= C++20?
Cheers,
Marcus
On 21.12.21 10:55, Johannes Demel wrote:
> Hi everyone,
>
> today I'd like to propose an idea for the future of VOLK. Currently, VOLK is a C library
> with a C++ interface and tooling that is written in C++.
>
> I propose to make VOLK a C++ library. Similar to e.g. UHD, we can add a C interface if
> the need arises.
>
> This email serves as a request for comments. So go ahead.
>
> Benefits:
> - sane std::complex interface.
> - same compilation mode on all platforms.
> - Better dynamic kernel load management.
> - Option to use std::simd in the future
> - Less manual memory management (think vector, ...).
>
> Drawbacks:
> - It is a major effort.
> - VOLK won't be a C project anymore.
>
> Why do I propose this shift?
> VOLK segfaults on PowerPC architectures. This issue requires a breaking API change to be
> fixable. I tried to update the API to fix this isse.
> https://github.com/gnuradio/volk/pull/488
> It works with GCC and Clang but fails on MSVC.
> One might argue that PowerPC is an obscure architecture at this point but new
> architectures might cause the same issue in the future. Also, VOLK tries to be portable
> and that kind of issue is a serious roadblock.
>
> How did we get into this mess?
> The current API is a workaround to make things work for a specific compiler: MSVC. MSVC
> does not support C `complex.h` at all. The trick to make things work with MSVC is:
> compile VOLK in C++ mode and pretend it is a C++ library anyways.
> In turn `volk_complex.h` defines complex data types differently depending if VOLK is
> included in C or C++. Finally, we just hope that the target platform provides the same
> ABI for C complex and C++ complex. C complex and C++ complex are not compatible.
> However, passing pointers around is.
> Thus, the proposed change does not affect Windows/MSVC users because they were excluded
> from our C API anyways. The bullet point: "same compilation mode on all platforms"
> refers to this issue.
>
> Proposed timeline:
> Together with our re-licensing effort, we aim for a VOLK 3.0 release. VOLK 3.0 is a good
> target for breaking API changes.
>
> Effects:
> I'd like to make the transition to VOLK 3.0 as easy as possible. Thus, I'd like to keep
> an interface that hopefully doesn't require any code changes for VOLK 2.x users. A
> re-built of your application should be sufficient. However, we'd be able to adopt a
> C++-ic API as well. e.g. use vectors, spans etc.
>
> The current implementation to detect and load the preferred implementation at runtime is
> hard to understand and easy to break. C++ should offer more accessible tools to make
> this part easier.
>
> What about all the current kernels?
> We'd start with a new API and hide the old kernel code behind that interface. We come up
> with a new implementation structure and how to load it. Thus, we can progressively
> convert to "new-style" implementations.
>
> Another bonus: std::simd
> Currently, std::simd is a proposal for C++23. Making VOLK a C++ lib would allow us to
> eventually use std::simd in VOLK and thus make Comms DSP algorithms more optimized on
> more platforms.
>
> Cheers
> Johannes
>