9月
23
最近、命令ベンチマークツールをもうちょっと汎用的に組めるように作りなおしているのですが、さっき試しに計測したら Sandy 上で pmovzxbw のスループットが 0.5 と出てきました。以前のツールで測った時は 1 になっていました。あれれと思って Intel の最適化マニュアルを見たところ、0.5 が正しいようです。あとよく見たら palignr も正しくはスループット 0.5 で、これまた以前のツールでは間違った値が出てきています。
今回のツールと以前のツールの計測関数の部分を見比べても特に違いは見つかりません。違うのは以前のは x86 用なのに対し今回のは x64 用ということですが、今回のをちょちょいといじって x86 用にしたところ、やっぱり同じ挙動（0.5 と出てくる）になります。さすがにそんなところで差は出ないか。
で、上から下までずーっと見たところ、
%xdefine nrep 4000
と書いてありました。これはループ1周の命令数を決定するマクロなのですが、試しに 1000 にしてみたら 0.5 という結果が出てくるようになりました。1次命令キャッシュからあふれているのかと思いましたが、REX プレフィックスが付かない pmovzxbw 命令は5バイトなので 4000 個並ぶと合計 20kB となり、32KB ある Sandy の1次命令キャッシュには収まります。ていうか pshufb も5バイト命令ですがこちらは元から 0.5 という結果になっているので、関係はなさそうです。
うーん…？
ループ中に長い依存列があると命令発行が遅くなる？
命令ベンチマークツールでループ中の命令数を増やすとスループットが下がる件にからんで、パフォーマンスを計測する方法一般についてちょろっとググったら、Linux の perf コマンドを使…
某巨大匿名掲示板のインテル・プロセッサ・フリークに聞いたところ以下のようなレスが付きました。
――
Intelのマニュアルに書かれてるのはμOPs cacheにヒットしてる場合のスループットであって
デコーダにネックがある場合のスループットではない
PMOVSX/ZXをデコードできるパスが1つしか存在しないという可能性を考えてみては？
そんな利用頻度高い命令でもないのにμOPs cache外の命令を1クロックに何命令も
デコードできる必要性なんてないという判断をしても不思議じゃない
ああ、uOP cache ！ 忘れてました。考察します。