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
>