On Tue, Dec 21, 2021 at 3:29 AM Marcus Müller <mmuel...@gnuradio.org> wrote:
> 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 > > > >
