[R-pkg-devel] using portable simd instructions

[Serguei Sokol]

Le 27/03/2024 à 14:54, jesse koops a écrit :
> I tried that but I found the interface awkward and there was really no
> performance bonus. It was in the early phase of experimentation and I
> didn't save it, so it could very well be that I got the compiler
> settings wrong and simd was not used. But if that was the case, there
> would still be the problem of using the correct compiler settings
> cross platform.
When I compile the example of the cited page with "authorized" flag "-std":

    g++ -std=c++20 stdx_simd.cpp -o tmp.exe

then I do:

    objdump -d tmp.exe > tmp.asm

I do find simd instructions in assembler code, e.g.:

    grep paddd tmp.asm

     14a8:	66 0f fe c1          	paddd  %xmm1,%xmm0
     8f7b:	66 0f fe c1          	paddd  %xmm1,%xmm0

> 
> Op wo 27 mrt 2024 om 14:44 schreef Serguei Sokol <serguei.sokol using gmail.com>:
>>
>> Le 26/03/2024 à 15:51, Tomas Kalibera a écrit :
>>>
>>> On 3/26/24 10:53, jesse koops wrote:
>>>> Hello R-package-devel,
>>>>
>>>> I recently got inspired by the rcppsimdjson package to try out simd
>>>> registers. It works fantastic on my computer but I struggle to find
>>>> information on how to make it portable. It doesn't help in this case
>>>> that R and Rcpp make including Cpp code so easy that I have never had
>>>> to learn about cmake and compiler flags. I would appreciate any help,
>>>> including of the type: "go read instructions at ...".
>>>>
>>>> I use RcppArmadillo and Rcpp. I currenlty include the following header:
>>>>
>>>> #include <immintrin.h>
>>>>
>>>> The functions in immintrin that I use are:
>>>>
>>>> _mm256_loadu_pd
>>>> _mm256_set1_pd
>>>> _mm256_mul_pd
>>>> _mm256_fmadd_pd
>>>> _mm256_storeu_pd
>>>>
>>>> and I define up to four __m256d registers. From information found
>>>> online (not sure where anymore) I constructed the following makevars
>>>> file:
>>>>
>>>> CXX_STD = CXX14
>>>>
>>>> PKG_CPPFLAGS = -I../inst/include -mfma -msse4.2 -mavx
>>>>
>>>> PKG_CXXFLAGS = $(SHLIB_OPENMP_CXXFLAGS)
>>>> PKG_LIBS = $(SHLIB_OPENMP_CXXFLAGS) $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)
>>>>
>>>> (I also use openmp, that has always worked fine, I just included all
>>>> lines for completeness) Rcheck gives me two notes:
>>>>
>>>> ─  using R version 4.3.2 (2023-10-31 ucrt)
>>>> ─  using platform: x86_64-w64-mingw32 (64-bit)
>>>> ─  R was compiled by
>>>>          gcc.exe (GCC) 12.3.0
>>>>          GNU Fortran (GCC) 12.3.0
>>>>
>>>> ❯ checking compilation flags used ... NOTE
>>>>     Compilation used the following non-portable flag(s):
>>>>       '-mavx' '-mfma' '-msse4.2'
>>>>
>>>> ❯ checking C++ specification ... NOTE
>>>>       Specified C++14: please drop specification unless essential
>>>>
>>>> But as far as I understand, the flags are necessary, at least in GCC.
>>>> How can I make this portable and CRAN-acceptable?
>>>
>>> I think it the best way for portability is to use a higher-level library
>>> that already has done the low-level business of maintaining multiple
>>> versions of the code (with multiple instruction sets) and choosing one
>>> appropriate for the current CPU. It could be say LAPACK, BLAS, openmp,
>>> depending of the problem at hand.
>> Talking about libraries, may be the
>> https://en.cppreference.com/w/cpp/experimental/simd will do the job?
>>
>> Best,
>> Serguei.
>>
>>    In some cases, code can be rewritten
>>> so that the compiler can vectorize it better, using the level of
>>> vectorized instructions that have been enabled.
>>>
>>> Unconditionally using GCC-specific or architecture-specific options in
>>> packages would certainly not be portable. Even on Windows, R is now used
>>> also with clang and on aarch64, so one should not assume a concrete
>>> compiler and architecture.
>>>
>>> Please note also that GCC on Windows has a bug due to which AVX2
>>> instructions cannot be used reliably - the compiler doesn't always
>>> properly align local variables on the stack when emitting these. See
>>> [1,2] for more information.
>>>
>>> Best
>>> Tomas
>>>
>>> [1] https://stat.ethz.ch/pipermail/r-sig-windows/2024q1/000113.html
>>> [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412
>>>
>>>>
>>>> kind regards,
>>>> Jesse
>>>>
>>>> ______________________________________________
>>>> R-package-devel using r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>>
>>> ______________________________________________
>>> R-package-devel using r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>