5 replies to this topic

[wobuu]

The documentation for the m128i datatype on MSDN reads:

Quote

You should not access the __m128i fields directly. You can, however, see these types in the debugger. A variable of type __m128i maps to the XMM[0-7] registers.

However, when I access one of the fields directly and store it in an integer, it works like expected (in debug and release builds).

m128i var;

int n = var.m128i_i32[3]

What is the reason the documentation tells me not to write code like this? Or can I ignore that advice and safely use this approach.

Perhaps it's not _guaranteed_ to work in all circumstances/cpu's?

[.oisyn]

It should always work. However, it might not be as efficient as keeping the values in mm128 registers and doing math operations on them, as it needs to store the register in memory first. However, if you simply want to store a single int that's ok because you're storing it in memory anyway

[Nick]

A lot of compilers don't handle __m128 as a struct. It's Visual C++ specific to have a mapping between the SSE vectors and the individual components as the fields of a structure. The names of the fields might even differ between compiler versions.

Another important reason not to read or write those fields directly is to allow the compiler to optimize things better. The compiler will have to store the SSE registers in memory to access individual components. So it's advised to always use the SSE intrinsics to read and write components, which the compiler does know how to turn into efficient code.

If you don't care that much about performance and it only needs to work for a specific version of Visual C++ then it's probably fine to access those fields directly. Just be aware of the compromises your making. I would highly advise to always have a scalar C++ version of your code as well though. Maybe in a couple years you have to use that code again and when the SSE version doesn't compile at least you still have the plain C++ code...

[wobuu]

Ok thanks for the advice guys. I ended up using the proper '_mm_store_si128' approach. Speedwise, this made no difference as far as I could tell.

[Nick]

wobuu said:

Ok thanks for the advice guys. I ended up using the proper '_mm_store_si128' approach. Speedwise, this made no difference as far as I could tell.

The Visual Studio compiller is pretty lame when it comes to optimizing SSE code. The Intel compiler for example does a far better job. Anyway, it's quite possible that the code you rewrote wasn't in a performance critical path anyway.

I also often see people spending days, weeks or even months writing an SSE optimized vector library, while their application actually only uses vector math for 5% of the exeuction time. So before optimizing anything it's important to profile instead of assuming and guessing. After identifying a hotspot I'd also first prototype the optimization to see if it's worth it. If not, stick with readable C++ code.

[poita]

GCC apparently does a really good job of optimizing code. More so than Intel in many cases.

Good read on optimisations done by compilers (very recent): http://www.linux-kon...von_leitner.pdf