竹下世界塔の計算機よもやま話

アクセスカウンタ

zoom RSS 命令実装時のサボりについて

<<   作成日時 : 2014/08/07 02:42   >>

ブログ気持玉 0 / トラックバック 0 / コメント 1

 先日見かけた記事が面白かった。
ループカウンタを64bitにしたり、 バッファのサイズを定数にしたらパフォーマンス激落ちなんだけど何で?(本の虫)
 元記事。
Replacing a 32-bit loop count variable with 64-bit introduces crazy performance deviations(stackoverflow)

 問題と思われるpopcnt命令はSandyBridge世代から追加されたもの。
 Intel® 64 and IA-32 Architectures Software Developer’s Manual[PDF]

 popcnt命令は指定されたレジスタ幅から1が立っている個数を数える。これと同じ動作をする命令を知ったのはSPARC V9アーキでPOPC命令だった。最初のSPARC V9実装であるUltraSPARCでは、ハードウェアではこの命令は実装されずにトラップで命令をエミュレーションすることになっていた。このPOPC/popcnt命令はあると便利な命令扱い。「ハッカーのたのしみ」では類似の命令を持つプロセッサのモデルと持っていないモデルで解説されていた。

 出現頻度の高い命令(addなど)は1サイクル実行で複数のユニットを持つことがある。それに対して乗算、さらに除算は出現頻度が低いので実行サイクルは無理して1サイクルに収めないでもよく、実行ユニットも1個あればよい。極端な場合はその命令でトラップを発生させてソフトウェアで処理することがある。

 ここからは推測。

popcnt命令について:

1.実行に1cycleではなく数サイクルかかる
2.新規に追加された命令で、レジスタの依存関係に関わる論理回路を省略している。

1.の実行サイクルは、アウトオブオーダ実行のプロセッサだと見かけ上隠されるが、popcnt命令を想定以上の頻度で使用するとその遅さが目立ってくるはず。
2.については、以下の様に考えられる。

 例えば1GHz動作をターゲットとして設計した場合は1クロックの間に組合せ回路が変化できるスピードは1ns以内に収めなければならない。命令を追加したことにより、関連する制御回路の論理が深くなり、1nsを越えてしまう箇所があると全体のスピードはたったそれだけの命令実行のために遅くなってしまう。それよりは制御回路のデコードをサボって簡略化し、その命令実行時のペナルティは受けることにして、全体の動作を1ns以内に収める。サボり方の例としては、あるアドレスが一致したら1サイクル待たせるような制御があるとしたらアドレス下位の数ビットを無視して比較するなどのやり方がある。完全には一致しない時には余計な待ちサイクルが発生するかもしれないが論理回路は簡略化できる。

 もうひとつは検証の手間。新規に追加した命令はその命令を含んだ色々な命令との組み合わせパターンを流して想定どおりの動作かどうかを確認しなければならない。が、従来存在した命令と依存関係などの制御を流用しているのであれば、新規追加した命令に由来する問題が発生する確率は減る(エンバグがない)。

 恐らくこれらの理由でpopcnt命令の動作に制限があるのではないだろうか。新規追加命令なので実行速度が以前と比べて遅いということはないので、仕様書にもわざわざ書くようなことはない。

 このように、特定の命令列で想定していた理想的な実行サイクルよりも遅くなるというのはどのプロセッサでもありえる。これは全体の実行速度/命令の実行頻度/検証の手間とのトレードオフで実装が決まる。

テーマ

注目テーマ 一覧


月別リンク

ブログ気持玉

クリックして気持ちを伝えよう!
ログインしてクリックすれば、自分のブログへのリンクが付きます。
→ログインへ

トラックバック(0件)

タイトル (本文) ブログ名/日時

トラックバック用URL help


自分のブログにトラックバック記事作成(会員用) help

タイトル
本 文

コメント(1件)

内 容 ニックネーム/日時
C鍄糯鞣 粢? 琺 <a href=http://www.neftmash.com/->ハA?? ? ?? 磅@粽蓖H 瑩?瑣?</a>
WesleyVob
2017/07/19 04:15

コメントする help

ニックネーム
本 文




命令実装時のサボりについて 竹下世界塔の計算機よもやま話/BIGLOBEウェブリブログ
文字サイズ:       閉じる