Re: [VOLK] Release 2.5.1

2022-02-14 Thread Marcus Müller
Cursory glance at `git diff v2.5.0..v2.51 **/**.h` tells me you didn't change anything 
ABI-wise.


Cheers,
Marcus

On 14.02.22 13:38, Johannes Demel wrote:

Hi all,

while I did not run the ABI compliance checker to compare 2.5.0 vs 2.5.1 specifically, it 
is simple and can be done with this tool:

https://lvc.github.io/abi-compliance-checker/#ABI_Dumper
So far, we were able to keep the ABI compatible across VOLK 2.x.
Also, we didn't change any function signatures of existing functions.

It might be a worthwhile undertaking to add an ABI compliance checker to our CI.

The VOLK library is written in C. Here, we rely on C11. Also, we require cpu_features 
because detecting such features across systems and architectures is terribly difficult.


Then, the questions are: Why Boost, why C++17 at all?
We use tools around our library. The volk_profile utility and our tests are written in 
C++. Here, we need to write the profile results to a file. In the past, we used 
`boost::filesystem` to achieve this. `boost::filesystem` basically became part of C++17 
with `std::filesystem`. Thus, we use `std::filesystem` now.


Cheers
Johannes

On 13.02.22 12:08, Jeff Long wrote:

Fons - filesystem is used for the volk_profile utility.

Chris - do not assume ABI compatibility. A number of small things have changed in ".h" 
files.


On Sat, Feb 12, 2022 at 6:19 PM Chris Vine > wrote:


    On Sat, 12 Feb 2022 11:40:26 +0100
    Johannes Demel mailto:de...@ant.uni-bremen.de>> wrote:
 > Hi everyone!
 >
 > You can find the news at
    https://www.libvolk.org/release-v251.html
     as well.
 >
 > We have a new VOLK release! We are happy to announce VOLK v2.5.1! We
 > want to thank all contributors. This release wouldn't have been
    possible
 > without them.

    Hi,

    Is this ABI compatible with volk-2.5.0 (or put another way, if I
    upgrade from volk-2.5.0 will I need to recompile gnuradio)?

    Chris







Re: [VOLK] Release 2.5.1

2022-02-14 Thread Johannes Demel

Hi all,

while I did not run the ABI compliance checker to compare 2.5.0 vs 2.5.1 
specifically, it is simple and can be done with this tool:

https://lvc.github.io/abi-compliance-checker/#ABI_Dumper
So far, we were able to keep the ABI compatible across VOLK 2.x.
Also, we didn't change any function signatures of existing functions.

It might be a worthwhile undertaking to add an ABI compliance checker to 
our CI.


The VOLK library is written in C. Here, we rely on C11. Also, we require 
cpu_features because detecting such features across systems and 
architectures is terribly difficult.


Then, the questions are: Why Boost, why C++17 at all?
We use tools around our library. The volk_profile utility and our tests 
are written in C++. Here, we need to write the profile results to a 
file. In the past, we used `boost::filesystem` to achieve this. 
`boost::filesystem` basically became part of C++17 with 
`std::filesystem`. Thus, we use `std::filesystem` now.


Cheers
Johannes

On 13.02.22 12:08, Jeff Long wrote:

Fons - filesystem is used for the volk_profile utility.

Chris - do not assume ABI compatibility. A number of small things have 
changed in ".h" files.


On Sat, Feb 12, 2022 at 6:19 PM Chris Vine > wrote:


On Sat, 12 Feb 2022 11:40:26 +0100
Johannes Demel mailto:de...@ant.uni-bremen.de>> wrote:
 > Hi everyone!
 >
 > You can find the news at
https://www.libvolk.org/release-v251.html
 as well.
 >
 > We have a new VOLK release! We are happy to announce VOLK v2.5.1! We
 > want to thank all contributors. This release wouldn't have been
possible
 > without them.

Hi,

Is this ABI compatible with volk-2.5.0 (or put another way, if I
upgrade from volk-2.5.0 will I need to recompile gnuradio)?

Chris





Re: [VOLK] Release 2.5.1

2022-02-13 Thread Jeff Long
Fons - filesystem is used for the volk_profile utility.

Chris - do not assume ABI compatibility. A number of small things have
changed in ".h" files.

On Sat, Feb 12, 2022 at 6:19 PM Chris Vine  wrote:

> On Sat, 12 Feb 2022 11:40:26 +0100
> Johannes Demel  wrote:
> > Hi everyone!
> >
> > You can find the news at https://www.libvolk.org/release-v251.html as
> well.
> >
> > We have a new VOLK release! We are happy to announce VOLK v2.5.1! We
> > want to thank all contributors. This release wouldn't have been possible
> > without them.
>
> Hi,
>
> Is this ABI compatible with volk-2.5.0 (or put another way, if I
> upgrade from volk-2.5.0 will I need to recompile gnuradio)?
>
> Chris
>
>


Re: [VOLK] Release 2.5.1

2022-02-12 Thread Chris Vine
On Sat, 12 Feb 2022 11:40:26 +0100
Johannes Demel  wrote:
> Hi everyone!
> 
> You can find the news at https://www.libvolk.org/release-v251.html as well.
> 
> We have a new VOLK release! We are happy to announce VOLK v2.5.1! We 
> want to thank all contributors. This release wouldn't have been possible 
> without them.

