Re: VOLK C++ core

True, but with Pybind11, we at least get direct python->C++ bindings which *can* allow for
in-place modification of appropriately typed numpy arrays. For other languages, the C
layer should be pretty much a zero-overhead redirection (or so I hope), just like it's
theoretically useful right now.


On 21.12.21 16:08, Albin Stigö wrote:
> I like the idea. It will make it difficult to use volk with other language's FFI though.
>
> --Albin
>
> On Tue, Dec 21, 2021, 12:27 Marcus Müller <mmueller@gnuradio.org
> <mailto:mmueller@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.
>
> 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 <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
> >
>