>>87
たとえば、256個づつのDWORD値を加算する場合、16バイトアライメントされていないとすると、
mov esi, srcadr
mov edi, destadr
mov ecx, 16
lp:
movdqu xmm0, [esi]
movdqu xmm4, [edi]
movdqu xmm1, [esi+16]
movdqu xmm5, [edi+16]
movdqu xmm2, [esi+32]
movdqu xmm6, [edi+32]
movdqu xmm3, [esi+48]
movdqu xmm7, [edi+48]
paddd xmm0, xmm4
paddd xmm1, xmm5
paddd xmm2, xmm6
paddd xmm3, xmm7
movdqu [edi], xmm0
movdqu [edi+16], xmm1
movdqu [edi+32], xmm2
movdqu [edi+48], xmm3
sub ecx, 1
jnz lp
とすると、FP_MOVポートと、MMX_ALUが別ポートなので、ループによってアウトオブオーダーで
処理が折り込まれて、レイテンシがある程度隠蔽されるので、高速化が出来るのですが、
movdqu のペナルティ遅延がひどくて、アライメントの合っている処理(MOVDQA)と比べて、
３０％くらい遅くなってしまう場合があります。
(更に言うと、１２８ビットオペランドでアライメントが合っていれば、レジスタに入れなくても直接演算できる)
そこに、lddquをそのままmovdquと置換（ただし、ロード側のみ、ストアは代えられない)すると、１５％位、スループットが改善するようです。
まあ、アライメントをうまく合わせられればそっちのほうが良いと思います。お手軽高速化用ですね。