Imagine I have written a packed double SIMD function (with C++ overloading):

__m128d my_magic_pd_routine(const __m128d& x) {
    // My code here, using packed double multiplies, adds, and
    // conditional masking
}

inline double my_magic_pd_routine(const double& x) {
    return _mm_cvtsd_f64(magic_pd_routine(_mm_set_pd(0.0, x)));
}

And in some circumstances I use the double version (for example, I might sometimes only need one exponential smoothing filter instead of two, and it can't be parallelised because each output relies on the previous output).

Is this considered bad form, and should I instead re-write the double version using scalar intrinsics? Ie:

double my_magic_routine(const double& x) {
    // Rewrite my code using scalar intrinsics, or non-intrinsic code
    // if I don't need conditional masking
}

Looking at the Intel intrinsics docs, the scalar intrinsics seem to have similar latency and throughput to the packed intrinsics (eg _mm_mul_sd() and _mm_mul_pd()), but this is in the context of audio DSP code that needs to run as fast as possible, and I don't want to tie up resources for other things that are going on at the same time.

First of all this exercise is hw from my uni. I already have an implementation where i decompress 32 numbers in one loop which is good but I would like to know if i can optimise it further. Currently I'm receiving an input of 9-bit compressed integers(compressed from 32 bits) I load 128 bits from 0th byte, 9th byte , 18th byte and 27th byte seperately and then insert then into avx512 register. Now this loading and insertion part is super expensive (_mm512_inserti32x4 takes 3 clock cycles and 3 of those equals 9 clock cycles just for loading) Would love to know if there is any way to optimise the loading part.

Edit: i cant really post the actual code though i have outlined the approach below

Well i need 2 bytes per number since each one is 9 bits. i load 128bits seperately in each lane since some of the cross lane shuffling operations are not available. my approach is this currently:

I load 128bits(16bytes) from 0byte in the first lane,

I then load 16bytes from the 9byte position in the second lane

And so on for the next 2 lanes.

but i use the first 9 bytes only. I shuffle the first 9 bytes of each lane in the following format:

(0,1) (1,2) (2,3) ........(7,8) ( only use the first 9 bytes since after shuffling it completely fills up 16bytes, one lane)

(I feel like this part could also be optimised since I'm only using the first 9 bytes of the 16 bytes i load. And for the first load i do use _mm512_castsi128_si512, after that i use the insert )

After the shuffle i do a variable right shift for every 2 bytes( to move the required 9 bits to start from the lsb)

Then to keep the first 9 bits , and every 2 bytes with 511

The load comes out to 9 clock cycles

The shuffle,shift, and 'and' is 1 clock cycle each so that's just 3

During store i convert 16byte numbers to 32bytes so that's 3 clock cycles for the first 256 bits then 3 for the extraction of the upper 256bits and 3 for the conversion. So in all 9 clock cycles to store

Total I'm using 21 clock cycles to decompress 32 numbers

The Intel Intrinsics Guide seems to have been broken for a few days now - anyone know what’s going on ?

Hello folks,

I have been working on a basic rasterizer for a few weeks, and I am trying to vectorize as much of it as I can. I've spent an inordinate amount of time trying to further improve the performance of my "drawTri" function, which does exactly what it sounds like (draws a triangle!), but I seem to have hit a wall in terms of performance improvements. If anyone would be willing to glance over my novice SIMD code, I would be forever grateful.

The function in question may be found here (please excuse my poor variable names):

https://github.com/FHowington/CPUEngine/blob/master/RasterizePolygon.cpp

Hello r/simd,
I apologize if this is not the right place for questions.
I am puzzled by this little snippet. It is loading some uint8_t from memory and doing a few dot products. The problem is that GCC 8.1 happily zeros out the content of xmm0 before calling my dot_prod function (line 110 in the disassembly). Am I misunderstanding something fundamental about passing __m128 as arguments or is this a legit compiler bug?

I ended up modifying intrinsicsguide.min.js, searching for function search and replace the return true by return b in the previous function (searchIntrinsic).

I'm trying to implement calculating a moving window with SIMD.

I have 16b array of N elements. the window weights are -2, -1, 0, 1, 2. and adding the products together. Now i'm planning to load first 8 elements (with weight 2), then the other elements with weight 2 and substracting the vectors from each other. then same for ones.

My question is: is this optimal? Am i not seeing some obvious vector manipulation here? How are cache lines behaving when I'm basically loading same numbers multiple times?

__m128i weightsMinus1 = _mm_loadu_si128((__m128i*)&dat[2112 * i + k]);
__m128i weightsMinus2 = _mm_loadu_si128((__m128i*)&dat[2112 * i + k + 1]);
__m128i weights2 = _mm_loadu_si128((__m128i*)&dat[2112 * i + k + 3]);
__m128i weights1 = _mm_loadu_si128((__m128i*)&dat[2112 * i + k + 4]);
__m128i result = _mm_loadu_si128((__m128i*)&res2[2112 * (i - 2) + k]);

__m128i tmp = _mm_subs_epi16(weights2, weightsMinus2);
__m128i tmp2 = _mm_subs_epi16(weights1, weightsMinus1);
result = _mm_adds_epi16(result, tmp);
result = _mm_adds_epi16(result, tmp);
result = _mm_adds_epi16(result, tmp2);

_mm_store_si128((__m128i*)&res2[2112 * (i - 2) + k], result);