この質問は、ここでの私の質問に続きます (Mystical のアドバイスによる):
私の質問を続けると、スカラー命令の代わりにパック命令を使用すると、組み込み関数を使用するコードは非常によく似たものになります。
for(int i=0; i<size; i+=16) {
y1 = _mm_load_ps(output[i]);
…
y4 = _mm_load_ps(output[i+12]);
for(k=0; k<ksize; k++){
for(l=0; l<ksize; l++){
w = _mm_set_ps1(weight[i+k+l]);
x1 = _mm_load_ps(input[i+k+l]);
y1 = _mm_add_ps(y1,_mm_mul_ps(w,x1));
…
x4 = _mm_load_ps(input[i+k+l+12]);
y4 = _mm_add_ps(y4,_mm_mul_ps(w,x4));
}
}
_mm_store_ps(&output[i],y1);
…
_mm_store_ps(&output[i+12],y4);
}
このカーネルの測定されたパフォーマンスは、1 サイクルあたり約 5.6 FP 操作ですが、スカラー バージョンのパフォーマンスのちょうど 4 倍、つまり 1 サイクルあたり 4.1,6=6,4 FP 操作になると予想されます。
重み係数の移動を考慮すると (指摘してくれてありがとう)、スケジュールは次のようになります。
スケジュールは変更されていないように見えますが、movss操作の後にスカラーの重み値を XMM レジスタに移動し、shufpsこのスカラー値をベクター全体にコピーするために使用する追加の命令があります。mulpsロードから浮動小数点ドメインへの切り替えレイテンシを考慮して、重みベクトルを使用する準備ができているように見えるため、余分なレイテンシが発生することはありません。
このカーネルで使用されるmovaps(アラインされた、パックされた移動) addps&mulps命令 (アセンブリ コードでチェック) は、スカラー バージョンと同じレイテンシとスループットを持っているため、余分なレイテンシが発生することはありません。
このカーネルが得られる最大パフォーマンスがサイクルあたり 6.4 FP ops であり、サイクルあたり 5.6 FP ops で実行されていると仮定して、8 サイクルあたりのこの余分なサイクルがどこに費やされているかを知っている人はいますか?
ちなみに実際の組み立てはこんな感じ。
…
Block x:
movapsx (%rax,%rcx,4), %xmm0
movapsx 0x10(%rax,%rcx,4), %xmm1
movapsx 0x20(%rax,%rcx,4), %xmm2
movapsx 0x30(%rax,%rcx,4), %xmm3
movssl (%rdx,%rcx,4), %xmm4
inc %rcx
shufps $0x0, %xmm4, %xmm4 {fill weight vector}
cmp $0x32, %rcx
mulps %xmm4, %xmm0
mulps %xmm4, %xmm1
mulps %xmm4, %xmm2
mulps %xmm3, %xmm4
addps %xmm0, %xmm5
addps %xmm1, %xmm6
addps %xmm2, %xmm7
addps %xmm4, %xmm8
jl 0x401ad6 <Block x>
…