Re: VOLK C++ core

[John Sallay]

If nothing else I think there is a lot of value in adding c++ wrappers to volk. I don't have a strong opinion on an underlying base of c or c++, but would like for it to be easier to use in c++. A common approach with other c libraries like zeromq is to make a header only c++ wrapper. This would take a lot less work to implement, but only provides some of the advantages you mention.

What version of c++ would you target? I would recommend c++20 so that you can define a concept for a vector like object to use as arguments to these functions (or at least a concept based wrapper)

On Tue, Dec 21, 2021, 5:21 AM Johannes Demel <demel@ant.uni-bremen.de> 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