Hi,

Is this ABI compatible with volk-2.5.0 (or put another way, if I
upgrade from volk-2.5.0 will I need to recompile gnuradio)?

Chris



Re: [VOLK] Release 2.5.1

2022-02-12 Thread Fons Adriaensen
On Sat, Feb 12, 2022 at 11:40:26AM +0100, Johannes Demel wrote:

> In the past, we relied on Boost for several tasks in `volk_profile`. For
> years, we minimized Boost usage to `boost::filesystem`. We mostly switched
> to C++17 `std::filesystem` years ago. The last distribution in our CI system
> that required Boost to build VOLK, was Ubuntu 14.04. Thus, now is the time
> to remove the Boost dependency completely and rely on C++17 features.

I am not (yet) a user of VOLK, but interested. One thing that usually
puts me off when considering to use a library is excessive dependencies.

This may be a very naive question but I hope you can provide an answer.

Why does a library that provides numerical procedures using vector
instructions require anything from boost or C++17 ?  Or even file
operations at all ?

Even if this is just a build time dependency it seems odd... 

Ciao,

-- 
FA






[VOLK] Release 2.5.1

2022-02-12 Thread Johannes Demel

Hi everyone!

You can find the news at https://www.libvolk.org/release-v251.html as well.

We have a new VOLK release! We are happy to announce VOLK v2.5.1! We 
want to thank all contributors. This release wouldn't have been possible 
without them.


The list of contributors is pretty long this time due to a lot of 
support to relicense VOLK under LGPL. Currently, we are "almost there" 
but need a few more approvals, please support us. We thank everyone for 
their support in this effort.


We use `cpu_features` for a while now. This maintainance release should 
make it easier for package maintainers, FreeBSD users, and M1 users to 
use VOLK. Package maintainers should be able to use an external 
`cpu_features` module. For everyone else, `cpu_features` received 
support for M1 and FreeBSD.


You can find [VOLK on Zenodo DOI: 
10.5281/zenodo.3360942](https://doi.org/10.5281/zenodo.3360942).
We started to actively support Zenodo now via a `.zenodo.json` file. 
This might come in handy for people who use VOLK in publications. As a 
contributor, if you want more information about yourself added to VOLK, 
feel free to add your ORCiD and affiliation.


In the past, we relied on Boost for several tasks in `volk_profile`. For 
years, we minimized Boost usage to `boost::filesystem`. We mostly 
switched to C++17 `std::filesystem` years ago. The last distribution in 
our CI system that required Boost to build VOLK, was Ubuntu 14.04. Thus, 
now is the time to remove the Boost dependency completely and rely on 
C++17 features.


Some VOLK kernels are untested for years. We decided to deprecate these 
kernels but assume that nobody uses them anyways. If your compiler spits 
out a warning that you use a deprecated kernel, get in touch. Besides, 
we received fixes for various kernels. Especially FEC kernels are 
notoriously difficult to debug because issues often pop up as 
performance regressions.


Finally, we saw a lot of housekeeping in different areas. Scripts to 
support us in our LGPL relicensing effort, updated docs, and updated our 
code of conduct. We could remove some double entries in our QA system 
and fixed a `volk_malloc` bug that ASAN reported.
Finally, we switched to the Python `sysconfig` module in our build 
system to ensure Python 3.12+ does not break our builds.




### Contributors

* A. Maitland Bottoms 
* Aang23 
* AlexandreRouma 
* Andrej Rode 
* Ben Hilburn 
* Bernhard M. Wiedemann 
* Brennan Ashton 
* Carles Fernandez 
* Clayton Smith 
* Doug 
* Douglas Anderson 
* Florian Ritterhoff 
* Jaroslav Škarvada 
* Johannes Demel 
* Josh Blum 
* Kyle A Logue 
* Luigi Cruz 
* Magnus Lundmark 
* Marc L 
* Marcus Müller 
* Martin Kaesberger 
* Michael Dickens 
* Nathan West 
* Paul Cercueil 
* Philip Balister 
* Ron Economos 
* Ryan Volz 
* Sylvain Munaut 
* Takehiro Sekine 
* Vanya Sergeev 
* Vasil Velichkov 
* Zlika 
* namccart 
* dernasherbrezon 
* rear1019 


### Changes

* Kernels
- Fixup underperforming GENERIC kernel for volk_8u_x4_conv_k7_r2_8u
- volk_32fc_x2_conjugate_dot_prod_32fc: New generic implementation
- Add volk_32f(c)_index_min_16/32u
- Fix volk_32fc_index_min_32u_neon
- Fix volk_32fc_index_min_32u_neon

* Misc
- Fix volk_malloc alignment bug
- qa: Remove repeating tests
- python: Switch to sysconfig module
- deprecate: Add attribute deprecated
- deprecate: Exclude warnings on Windows
- docs: Update docs
- Add the list of contributors agreeing to LGPL licensing
- Add a script to count the lines that are pending resubmission
- Testing: Add test for LGPL licensing
- Update CODE_OF_CONDUCT file

* Boost
- boost: Remove boost dependency
- c++: Require C++17 for std::filesystem

* cpu_features
  cpu_features: Update submodule pointer
  cpu_features: Make cpu_features submodule optional

* Zenodo
  zenodo: Add metadata file
  zenodo: Re-organize .zenodo.json