Assume the following simplified scenario:

You have a base class for objects that exist in the game world called CEntity that is maybe a couple of hundred bytes or so of data members that describe all its necessary state data, the position, a pair of angles or maybe a transformation matrix, the velocity, whether it has a collision mesh, whether it is static and so on.

From this class you derive a bunch of CRockets, CPlayers, CPhysicsObject etc. To improve locality of reference you store all your CEntities in a simple array rather than spreading them out in memory. You might just allocate a big enough array that it’s not going to reach capacity under any but pathological cases or you might use some dynamic array that you reallocate to double the size if it’s filled to capacity or reallocate to half the size if emptied to one quarter or something like that.

In order to give the processor the best possible chance to precache necessary data your update loop calls the Update() method on the CEntity at index zero, then index one and so on in the order they are stored in memory. Each Update() does one normalization among various other stuff.

Under these conditions, which are about as predictable as possible, will the processor look at the memory access pattern and correctly identify that there’s a 224(or whatever) byte stride and that it is supposed to cache this data ahead of time? If the data is not precached the processor is going to sit idle and wait on RAM for at least several hundred clock cycles in which case it totally swamps the performance of your arithmetic to the point that it barely matters.

Soylent: What you’re suggesting indeed makes sense when one has long lists of packed vectors to transform, but that’s not what I’m timing here. I’m looking at cases where you have to perform a single vector normalization as part of the logic in some larger function — like performing an angle comparison when an AI selects which enemy to target next. Mike Acton might say that even game logic should be packed structures of arrays so that instead of having one entity per AI, you have a big structure of all the positions for all AIs, all velocities for all AIs, all nav state for all AIs, and so on; but games just aren’t built like that yet. We’re still in a world where each rocket is represented by an instance of a CRocket class, and each CRocket has its own Update() function, and each CRocket does its own logic one at a time.

I wouldn’t have expected you to structure your data in that way. I would have expected either uniform vectors { x, y, z ,w } which allow a 4×4 matrix to represent an affine transformation(e.g. projection, translations) or a structure of arrays(SoA), where the x coordinates, y-coordinates and z-coordinates are kept in separate 16-byte aligned arrays.

If you use the SoA approach you would do aligned loads from packed x-vectors, packed y-vectors and packed z-vectors and operate on them in exactly the same way you do with the scalar instructions, you just use the corresponding packed scalar instruction(e.g. rsqrtss -> rsqrtps). You probably want to unroll the loop so that you are normalizing 8 vectors at a time. If the number of vectors to normalize isn’t evenly divisible by 8 you can use some scalar code to pick up any stragglers. You can also force the user to allocate a number of floats that is evenly divisible by 8 so that you never have any stragglers(that leaves between 0 and 7 unused vectors at the end of the array; it is probably cheaper to normalize these unused vectors than it is to polluting the instructure cache with extra code).

If you are forced for some reason to work on 3-component vectors in an AoS memory arrangement then I believe it may still be more efficient to convert from AoS to SoA as you load into the xmm registers(one register containing only x-values, one register containing only y-values and one containing only z-values), do the math and then convert back to AoS and store.

If eax is a pointer to the current position in the array you could use a sequence like he following to load the vectors:

movlps xmm0, [eax] // xmm0: { -, -, y0, x0 }.
movlps xmm1, [eax+24] // xmm1: { -, -, y2, x2 }.
unpcklps xmm0, [eax+12] // xmm0: { y1, y0, x1, x0}.
unpcklps xmm1, [eax+36] // xmm1: { y3, y2, x3, x2}.
movss xmm2, [eax+8] // xmm2: { 0, 0, 0, z0 }.
movss xmm3, [eax+32] // xmm3: { 0, 0, 0, z2 }.
unpcklps xmm2, [eax+20] // xmm2: { x2, 0, z1, z0 }.
unpcklps xmm3, [eax+44] // xmm3: { x4, 0, z3, z1 }. <- note x4.
movaps xmm4, xmm0;
movlhps xmm0, xmm1; // xmm0: { x3, x2, x1, x0 }.
movhlps xmm1, xmm4; // xmm1: { y3, y2, y1, y0 }.
movlhps xmm2, xmm3; // xmm2: { z3, z2, z1, z0 }.

You don't want to go off the end of the array(also note that x4 was read above, which can be off the array even if the number of vertices is evenly divisible by 4), so you have to stop and switch over to a scalar routine to pick up the last few elements.

Do vector normalization in this packed format. When you are done do something like this to store again:

// xmm0: { x3', x2', x1', x0' }
// xmm1: { y3', y2', y1', y0' }
// xmm2: { z3', z2', z1', z0' }
movaps xmm3, xmm0
movhlps xmm4, xmm1 // { -, -, z3', z2' }
unpcklps xmm0, xmm1 // { y1', x1', y0', x0' }
unpckhps xmm3, xmm1 // { y3', x3', y2', x2' }
movlps [eax], xmm0 // Store { y0', x0' }
movss [eax+8], xmm2 // Store z0'
movhps [eax+12], xmm0 // Store {y1', x1'}
unpcklps xmm2, xmm2 // { z1', z1', z0', z0' }
movhps [eax+20], xmm2 // Store z1'.
movlps [eax+24], xmm3 // Store {y2', x2' }
movss [eax+32], xmm4 // Store z2'
movhps [eax+36], xmm3 // Store {y3', x3' }
shufps xmm4, xmm4, 01010101b // { z3', z3', z3', z3' }
movss [eax+44], xmm4 // Store z3'.

Of course, caveat emptor. I haven't tested this code at all. I've just drawn jotted a bit on a piece of paper. It is probably not worth trying to process 8 vectors at a time unless you are in 64-bit mode(8 extra xmm registers).

I also occasionally need the sqrt itself to solve a quadratic, like computing an apsis or a ballistic intercept.