> can you expand on what _mm256_permute4x64_pd is used for? In one place I was doing single-pass marching cubes on multiple FP32 scalar fields. A source data f

> can you expand on what _mm256_permute4x64_pd is used for? In one place I was doing single-pass marching cubes on multiple FP32 scalar fields. A source data for every cube is 8 FP32 number in 1 AVX register. Sometimes I need to broadcast FP32 lanes from the vector, where the source index is known at compile time. For most of these indices, a combo of _mm256_movehdup_ps/_mm256_moveldup_ps + _mm256_permute4x64_pd is the fastest way to do so. In another place I needed to broadcast FP64 values from non-zero lane. In another place I wanted to avoid MXCSR error flag for 3D FP64 vectors: // Duplicate Z into W to avoid division by zero size = _mm256_permute4x64_pd( size, _MM_SHUFFLE( 2, 2, 1, 0 ) ); In a few other places it’s just math e.g. const __m256d b_xxy = _mm256_permute4x64_pd( b, _MM_SHUFFLE( 3, 1, 0, 0 ) ); const __m256d bw_yzz = _mm256_permute4x64_pd( bWeight, _MM_SHUFFLE( 3, 2, 2, 1 ) ); __m256d tmp = _mm256_mul_pd( b_xxy, bw_yzz ); > we have not needed complex-valued functions yet Wasn’t related to complex numbers, I was doing something like that, saving a few instructions: https://en.wikipedia.org/wiki/Distance_from_a_point_to_a_line#Line_defined_by_two_points https://en.wikipedia.org/wiki/Distance_from_a_point_to_a_lin... > but #ifdef is increasingly infeasible now that SVE and Risc-V V are coming, no? I think that’s wishful thinking like all these years of Linux on desktop, or rewriting everything in Rust. I think ARM is good enough for most applications, except very small niches (very low power, very price-sensitive, mostly embedded). > Those can actually be bridged just fine Yeah, but other things can’t. For one, ARM has 8-byte SIMD vectors. Quite useful for a library which implements non-trivial algorithms processing 2D vector data with tons of FP32 2D vectors. Another thing, this whole source file https://github.com/Const-me/DtsDecoder/blob/master/Utils/store3-sse.hpp https://github.com/Const-me/DtsDecoder/blob/master/Utils/sto... implementing an equivalent of a single vst3q_s16 NEON instruction. That code is called in a loop which does not do much else and is inlined, i.e. these 9 shuffle constants stay in vector registers.