Support for Highway SIMD?

[ErichZimmer]

Preface

Google Highway provides a short and concise solution for targeting SIMD on multiple platforms. Although Highway supports dynamic dispatching, the main area of research is static dispatching via compiler flags. This enables the use of vector extensions using MSVC among others that do not support or have limited support of GNU GCC vector extensions. Additionally, Highway is also c++11 compliant.

Context

I think adding a port for Highway vector extensions would be nice since it allows for a more consistent and extensive SIMD experience. Unfortunately, it appears that a significant chunk of code may need to be rewritten to allow for Highway's vector extensions. Although I am willing to put in effort on my behalf to get a working solution, my knowledge of how your version of pocketfft works and how to change the SIMD instructions is limited. This means that I would more than likely need help since you would undoubtedly have more knowledge on the implementation details.

Alternatives

Do nothing.

[mreineck]

Thank you for the suggestion!

I'm not totally sure whether this would be worth the effort, since pocketfft is basically in maintenance mode and has been superseded by the FFT component of https://github.com/mreineck/ducc (this is now used by JAX, for example). The ducc FFT has almost te same interface as pocketfft, but it no longer relies on gcc vector extensions, but uses the interface proposed by https://en.cppreference.com/w/cpp/experimental/simd, which hopefully will be adopted by standard C++ soon. At least gcc already supports this, and for other compilers I have written an emulation layer which appears to do a decent job. The relevant code is in https://github.com/mreineck/ducc/blob/ducc0/src/ducc0/infra/simd.h, I cannot say how well this performs with MSVC, but I hope this functionality will be integrated in the compiler sooner or later. Do you think this could address your requirements as well?

[ErichZimmer]

Hmm... I wonder if the ducc version of pocketfft can be Jerry-rigged to use Highway? One of the main reason why I plan on using Highway for SIMD support is because I plan on implementing a custom linalg library for particle image velocimetry (PIV), more specifically for the OpenPIV organization. However, I must admit that I do not know much about the experimental SIMD module from the c++ standard library. Perhaps, I will investigate into it further as long as it supports c++17 (the version of c++ that I will be using for the current projects). Or, I could also include an optional FFTW-f port for the Windows folks since Windows is the only offending OS that is currently causing issues (mostly due to Microsoft license restrictions for their runtime library import libs which causes limited support for third-party compilers).

[mreineck]

I think the chances are quite good for using Highway as a "backend"; in principle all that's needed is listed atthe bottom of simd.h:

using detail_simd::element_aligned_tag;
using detail_simd::native_simd;
using detail_simd::simd_select;
using detail_simd::simd_exists;
using detail_simd::vectorizable;

Of course, all the required semantics need to be there ... but I think this is much easier to achieve than adjusting the original pocketfft.