NSIMD generates too much assembly about nsimd

[eschnett]

I believe you are misunderstanding the "length" argument of a pack. You should probably set it to 1 (not 4) to create a pack that has the natural size for your architecture. Choosing a larger value allows setting up SIMD vectors with a length that is a multiple of the natural hardware vector length. In other words, your nsimd examples are working on 16 elements, not just 4, and the code is thus much longer than expected. You are also seeing a lot of code related to loading and storing function arguments from and to the stack; these instructions will go away if the function is inlined, or is used inside a larger function.

I usually just use pack<double>, without specifying the length. The SIMD length is chosen automatically by nsimd.

As a test, you can evaluate sizeof(pack<float, 4>).

[raphaelthegreat]

I believe you are misunderstanding the "length" argument of a pack. You should probably set it to 1 (not 4) to create a pack that has the natural size for your architecture. Choosing a larger value allows setting up SIMD vectors with a length that is a multiple of the natural hardware vector length. In other words, your nsimd examples are working on 16 elements, not just 4, and the code is thus much longer than expected. You are also seeing a lot of code related to loading and storing function arguments from and to the stack; these instructions will go away if the function is inlined, or is used inside a larger function.

I usually just use pack<double>, without specifying the length. The SIMD length is chosen automatically by nsimd.

As a test, you can evaluate sizeof(pack<float, 4>).

Thanks for pointing it out. The code looks much cleaner now. But if size of the vector depends on the architecture provided, is there any cross platform way of defining the size? In addition, though, I have been facing numerous build errors on compilers that aren't GCC when using the nsimd::cvt function. For example:

GCC

Clang

MSVC

[eschnett]

I am not aware of a way to define the SIMD vector size. The suggested approach is to let nsimd choose the optimal vector length, and then to inquire the actual vector length at compile time. This allows efficient loop vectorization when traversing arrays in loops.

I am not encountering any such errors. I uses nsimd regularly, on various systems. I usually build with GCC 11.2 (as you do), and I specify -std=c++17 as well.

Most SIMD hardware works on a fixed number of bits. Thus converting from 4xi32 to 4xi16 is not a natural operation. The natural operation would generate an 8xi16 vector, presumably from two 4xi32 inputs. Maybe you need to use downcvt instead of cvt?

[raphaelthegreat]

I am not aware of a way to define the SIMD vector size. The suggested approach is to let nsimd choose the optimal vector length, and then to inquire the actual vector length at compile time. This allows efficient loop vectorization when traversing arrays in loops.

I am not encountering any such errors. I uses nsimd regularly, on various systems. I usually build with GCC 11.2 (as you do), and I specify -std=c++17 as well.

Most SIMD hardware works on a fixed number of bits. Thus converting from 4xi32 to 4xi16 is not a natural operation. The natural operation would generate an 8xi16 vector, presumably from two 4xi32 inputs. Maybe you need to use downcvt instead of cvt?

What I want to do is take each element of the int32 vector and cast it down to int16 without reducing the vector size (in elements). With intrinsics this can be done to my knowledge with _mm_cvtps_pi16 so I assumed that nsimd::cvt would work based on the similar name.

[raphaelthegreat]

Closing is now as resolved