News for hackers. Stuff that matters.

A comment on Show HN: Shishua – Fast pseudo-random generator.

Re:Show HN: Shishua – Fast pseudo-random generator by nkurz on Saturday April 18, 2020 @05:28PM (#22911243)
> Indeed, AVX2 has a bit of a quirk where regular registers (%rax and the like) cannot directly be transfered to the SIMD ones with a MOV; it must go through RAM (typically the stack), which costs both latency and two CPU instructions (MOV to the stack, VMOV from the stack).

I don't think this is quite correct. You can move efficiently from r64 to XMM/YMM without going through memory with MOVQ/_mm_cvtsi64_si128. I'm not able to look into it more closely right now, but these links should give insight:

https://www.felixcloutier.com/x86/movd:movq

https://software.intel.com/sites/landingpage/IntrinsicsGuide...

My vague recollection is that you might be right that this is clumsy with AVX2. Maybe it's a case where you have to take advantage of the fact that XMM1 and YMM1 are same register, and cast the YMM to XMM? Or just drop to inline assembly.

But thanks for the writeup, and I hope to be able to look at Shishua more closely at some point in the future.

[ Parent | on HN ]
Re:Show HN: Shishua – Fast pseudo-random generator by BeeOnRope on Monday April 20, 2020 @08:33PM (#22930560)
Yes, most instructions that modify only the bottom element(s) didn't get a ymm (256-bit) version since it would serve no purpose as it would produce the same result as the xmm one, and the corresponding intrinsics mostly follow the same pattern. So there is no int64 -> ymm intrinsic.

An intrinsic cast works fine though:

https://godbolt.org/z/M9XWCb

Intel even says about the cast:

> Cast vector of type __m128i to type __m256i; the upper 128 bits of the result are undefined. This intrinsic is only used for compilation and does not generate any instructions, thus it has zero latency.

That seems a bit beyond their mandate since what the compilers generate is mostly up to them, and in fact it doesn't seem true: at -O0, both gcc and clang generate a few extra instructions for the cast. With optimization on, it's all good though.

[ Parent | on HN ]