Intel® 64 and IA-32 Architectures Optimization Reference Manual Order Number: 248966-040
April 2018
https://software.intel.com/sites/default/files/managed/9e/bc/64-ia-32-architectures-optimization-manual.pdf
インテル® 64 アーキテクチャーおよび IA-32 アーキテクチャー最適化リファレンス・マニュアル(の参考訳) 参照ドキュメント番号: 248966-038 October 2017
https://www.isus.jp/wp-content/uploads/pdf/64-ia-32-architectures-optimization-manual-Oct2017-038JA.pdf
を比較して内容を確認。
ただし版が１年違うため、英語優先で、日本語に違いがあるかどうかを確認。
ここまででは、翻訳の仕方でどうするとわかりやすいかを検討。
１）英語を読んで、次に日本語を読んで、わかるやすくなっているかどうか。
２）英語をhttp://translate.google.comで翻訳し、日本語と比較。
３）必要があれば、コンパイル、アセンブルする。
Intel製コンパイラは持っていない。GCC, LLVM/Clang, Visual Studioを使用予定。
Assembly/Compiler Coding Rule
「Assembly/Compiler Coding Rule 1. (MH impact, M generality) Arrange code to make basic blocks contiguous and eliminate unnecessary branches.」
「アセンブリー/コンパイラー・コーディング規則 1 (影響 MH、一般性 M): 基本ブロックが隣接するようにコードを構成し、不要な分岐を排除します。」
「Assembly/Compiler Coding Rule 2. (M impact, ML generality) Use the SETCC and CMOV instructions to eliminate unpredictable conditional branches where possible. Do not do this for predictable branches. Do not use these instructions to eliminate all unpredictable conditional branches (because using these instructions will incur execution overhead due to the requirement for executing both paths of a conditional branch). In addition, converting a conditional branch to SETCC or CMOV trades off control flow dependence for data dependence and restricts the capability of the out-of-order engine. When tuning, note that all Intel 64 and IA-32 processors usually have very high branch prediction rates. Consistently mispredicted branches are generally rare. Use these instructions only if the increase in computation time is less than the expected cost of a mispredicted branch.」
「アセンブリー/コンパイラー・コーディング規則 2 (影響 M、一般性 ML): SETCC 命令と CMOV 命令を使用して、予測不可能な条件分岐をできるだけ排除します。予測可能な分岐については、この操作を行ってはなりません。これらの命令を使用して、すべての予測不可能な条件分岐を排除してはなりません (これらの命令を使用すると、条件分岐の両方のパスを実行する必要性から、実行のオーバーヘッドが発生します)。また、条件分岐を SETCC または CMOV に変更すると、データに依存する制御フローの依存関係がトレードオフされ、アウトオブオーダー・エンジンの機能が制限されます。チューニングの際は、すべてのインテル® 64 プロセッサーと IA-32 プロセッサーが、通常は高い分岐予測精度を持っていることを考慮すべきです。一貫した分岐予測ミスは一般的にまれです。これらの命令は、計算時間の増加分が、予想される分岐の予測ミスのペナルティーより小さい場合にのみ使用するべきです。」
「Assembly/Compiler Coding Rule 3. (M impact, H generality) Arrange code to be consistent with the static branch prediction algorithm: make the fall-through code following a conditional branch be the likely target for a branch with a forward target, and make the fall-through code following a conditional branch be the unlikely target for a branch with a backward target.」
「アセンブリー/コンパイラー・コーディング規則 3 (影響 M、一般性 H): 静的分岐予測アルゴリズムに従ってコードを配置します。すなわち、条件分岐に後続するフォールスルー・コードが、前方に分岐する分岐のターゲットになるように調整します。また、条件分岐に後続するフォールスルー・コードが、後方に分岐する分岐のターゲットにならないようにします。」
「Assembly/Compiler Coding Rule 4. (MH impact, MH generality) Near calls must be matched with near returns, and far calls must be matched with far returns. Pushing the return address on the stack and jumping to the routine to be called is not recommended since it creates a mismatch in calls and returns.」
「アセンブリー/コンパイラー・コーディング規則 4 (影響 MH、一般性 MH): near コールは near リターンに対応し、far コールは far リターンに対応していなければなりません。リターンアドレスをスタック上にプッシュして呼び出し先ルーチンにジャンプすると、コールとリターンの不一致が起こるため、この操作は推奨されません。」
「Assembly/Compiler Coding Rule 5. (MH impact, MH generality) Selectively inline a function if doing so decreases code size or if the function is small and the call site is frequently executed.」
「アセンブリー/コンパイラー・コーディング規則 5 (影響 MH、一般性 MH): 関数をインライン展開することでコードのサイズが小さくなる場合や、小さな関数が頻繁に呼び出される場合は、関数を選択した上でインライン展開を実施します。」
「Assembly/Compiler Coding Rule 6. (H impact, H generality) Do not inline a function if doing so increases the working set size beyond what will fit in the trace cache.」
「アセンブリー/コンパイラー・コーディング規則 6 (影響 H、一般性 H): 関数をインライン展開するとワーキングセットのサイズがトレースキャッシュの容量を超える場合は、関数のインライン展開を実施しません。」
「Assembly/Compiler Coding Rule 7. (ML impact, ML generality) If there are more than 16 nested calls and returns in rapid succession; consider transforming the program with inline to reduce the call depth.」
「アセンブリー/コンパイラー・コーディング規則 7 (影響 ML、一般性 ML): 17 以上のコールとリターンが連続してネストされている場合は、インライン展開を行いネストされているコールの数を減らします。」
「Assembly/Compiler Coding Rule 8. (ML impact, ML generality) Favor inlining small functions that contain branches with poor prediction rates. If a branch misprediction results in a RETURN being prematurely predicted as taken, a performance penalty may be incurred.」
「アセンブリー/コンパイラー・コーディング規則 8 (影響 ML、一般性 ML): 小さい関数内の分岐の予測精度が低い場合、関数をインライン展開すると予測の精度を改善できます。分岐予測ミスにより、リターンが誤って予測された場合は、ペナルティーが生じます。」
「Assembly/Compiler Coding Rule 9. (L impact, L generality) If the last statement in a function is a call to another function, consider converting the call to a jump. This will save the call/return overhead as well as an entry in the return stack buffer.」
「アセンブリー/コンパイラー・コーディング規則 9 (影響 L、一般性 L): 関数内の最後の文が別の関数への呼び出しである場合、コールをジャンプに置き換えることを検討します。これにより、コール/リターンのオーバーヘッド、リターン・スタック・バッファー内のエントリーが消費されなくなります。」
「Assembly/Compiler Coding Rule 10. (M impact, L generality) Do not put more than four branches in a 16-byte chunk.」
「アセンブリー/コンパイラー・コーディング規則 10 (影響 M、一般性 L): 16バイト・チャンク内に 5 つ以上の分岐を配置してはいけません。」
翻訳は５だが、英文は４。古い版を確認。
Order Number: 248966-033 June 2016
https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf
を見ると、古い版でも４。
「Assembly/Compiler Coding Rule 10. (M impact, L generality) Do not put more than four branches in a 16-byte chunk.」
「more than four」は、４を超えるだから「５以上」と同じ意味。なるほど。
「４を超える」がいいか「５以上」がいいかは多くの方のご意見を希望。
「Assembly/Compiler Coding Rule 11. (M impact, L generality) Do not put more than two end loop branches in a 16-byte chunk.」
「アセンブリー/コンパイラー・コーディング規則 11 (影響 M、一般性 L): 16バイト・チャンク内に 3 つ以上のループの終端分岐を配置してはいけません。」
「more than two」は「３つ以上」がいいか「２を超える」がいいか。
「Assembly/Compiler Coding Rule 12. (M impact, H generality) When executing code from the DSB, direct branches that are mostly taken should have all their instruction bytes in a 64B cache line and nearer the end of that cache line. Their targets should be at or near the beginning of a 64B cache line.」
「アセンブリー/コンパイラー・コーディング規則 12 (影響 M、一般性 H): コードが DSB から実行される直接分岐は、64 B キャッシュラインにすべての命令バイトが格納され、キャッシュラインの終端近くにあるべきです。分岐ターゲットは 64B キャッシュラインの先頭または始まりにある必要があります。」
「at or ner beggining」が「先頭または始まり」となっている。「先頭または先頭付近」の方がよくないか。
「Assembly/Compiler Coding Rule 13. (M impact, H generality) If the body of a conditional is not likely to be executed, it should be placed in another part of the program. If it is highly unlikely to be executed and code locality is an issue, it should be placed on a different code page.」
「アセンブリー/コンパイラー・コーディング規則 13 (影響 M、一般性 H): 条件分岐の直後の命令が実行される可能性が低い場合、そのコードをプログラムの別の部分に配置します。また、条件分岐の直後の命令が実行される可能性が非常に低く、コードの局所性が重要である場合は、そのコードを異なるコードページ上に配置します。」
「Assembly/Compiler Coding Rule 14. (M impact, L generality) When indirect branches are present, try to put the most likely target of an indirect branch immediately following the indirect branch. Alternatively, if indirect branches are common but they cannot be predicted by branch prediction hardware, then follow the indirect branch with a UD2 instruction, which will stop the processor from decoding down the fall-through path.」
「アセンブリー/コンパイラー・コーディング規則 14 (影響 M、一般性 L): 間接分岐を行う場合、実行頻度が最も高い分岐ターゲットを間接分岐の直後に配置します。あるいは、間接分岐が分岐予測ハードウェアによって予測できない場合、間接分岐の後に UD2 命令を配置します。これにより、プロセッサーによるフォールスルー・パスのデコードが停止します。」
「Assembly/Compiler Coding Rule 15. (H impact, M generality) Unroll small loops until the overhead of the branch and induction variable accounts (generally) for less than 10% of the execution time of the loop.」
「アセンブリー/コンパイラー・コーディング規則 15 (影響 H、一般性 M): 一般的に、分岐とインダクション変数のオーバーヘッドがループの実行時間の 10% より小さくなるまで、小さいループをアンロールします。」
Assembly/Compiler Coding Rule 16. (H impact, M generality) Avoid unrolling loops excessively; this may thrash the trace cache or instruction cache.
「アセンブリー/コンパイラー・コーディング規則 16 (影響 H、一般性 M): トレースキャッシュや命令キャッシュのスラッシュが起こる可能性があるため、必要以上にループをアンロールてはなりません。」
Assembly/Compiler Coding Rule 17. (M impact, M generality) Unroll loops that are frequently executed and have a predictable number of iterations to reduce the number of iterations to 16 or fewer. Do this unless it increases code size so that the working set no longer fits in the trace or instruction cache. If the loop body contains more than one conditional branch, then unroll so that the number of iterations is 16/(# conditional branches).
「アセンブリー/コンパイラー・コーディング規則 17 (影響 M、一般性 M): 反復回数が予測可能な実行頻度の高いループをアンロールして、反復の回数を16 以下に抑えます。コードのサイズが大きくなりすぎて、ワーキングセットがトレースキャッシュや命令キャッシュの容量を超える場合は、この操作は必要ありません。ループ本体に 2 つ以上の条件分岐が含まれる場合は、反復の回数が 16/(条件分岐の数) 回になるようにループをアンロールします。」
「Assembly/Compiler Coding Rule 18. (ML impact, M generality) For improving fetch/decode throughput, Give preference to memory flavor of an instruction over the register-only flavor of the same instruction, if such instruction can benefit from micro-fusion.」
「アセンブリー/コンパイラー・コーディング規則 18 (影響 ML、一般性 M): フェッチ/デコードのスループットを高める場合、命令がマイクロフュージョンからメリットを得られるのであれば、レジスター方式の命令よりもメモリー方式の命令を優先します。」
Assembly/Compiler Coding Rule 19. (M impact, ML generality) Employ macro-fusion where possible using instruction pairs that support macro-fusion. Prefer TEST over CMP if possible. Use unsigned variables and unsigned jumps when possible. Try to logically verify that a variable is non- negative at the time of comparison. Avoid CMP or TEST of MEM-IMM flavor when possible. However, do not add other instructions to avoid using the MEM-IMM flavor.
「アセンブリー/コンパイラー・コーディング規則 19 (影響 M、一般性 ML): 可能な限り、マクロフュージョンをサポートする命令ペアを使用してマクロフュージョンを行います。CMP よりも TEST を優先します。可能な限り、符号なし変数と符号なしジャンプを使用します。比較時に変数が負でないことを論理的に確認します。可能な限り、MEM-IMM 方式の CMP や TEST は回避します。ただし、MEM-IMM 方式を回避するためほかの命令を追加してはなりません。」
「Assembly/Compiler Coding Rule 20. (M impact, ML generality) Software can enable macro fusion when it can be logically determined that a variable is non-negative at the time of comparison; use TEST appropriately to enable macro-fusion when comparing a variable with 0.」
「アセンブリー/コンパイラー・コーディング規則 20 (影響 M、一般性 ML): 比較時に変数が負でないことを論理的に確認できれば、ソフトウェアによってマクロフュージョンを有効にできます。マクロフュージョンを有効にするには、変数をゼロ比較する際に TEST 命令を適切に使用します。」
「Assembly/Compiler Coding Rule 21. (MH impact, MH generality) Favor generating code using imm8 or imm32 values instead of imm16 values.」
「アセンブリー/コンパイラー・コーディング規則 21 (影響 MH、一般性 MH): imm16 値の代わりに imm8 や imm32 値を使用したコード生成を優先します。imm16 が必要な場合、代わりに、同等の imm32 値をレジスターにロードしてから、レジスター内のワード値を使用します。」
「Assembly/Compiler Coding Rule 22. (M impact, ML generality) Ensure instructions using 0xF7 opcode byte does not start at offset 14 of a fetch line; and avoid using these instruction to operate on 16-bit data, upcast short data to 32 bits.」
「アセンブリー/コンパイラー・コーディング規則 22 (影響 M、一般性 ML): 0xF7 オペコード・バイトを使用する命令がフェッチラインのオフセット 14 から始まらないようにします。また、このような命令を使用して 16 ビット・データを操作するのを回避し、短いデータを 32 ビットに置き換えます。」
「Assembly/Compiler Coding Rule 23. (MH impact, MH generality) Break up a loop long sequence of instructions into loops of shorter instruction blocks of no more than the size of LSD.」
「アセンブリー/コンパイラー・コーディング規則 23 (影響 MH、一般性 MH): 長い命令シーケンスのループを、LSD のサイズ以下の命令ブロックからなるループに分割します。」
「Assembly/Compiler Coding Rule 24. (MH impact, M generality) Avoid unrolling loops containing LCP stalls, if the unrolled block exceeds the size of LSD.」
「アセンブリー/コンパイラー・コーディング規則 24 (影響 MH、一般性 M): アンロールされるブロックが LSD のサイズを超える場合は、LCP ストールを含むループのアンロールを回避します。」
「Assembly/Compiler Coding Rule 25. (M impact, M generality) Avoid putting explicit references to ESP in a sequence of stack operations (POP, PUSH, CALL, RET).」
「アセンブリー/コンパイラー・コーディング規則 25 (影響 M、一般性 M): ESP への明示的な参照を一連のスタック操作 (POP、PUSH、CALL、RET) に含めることを避けます。」
「Assembly/Compiler Coding Rule 26. (ML impact, L generality) Use simple instructions that are less than eight bytes in length.」
「アセンブリー/コンパイラー・コーディング規則 26 (影響 ML、一般性 L): 8 バイト未満の単純な命令を使用します。」
「Assembly/Compiler Coding Rule 27. (M impact, MH generality) Avoid using prefixes to change the size of immediate and displacement.」
「アセンブリー/コンパイラー・コーディング規則 27 (影響 M、一般性 MH): 即値およびディスプレースメントのサイズ変更にプリフィクスを使用するのを避けます。」
「Assembly/Compiler Coding Rule 28. (M impact, H generality) Favor single-micro-operation instructions. Also favor instruction with shorter latencies.A compiler may be already doing a good job on instruction selection. If so, user intervention usually is not necessary.」
「アセンブリー/コンパイラー・コーディング規則 28 (影響 M、一般性 H): 単一マイクロオペレーション (μop) の命令を優先します。また、レイテンシーが小さい命令を優先します。」
「Assembly/Compiler Coding Rule 29. (M impact, L generality) Avoid prefixes, especially multiple non-0F-prefixed opcodes.」
「アセンブリー/コンパイラー・コーディング規則 29 (影響 M、一般性 L): プリフィクス、特に 0F 以外のプリフィクスが付いた複数のオペコードを避けます。」
「Assembly/Compiler Coding Rule 30. (M impact, L generality) Do not use many segment registers.」
「アセンブリー/コンパイラー・コーディング規則 30 (影響 M、一般性 L): セグメントレジスターを多用しないようにします。」
「Assembly/Compiler Coding Rule 31. (M impact, M generality) Avoid using complex instructions (for example, enter, leave, or loop) that have more than four μops and require multiple cycles to decode. Use sequences of simple instructions instead.」
「アセンブリー/コンパイラー・コーディング規則 31 (影響 M、一般性 M): 5 つ以上のマイクロオペレーション (μop) を含み、デコードが 1 サイクルで完了しない複雑な命令 (例えば、enter、leave、loop) の使用を避けます。代わりに、単純な命令のシーケンスを使用します。」
「Assembly/Compiler Coding Rule 32. (MH impact, M generality) Use push/pop to manage stack space and address adjustments between function calls/returns instead of enter/leave. Using enter instruction with non-zero immediates can experience significant delays in the pipeline in addition to misprediction.」
「アセンブリー/コンパイラー・コーディング規則 32 (影響 MH、一般性 M): 関数の呼び出しとリターンにおけるスタック空間とアドレス調整の管理には、enter/leave 命令の代わりに push/pop 命令を使用します。非ゼロの即値を持つ enter 命令を使用すると、予測ミスに加えて重大なパイプラインの遅延が生じます。」
「Assembly/Compiler Coding Rule 33. (ML impact, L generality) If an LEA instruction using the scaled index is on the critical path, a sequence with ADDs may be better. If code density and bandwidth out of the trace cache are the critical factor, then use the LEA instruction.」
「アセンブリー/コンパイラー・コーディング規則 33 (影響 ML、一般性 L): スケール・インデックスを使用する LEA 命令がクリティカル・パス上にある場合は、ADD 命令のシーケンスの方が適しています。コードのサイズとトレースキャッシュの帯域幅が重要な要因である場合、LEA 命令を使用します。」
「Assembly/Compiler Coding Rule 34. (ML impact, L generality) Avoid ROTATE by register or ROTATE by immediate instructions. If possible, replace with a ROTATE by 1 instruction.」
「アセンブリー/コンパイラー・コーディング規則 34 (影響 ML、一般性 L): レジスターや即値を使用した ROTATE 命令の使用を避けて、できるだけ 1 ビットの ROTATE 命令で置き換えます。」
疑問
「1 ビットの」は「1 instruction」ビット数には言及していない。
2016年版も英語は同文（規則番号は35)
「Assembly/Compiler Coding Rule 35. (M impact, ML generality) Use dependency-breaking-idiom instructions to set a register to 0, or to break a false dependence chain resulting from re-use of registers. In contexts where the condition codes must be preserved, move 0 into the register instead. This requires more code space than using XOR and SUB, but avoids setting the condition codes.」
「アセンブリー/コンパイラー・コーディング規則 35 (影響 M、一般性 ML): レジスターを 0 に設定するときや、レジスターの再利用によって発生した不正な依存関係チェーンを解消するときは、依存関係を解消する機能を持つ命令を使用します。条件コードを維持する必要がある場合は、これらの命令に代わって、レジスターに 0 を移動します。この操作は、XOR や SUB よりコード空間を必要としますが、条件コードは設定されません。」
「Assembly/Compiler Coding Rule 36. (M impact, MH generality) Break dependences on portions of registers between instructions by operating on 32-bit registers instead of partial registers. For moves, this can be accomplished with 32-bit moves or by using MOVZX.」
「アセンブリー/コンパイラー・コーディング規則 36 (影響 M、一般性 MH): パーシャルレジスターの代わりに 32 ビット・レジスターを操作すると、レジスターの一部分を操作する命令との依存関係を解消できます。移動を行う場合、32 ビット移動命令または MOVZX 命令を使用します。」
「Assembly/Compiler Coding Rule 37. (M impact, M generality) Try to use zero extension or operate on 32-bit operands instead of using moves with sign extension.
The trace cache can be packed more tightly when instructions with operands that can only be repre- sented as 32 bits are not adjacent.」
「アセンブリー/コンパイラー・コーディング規則 37 (影響 M、一般性 M): 符号拡張付き移動命令を使用する代わりに、ゼロ拡張を使用するか、または 32 ビット・オペランドを操作します。」
「Assembly/Compiler Coding Rule 38. (ML impact, L generality) Avoid placing instructions that use 32-bit immediates which cannot be encoded as sign-extended 16-bit immediates near each other. Try to schedule μops that have no immediate immediately before or after μops with 32-bit immediates.」
「アセンブリー/コンパイラー・コーディング規則 38 (影響 ML、一般性 L): (符号拡張された 16 ビット即値としてコード化できない) 32 ビット即値を使用する命令を隣接して配置しないようにします。32 ビット即値を使用するマイクロオペレーション (μop) の直前または直後には、即値を持たないマイクロオペレーション (μop) を配置します。」
」Assembly/Compiler Coding Rule 39. (ML impact, M generality) Use the TEST instruction instead of AND when the result of the logical AND is not used. This saves μops in execution. Use a TEST of a register with itself instead of a CMP of the register to zero, this saves the need to encode the zero and saves encoding space. Avoid comparing a constant to a memory operand. It is preferable to load the memory operand and compare the constant to a register.」
「アセンブリー/コンパイラー・コーディング規則 39 (影響 ML、一般性 M): 論理 AND の結果が使用されないときは、AND 命令に代わって TEST 命令を使用します。これにより、実行時のマイクロオペレーション (μop) 数が軽減されます。レジスターをゼロと CMP するのではなく、レジスター自身との TEST を行います。これにより、ゼロをエンコードする必要がなくなり、命令を小さくエンコードできます。定数をメモリーオペランドと比較することは避けます。メモリーオペランドをロードし、定数をレジスターと比較する方が適切です。」
「Assembly/Compiler Coding Rule 40. (ML impact, M generality) Eliminate unnecessary compare with zero instructions by using the appropriate conditional jump instruction when the flags are already set by a preceding arithmetic instruction. If necessary, use a TEST instruction instead of a compare. Be certain that any code transformations made do not introduce problems with overflow.」
「アセンブリー/コンパイラー・コーディング規則 40 (影響 ML、一般性 M): 先行する算術命令によってすでにフラグが設定されている場合、適切な条件分岐命令を使用して、ゼロとの比較命令を排除します。必要に応じて、比較の代わりに TEST 命令を使用します。コードの変換によって、オーバーフローの問題が起こらないように注意してください。」
「Assembly/Compiler Coding Rule 41. (H impact, MH generality) For small loops, placing loop invariants in memory is better than spilling loop-carried dependencies.」
「アセンブリー/コンパイラー・コーディング規則 41 (影響 H、一般性 MH): 小さいループは、ループ伝搬依存を退避させるより、ループ不変コードをメモリー上に置く方が適切です。」
「Assembly/Compiler Coding Rule 42. (M impact, ML generality) Avoid introducing dependences with partial floating-point register writes, e.g. from the MOVSD XMMREG1, XMMREG2 instruction. Use the MOVAPD XMMREG1, XMMREG2 instruction instead.」
「アセンブリー/コンパイラー・コーディング規則 42 (影響 M、一般性 ML): 例えば、MOVSD XMMREG1、XMMREG2 命令によって、パーシャル浮動小数点レジスターへの書き込みによる依存関係が発生するのを避けます。MOVSD 命令に代わって、MOVAPD XMMREG1、XMMREG2 命令を使用します。」
「Assembly/Compiler Coding Rule 43. (ML impact, L generality) Instead of using MOVUPD XMMREG1, MEM for a unaligned 128-bit load, use MOVSD XMMREG1, MEM; MOVSD XMMREG2, MEM+8; UNPCKLPD XMMREG1, XMMREG2. If the additional register is not available, then use MOVSD XMMREG1, MEM; MOVHPD XMMREG1, MEM+8.」
「アセンブリー/コンパイラー・コーディング規則 43 (影響 ML、一般性 L): アライメントされていない 128 ビット・データのロードには、MOVUPD XMMREG1, MEM の代わりに、MOVSD XMMREG1, MEM; MOVSD XMMREG2, MEM+8; UNPCKLPD XMMREG1, XMMREG2 を使用します。追加のレジスターが使用できない場合は、MOVSD XMMREG1, MEM; MOVHPD XMMREG1, MEM+8 を使用します。」
「Assembly/Compiler Coding Rule 44. (M impact, ML generality) Instead of using MOVUPD MEM, XMMREG1 for a store, use MOVSD MEM, XMMREG1; UNPCKHPD XMMREG1, XMMREG1; MOVSD MEM+8, XMMREG1 instead.」
「アセンブリー/コンパイラー・コーディング規則 44 (影響 M、一般性 ML): ストアには、MOVUPD MEM, XMMREG1 の代わりに、MOVSD MEM, XMMREG1; UNPCKHPD XMMREG1, XMMREG1; MOVSD MEM+8, XMMREG1 を使用します。」
「Assembly/Compiler Coding Rule 45. (H impact, H generality) Align data on natural operand size address boundaries. If the data will be accessed with vector instruction loads and stores, align the data on 16-byte boundaries.」
「アセンブリー/コンパイラー・コーディング規則 45 (影響 H、一般性 H): データのアライメントを、オペランドサイズの自然なアドレス境界に合わせます。データが、SIMD 命令のロードとストアでアクセスされる場合、データのアライメントを 16 バイト境界に合わせます。」
「Assembly/Compiler Coding Rule 46. (H impact, M generality) Pass parameters in registers instead of on the stack where possible. Passing arguments on the stack requires a store followed by a reload. While this sequence is optimized in hardware by providing the value to the load directly from the memory order buffer without the need to access the data cache if permitted by store-forwarding restrictions, floating-point values incur a significant latency in forwarding. Passing floating-point arguments in (preferably XMM) registers should save this long latency operation.」
「アセンブリー/コンパイラー・コーディング規則 46 (影響 H、一般性 M): 可能な限りスタックではなくレジスターでパラメーターを受け渡します。スタック上での引数の受け渡しは、ストアの後に再ロードを行う必要があります。ストア・フォワーディングの制限上可能であれば、データキャッシュにアクセスせずにメモリー・オーダー・バッファーから直接ロードに値を供給することで、ハードウェア内でこのシーケンスを最適化できますが、浮動小数点値のフォワーディングには大きなレイテンシーが生じます。浮動小数点引数をレジスター (XMM が望ましい) に渡すと、この大きなレイテンシーの操作がなくなります。」
「Assembly/Compiler Coding Rule 47. (H impact, M generality) A load that forwards from a store must have the same address start point and therefore the same alignment as the store data.」
「アセンブリー/コンパイラー・コーディング規則 47 (影響 H、一般性 M): ストアの転送先であるロードは、ストアデータと同じ開始アドレスおよび同じアライメントでなければなりません。」
「Assembly/Compiler Coding Rule 48. (H impact, M generality) The data of a load which is forwarded from a store must be completely contained within the store data.」
「アセンブリー/コンパイラー・コーディング規則 48 (影響 H、一般性 M): ストアから転送されるロードのデータ全体が、ストアデータに含まれていなければなりません。」
「Assembly/Compiler Coding Rule 49. (H impact, ML generality) If it is necessary to extract a non- aligned portion of stored data, read out the smallest aligned portion that completely contains the data and shift/mask the data as necessary. This is better than incurring the penalties of a failed store- forward.」
「アセンブリー/コンパイラー・コーディング規則 49 (影響 H、一般性 ML): ストアされるデータのうちアライメントされていない部分を抽出する必要がある場合、そのデータを含む、アライメントされた最小部分を読み出して、必要に応じてデータをシフト/マスクします。ストア・フォワーディングに失敗してペナルティーが生じるより、この操作を行ったほうが良いでしょう。」
「Assembly/Compiler Coding Rule 50. (MH impact, ML generality) Avoid several small loads after large stores to the same area of memory by using a single large read and register copies as needed.」
「アセンブリー/コンパイラー・コーディング規則 50 (影響 MH、一般性 ML): 同じメモリー領域に対して、大きなデータ幅のストアの後に複数の小さなロードを続けないようにします。必要に応じて、1 回の大きな読み込みとレジスターのコピーを使用します。」
「Assembly/Compiler Coding Rule 51. (H impact, MH generality) Where it is possible to do so without incurring other penalties, prioritize the allocation of variables to registers, as in register allocation and for parameter passing, to minimize the likelihood and impact of store-forwarding problems. Try not to store-forward data generated from a long latency instruction - for example, MUL or DIV. Avoid store-forwarding data for variables with the shortest store-load distance. Avoid store- forwarding data for variables with many and/or long dependence chains, and especially avoid including a store forward on a loop-carried dependence chain.」
「アセンブリー/コンパイラー・コーディング規則 51 (影響 H、一般性 MH): ストア・フォワーディングの問題が起こる可能性とその影響が最小限に抑えられるように、(レジスターの割り当てやパラメーターの受け渡しの際に) レジスターへの変数の割り当てに優先順位を付けます (これによって他のペナルティーが生じない場合)。レイテンシーが大きい命令 (例えば、MUL、DIV) によるデータ、ストアとロードの間隔が非常に小さい変数のデータ、多数の依存関係チェーンまたは長い依存関係チェーンを含む変数のデータには、ストア・フォワーディングを適用しません。特に、ループ伝搬依存関係チェーンにはストア・フォワーディングを適用しません。」
「Assembly/Compiler Coding Rule 52. (M impact, MH generality) Calculate store addresses as early as possible to avoid having stores block loads.」
「アセンブリー/コンパイラー・コーディング規則 52 (影響 M、一般性 MH): ロードがストアの完了を待たずに進行するように、できるだけ早くストアアドレスを計算します。」
「Assembly/Compiler Coding Rule 53. (H impact, M generality) Try to arrange data structures such that they permit sequential access.」
「アセンブリー/コンパイラー・コーディング規則 53 (影響 H、一般性 M): 連続してアクセスできるように、データ構造を配置します。」
「Assembly/Compiler Coding Rule 54. (H impact, M generality) Make sure that the stack is aligned at the largest multi-byte granular data type boundary matching the register width.」
「アセンブリー/コンパイラー・コーディング規則 54 (影響 H、一般性 M): 64 ビット・データがスタック上でパラメーターとして渡されるか、割り当てられる可能性がある場合は、常にスタックのアライメントを 8 バイト境界に合わせます。」
「Assembly/Compiler Coding Rule 55. (H impact, M generality) Avoid having a store followed by a non-dependent load with addresses that differ by a multiple of 4 KBytes. Also, lay out data or order computation to avoid having cache lines that have linear addresses that are a multiple of 64 KBytes apart in the same working set. Avoid having more than 4 cache lines that are some multiple of 2 KBytes apart in the same first-level cache working set, and avoid having more than 8 cache lines that are some multiple of 4 KBytes apart in the same first-level cache working set.」
「アセンブリー/コンパイラー・コーディング規則 55 (影響 H、一般性 M): ストアの後に、4KB の倍数となるアドレスを持つ独立したロードが続かないようにします。また、64KB の倍数となるリニアアドレスを持つ複数のキャッシュラインが同じワーキングセットに含まれないように、データをレイアウトするか、計算の順序を変更します。同じ 1 次キャッシュ・ワーキング・セット内で、2KB の倍数離れたキャッシュラインの数が 4 つを超えないようにします。また、同じ 1 次キャッシュ・ワーキング・セット内で、4KB 倍数離れたキャッシュラインの数が 8 つを超えないようにします。」
「Assembly/Compiler Coding Rule 56. (M impact, L generality) If (hopefully read-only) data must occur on the same page as code, avoid placing it immediately after an indirect jump. For example, follow an indirect jump with its mostly likely target, and place the data after an unconditional branch.」
「アセンブリー/コンパイラー・コーディング規則 56 (影響 M、一般性 L): コードと同じページ上に (読み出し専用の) データを置かざるをえない場合は、間接ジャンプの直後にそのデータを置かないようにします。例えば、間接ジャンプの直後にはそのジャンプのターゲットになる可能性の高いコードを置き、無条件分岐の後にデータを配置します。」
「Assembly/Compiler Coding Rule 57. (H impact, L generality) Always put code and data on separate pages. Avoid self-modifying code wherever possible. If code is to be modified, try to do it all at once and make sure the code that performs the modifications and the code being modified are on separate 4-KByte pages or on separate aligned 1-KByte subpages.」
「アセンブリー/コンパイラー・コーディング規則 57 (影響 H、一般性 L): コードとデータは常に別のページに配置します。自己修正コードは極力使用しないようにします。コードが修正される場合は、すべて一度に修正するようにして、修正を実行する側のコードと修正される側のコードを別の 4KB ページに置くか、別々のアライメントされた 1KB サブページに置きます。」
「Assembly/Compiler Coding Rule 58. (H impact, L generality) If an inner loop writes to more than four arrays (four distinct cache lines), apply loop fission to break up the body of the loop such that only four arrays are being written to in each iteration of each of the resulting loops.」
「アセンブリー/コンパイラー・コーディング規則 58 (影響 H、一般性 L): 内部ループによって 5 つ以上の配列 (4 つの異なるキャッシュライン) にデータが書き込まれる場合、ループの本体を分割しそれぞれのループ反復で書き込まれる配列を 4 つ以内に抑えるようにします。
ライト・コンバイニング・バッファーは、すべての」
「Assembly/Compiler Coding Rule 59. (H impact, M generality) Minimize changes to bits 8-12 of the floating-point control word. Changes for more than two values (each value being a combination of the following bits: precision, rounding and infinity control, and the rest of bits in FCW) leads to delays that are on the order of the pipeline depth.」
「アセンブリー/コンパイラー・コーディング規則 59 (影響 H、一般性 M): 浮動小数点制御ワードのビット 8 ～ 12 の変更を最小限にします。3 つ以上の値 (各値は次のビットの組み合わせ。精度制御、丸め制御、無限大制御、FCW の残りのビット) の間で切り替えると、パイプラインの段数にほぼ相当する遅延が発生します。」
「Assembly/Compiler Coding Rule 60. (H impact, L generality) Minimize the number of changes to the rounding mode. Do not use changes in the rounding mode to implement the floor and ceiling functions if this involves a total of more than two values of the set of rounding, precision, and infinity bits.」
「アセンブリー/コンパイラー・コーディング規則 60 (影響 H、一般性 L): 丸めモードの変更回数を最小限に抑えます。丸めビット、精度ビット、無限大ビットが合計3つ以上の値の間で切り替えられる場合は、丸めモードの変更を使ってフロアー関数とシーリング関数を実行してはなりません。」
「Assembly/Compiler Coding Rule 61. (H impact, L generality) Minimize the number of changes to the precision mode.」
「アセンブリー/コンパイラー・コーディング規則 61 (影響 H、一般性 L): 精度モードの変更回数を最小限に抑えます。」
「Assembly/Compiler Coding Rule 62. (M impact, M generality) Use Streaming SIMD Extensions 2 or Streaming SIMD Extensions unless you need an x87 feature. Most SSE2 arithmetic operations have shorter latency then their X87 counterpart and they eliminate the overhead associated with the management of the X87 register stack.」
「アセンブリー/コンパイラー・コーディング規則 62 (影響 M、一般性 M): x87命令の機能が特に必要な場合以外は、インテル® ストリーミング SIMD 拡張命令 2 またはインテル® ストリーミング SIMD 拡張命令を使用します。大部分のインテル® SSE2 算術演算は x87 よりもレイテンシーが小さく、x87 レジスタースタックの管理に関連するオーバーヘッドが生じません。」
「Assembly/Compiler Coding Rule 63. (H impact, M generality) Use the 32-bit versions of instructions in 64-bit mode to reduce code size unless the 64-bit version is necessary to access 64-bit data or additional registers.」
「アセンブリー/コンパイラー・コーディング規則 63 (影響 H、一般性 M): 64 ビット・モードでは、64 ビット・データや追加レジスターへのアクセスに 64 ビット版の命令が必要な場合を除き、32 ビット版の命令を使うことでコードサイズを削減します。」
「Assembly/Compiler Coding Rule 64. (M impact, MH generality) When they are needed to reduce register pressure, use the 8 extra general purpose registers for integer code and 8 extra XMM registers for floating-point or SIMD code.」
「アセンブリー/コンパイラー・コーディング規則 64 (影響 H、一般性 MH): レジスターへの負荷削減に必要であれば、整数コードには 8 つの追加汎用レジスターと、浮動小数点および SIMD コードには 8 つの追加 XMM レジスターを使用します。」
「Assembly/Compiler Coding Rule 65. (ML impact, M generality) Prefer 64-bit by 64-bit integer multiplication that produces 64-bit results over multiplication that produces 128-bit results.」
「アセンブリー/コンパイラー・コーディング規則 65 (影響 ML、一般性 M): 128 ビットの結果を生成する乗算よりも、64 ビットの結果を生成する 64 ビット同士の整数乗算を優先します。」
「Assembly/Compiler Coding Rule 66. (ML impact, M generality) Stagger accessing the high 64-bit result of a 128-bit multiplication after accessing the low 64-bit results.」
「アセンブリー/コンパイラー・コーディング規則 66 (影響 ML、一般性 M): 128 ビット乗算の下位 64ビットの結果にアクセスした後に、上位 64 ビットの結果にアクセスしないようにします。」
「Assembly/Compiler Coding Rule 67. (ML impact, M generality) Use the 64-bit versions of multiply for 32-bit integer multiplies that require a 64 bit result.」
「アセンブリー/コンパイラー・コーディング規則 67 (影響 ML、一般性 M): 64 ビットの結果が必要な 32 ビットの整数乗算には、64 ビット版の乗算を使用します。」
「Assembly/Compiler Coding Rule 68. (ML impact, M generality) Use the 64-bit versions of add for 64-bit adds.」
「アセンブリー/コンパイラー・コーディング規則 68 (影響 ML、一般性 M): 64 ビットの加算には、64 ビット版の加算を使用します。」
「Assembly/Compiler Coding Rule 69. (L impact, L generality) If software prefetch instructions are necessary, use the prefetch instructions provided by SSE.」
「アセンブリー/コンパイラー・コーディング規則 69 (影響 L、一般性 L): ソフトウェア・プリフェッチ命令が必要な場合は、インテル® SSE 命令セットで提供されているプリフェッチ命令を使用します。」
「Assembly/Compiler Coding Rule 70. (H impact, H generality) Whenever a 256-bit AVX code block and 128-bit SSE code block might execute in sequence, use the VZEROUPPER instruction to facilitate a transition to a “Clean” state for the next block to execute from.」
「アセンブリー/コンパイラー・コーディング規則 70 (影響 H、一般性 H): 256 ビットのインテル® AVX コードブロックと 128 ビットのインテル® SSE コードブロックが連続して実行する場合は、次のコードブロックを実行する “クリーン” ステートへの移行を容易にするため常に VZEROUPPER 命令を使用します。」
「Assembly/Compiler Coding Rule 71. (H impact, H generality) Add VZEROUPPER instruction after 256-bit AVX instructions are executed and before any function call that might execute SSE code. Add VZEROUPPER at the end of any function that uses 256-bit AVX instructions.」
「アセンブリー/コンパイラー・コーディング規則 71 (影響 H、一般性 H): 256 ビットのインテル® AVX 命令が実行された後と、インテル® SSE コードが実行される関数呼び出しの前には、VZEROUPPER 命令を追加します。さらに、256 ビットのインテル® AVX 命令を使用するすべての関数の終わりに VZEROUPPER 命令を追加します。」
「Assembly/Compiler Coding Rule 72. (H impact, M generality) Align data to 32-byte boundary when possible. Prefer store alignment over load alignment.」
「アセンブリー/コンパイラー・コーディング規則 72 (影響 H、一般性 M): 可能な限りデータを 32 バイトにアライメントします。ロードのアライメントよりもストアのアライメントの方が重要です。」
「Assembly/Compiler Coding Rule 73. (M impact, H generality) Align data to 32-byte boundary when possible. Prefer store alignment over load alignment.」
「アセンブリー/コンパイラー・コーディング規則 73 (影響 M、一般性 H): 可能な限りデータを 32 バイトにアライメントします。ロードのアライメントよりもストアのアライメントの方が重要です。」
「Assembly/Compiler Coding Rule 74. (M impact, M generality) Use Blend instructions in lieu of shuffle instruction in AVX whenever possible.」
「アセンブリー/コンパイラー・コーディング規則 74 (影響 M、一般性 M): インテル® AVX のシャッフル命令の代わりに、可能であればブレンド命令を使用します。」
SSE4.2 Coding Rule
「SSE4.2 Coding Rule 5. (H impact, H generality) Loop-carry dependency that depends on the ECX result of PCMPESTRI/PCMPESTRM/PCMPISTRI/PCMPISTRM for address adjustment must be minimized. Isolate code paths that expect ECX result will be 16 (bytes) or 8 (words), replace these values of ECX with constants in address adjustment expressions to take advantage of memory disambiguation hardware.」
「インテル® SSE4.2 コーディング規則 5 (影響 H、一般性 H): アドレス調整を PCMPESTRI、PCMPESTRM、PCMPISTRI、PCMPISTRM の ECX 結果に依存しているループ伝搬依存は、最小限に抑えなければなりません。メモリー・ディスアンビゲーション・ハードウェアを利用するには、ECX 結果が 16 (バイト) または 8 (ワード) になると予期されるコードパスを特定し、これらの ECX 値をアドレス調整式の定数に置き換えます。」
SSE4.2 コーディング規則1から4はないのか？
User/Source Coding Rule
「User/Source Coding Rule 1. (M impact, L generality) If an indirect branch has two or more common taken targets and at least one of those targets is correlated with branch history leading up to the branch, then convert the indirect branch to a tree where one or more indirect branches are preceded by conditional branches to those targets. Apply this “peeling” procedure to the common target of an indirect branch that correlates to branch history.」
「ユーザー/ソース・コーディング規則 1 (影響 M、一般性 M): 反復数の多いショートループでループアンロールを利用する場合は、反復あたりの命令数を 28 未満に抑えます。」
「ユーザー/ソース・コーディング規則 1 (影響 M、一般性 L): 間接分岐が一般的な分岐するターゲットを 2 つ以上持っており、それらのターゲットの少なくとも 1 つがその分岐までの分岐履歴に関係している場合は、その間接分岐をツリーに変換し、1 つ以上の間接分岐の前にそれらのターゲットに対する条件分岐を配置します。この「ピーリング」手順は、分岐履歴に関係している間接分岐の一般的なターゲットに適用します。」
「User/Source Coding Rule 2. (H impact, M generality) Use the smallest possible floating-point or SIMD data type, to enable more parallelism with the use of a (longer) SIMD vector. For example, use single precision instead of double precision where possible.」
「ユーザー/ソース・コーディング規則 2 (影響 M、一般性 L): 除算は真に必要な場合のみ利用し、最も効率良く実行できるように正しいデータサイズと符号を使用します。」
「ユーザー/ソース・コーディング規則 2 (影響 H、一般性 M): 長い SIMD ベクトルを使用してより多くの並列処理が可能となるように、できるだけ小さい浮動小数点データ型または SIMD データ型を使用します。例えば、可能な限り倍精度の代わりに単精度を使用します。」
「User/Source Coding Rule 3. (M impact, ML generality) Arrange the nesting of loops so that the innermost nesting level is free of inter-iteration dependencies. Especially avoid the case where the store of data in an earlier iteration happens lexically after the load of that data in a future iteration, something which is called a lexically backward dependence.」
「ユーザー/ソース・コーディング規則 3 (影響 M、一般性 M): パックド単精度要素の取得には PALIGNR を使用します。」
「ユーザー/ソース・コーディング規則 3 (影響 M、一般性 ML): 最内のネストレベルに反復間の依存関係が生じないように、ループのネストを構成します。特に、直前の反復で生成したデータのストアが、語彙的に直後の反復の同じデータのロードの後に生成されるのを避けます (これは語彙的な後方依存関係と呼ばれます)。」
「User/Source Coding Rule 4. (M impact, ML generality) Avoid the use of conditional branches inside loops and consider using SSE instructions to eliminate branches.」
「ユーザー/ソース・コーディング規則 4 (影響 M、一般性 ML): ループ中では条件分岐を使用しないようにします。インテル® SSE 命令を使用して分岐を減らします。」
「User/Source Coding Rule 5. (M impact, ML generality) Keep induction (loop) variable expressions simple.」
「ユーザー/ソース・コーディング規則 5 (影響 M、一般性 ML): 複雑なインダクション (ループ) 変数式を使用しないようにします。」
「User/Source Coding Rule 6. (H impact, M generality) Pad data structures defined in the source code so that every data element is aligned to a natural operand size address boundary.」
「ユーザー/ソース・コーディング規則 6 (影響 H、一般性 M): ソースコード内で定義されるデータ構造をパディングして、すべてのデータ要素のアライメントをオペランドサイズの自然アドレス境界に合わせます。」
「User/Source Coding Rule 7. (M impact, L generality) Beware of false sharing within a cache line (64 bytes).」
「ユーザー/ソース・コーディング規則 7 (影響 M、一般性 L): キャッシュライン (64 バイト) 内のフォルス・シェアリングに注意します。」
「User/Source Coding Rule 8. (H impact, ML generality) Consider using a special memory allocation library with address offset capability to avoid aliasing. One way to implement a memory allocator to avoid aliasing is to allocate more than enough space and pad. For example, allocate structures that are 68 KB instead of 64 KBytes to avoid the 64-KByte aliasing, or have the allocator pad and return random offsets that are a multiple of 128 Bytes (the size of a cache line).」
「ユーザー/ソース・コーディング規則 8 (影響 H、一般性 ML): エイリアシングを避けるため、アドレスオフセット機能を持つ特殊なメモリー・アロケーション・ライブラリーの使用を検討します。メモリー・アロケーターにエイリアシングを回避させる方法は、必要以上の空間とパディングを行うことです。例えば、64KB の代わりに 68KB の構造体を割り当てて、64KB のエイリアシングを避けます。あるいは、アロケーターにパディングを実行させ、128 バイト (キャッシュラインのサイズ) の倍数であるランダムなオフセットを返すようにします。」
「User/Source Coding Rule 9. (M impact, M generality) When padding variable declarations to avoid aliasing, the greatest benefit comes from avoiding aliasing on second-level cache lines, suggesting an offset of 128 bytes or more.」
「ユーザー/ソース・コーディング規則 9 (影響 M、一般性 M): エイリアシングを避けるために変数の宣言時にパディングを行う場合、2 次キャッシュライン上のエイリアシングを避ける方が大きなメリットが得られます。したがって、128 バイトまたはそれ以上のオフセットが必要になります。」
「User/Source Coding Rule 10. (H impact, H generality) Optimization techniques such as blocking, loop interchange, loop skewing, and packing are best done by the compiler. Optimize data structures either to fit in one-half of the first-level cache or in the second-level cache; turn on loop optimizations in the compiler to enhance locality for nested loops.」
「ユーザー/ソース・コーディング規則 10 (影響 H、一般性 H): ブロッキング、ループ交換、ループ傾斜、パッキングなどの最適化手法はコンパイラーに任せる方が良いでしょう。コンパイラーのループ最適化を有効にして、1 次キャッシュの半分または 2 次キャッシュ全体に収まるように、データ構造を最適化し、ネストされたループの局所性を向上させます。」
「User/Source Coding Rule 11. (M impact, ML generality) If there is a blend of reads and writes on the bus, changing the code to separate these bus transactions into read phases and write phases can help performance.」
「ユーザー/ソース・コーディング規則 11 (影響 M、一般性 ML): バス上で読み込みと書き込みの両方を行う場合、これらのバス・トランザクションを読み込みフェーズと書き込みフェーズに分離するようにコードを変更すると性能向上につながります。」
「User/Source Coding Rule 12. (H impact, H generality) To achieve effective amortization of bus latency, software should favor data access patterns that result in higher concentrations of cache miss patterns, with cache miss strides that are significantly smaller than half the hardware prefetch trigger threshold.」
「ユーザー/ソース・コーディング規則 12 (影響 H、一般性 H): バス・レイテンシーを効率良く軽減するには、キャッシュミス間隔がハードウェア・プリフェッチ・トリガーしきい値の半分よりも狭く、より集中したキャッシュ・ミス・パターンとなるデータアクセスを優先すべきです。」
「User/Source Coding Rule 13. (M impact, M generality) Enable the compiler’s use of SSE, SSE2 and more advanced SIMD instruction sets (e.g. AVX) with appropriate switches. Favor scalar SIMD code generation to replace x87 code generation.」
「ユーザー/ソース・コーディング規則 13 (影響 M、一般性 M): インテル® SSE 命令、インテル® SSE2 命令、またはより高度な SIMD 命令セット (インテル® AVX など) 使用したコードを生成するように、コンパイラーの最適化オプションを利用します。x87 コードの代わりにスカラー SIMD コードを生成します。」
「User/Source Coding Rule 14. (H impact, ML generality) Make sure your application stays in range
to avoid denormal values, underflows.」
「ユーザー/ソース・コーディング規則 14 (影響 H、一般性 ML): アプリケーションが浮動小数点値の有効範囲を超えないようにし、デノーマル値、アンダーフローを避けます。」
「User/Source Coding Rule 15. (M impact, ML generality) Usually, math libraries take advantage of the transcendental instructions (for example, FSIN) when evaluating elementary functions. If there is no critical need to evaluate the transcendental functions using the extended precision of 80 bits, applications should consider an alternate, software-based approach, such as a look-up-table-based algorithm using interpolation techniques. It is possible to improve transcendental performance with these techniques by choosing the desired numeric precision and the size of the look-up table, and by taking advantage of the parallelism of the SSE and the SSE2 instructions.」
「ユーザー/ソース・コーディング規則 15 (影響 M、一般性 ML): 通常は、数値演算ライブラリーは、初等関数を計算する際に超越関数命令 (例えば、FSIN) を利用します。超越関数を計算するとき、特に 80 ビットの拡張精度を使用する必要がない場合は、ソフトウェアに基づく別の手法 (補間法を使用するルックアップ・テーブル方式のアルゴリズムなど) を検討するべきです。これらの手法を使って、希望する数値精度とルックアップ・テーブルのサイズを選択し、インテル® SSE 命令とインテル® SSE2 命令の並列処理を利用すると、超越関数計算のパフォーマンスを向上できます。」
「User/Source Coding Rule 16. (H impact, ML generality) Denormalized floating-point constants should be avoided as much as possible.」
「ユーザー/ソース・コーディング規則 16 (影響 H、一般性 ML): できるだけデノーマル浮動小数点定数の使用を避けます。」
「User/Source Coding Rule 17. If CLFLUSHOPT is available, use CLFLUSHOPT over CLFLUSH and use SFENCE to guard CLFLUSHOPT to ensure write order is globally observed. If CLUSHOPT is not available, consider flushing large buffers with CLFLUSH in smaller chunks of less than 4KB.」
「ユーザー/ソース・コーディング規則 17: CLFLUSHOPT が利用できる場合、CLFLUSH よりも CLFLUSHOPT を使用します。CLFLUSHOPT が書き込みの順番をグローバルに反映することを確実にするため最後に SFENCE を挿入します。CLFLUSHOPT が利用できない場合、CLFLUSH を 4KB 未満の小さなチャンクで使用して、大きなバッファーをフラッシュすることを検討してください。」
「User/Source Coding Rule 18. (M impact, H generality) Insert the PAUSE instruction in fast spin loops and keep the number of loop repetitions to a minimum to improve overall system performance.」
「ユーザー/ソース・コーディング規則 18 (影響 M、一般性 H): 高速スピンループ中に PAUSE 命令を挿入し、ループの反復回数を最小限に抑え、システム全体の性能を向上させます。」
「User/Source Coding Rule 19. (M impact, L generality) Replace a spin lock that may be acquired by multiple threads with pipelined locks such that no more than two threads have write accesses to one lock. If only one thread needs to write to a variable shared by two threads, there is no need to use a lock.」
「ユーザー/ソース・コーディング規則 19 (影響 M、一般性 L): 複数のスレッドが取得可能なスピンロックを、2 つのスレッドしか 1 つのロックに書き込めないようなパイプライン化されたロックと置き換えます。2 つのスレッドが共有する変数に、1 つのスレッドしか書き込みを行う必要がない場合は、ロックを使用する必要はありません。」
「User/Source Coding Rule 20. (H impact, M generality) Use a thread-blocking API in a long idle loop to free up the processor.」
「ユーザー/ソース・コーディング規則 20 (影響 H、一般性 M): スレッド・ブロッキング API を長いアイドルループ内で使用し、プロセッサーを解放します。」
「User/Source Coding Rule 21. (H impact, M generality) Beware of false sharing within a cache line or within a sector. Allocate critical data or locks separately using alignment granularity not smaller than the “false-sharing threshold”.」
「ユーザー/ソース・コーディング規則 21 (影響 H、一般性 M): キャッシュライン、またはセクター内のフォルス・シェアリングに注意します。”フォルス・シェアリングのしきい値” ほど小さくないアライメントの粒度で分離して、重要なデータやロックを割り当てます。」
「User/Source Coding Rule 22. (M impact, ML generality) Place each synchronization variable alone, separated by 128 bytes or in a separate cache line.」
「ユーザー/ソース・コーディング規則 22 (影響 M、一般性 ML): 各同期変数を 128 バイトで分離して単独に配置するか、独立したキャッシュラインに格納します。」
「User/Source Coding Rule 23. (H impact, L generality) Do not place any spin lock variable to span a cache line boundary.」
「ユーザー/ソース・コーディング規則 23 (影響 H、一般性 L): スピンロック変数は、キャッシュライン境界をまたいで配置してはなりません。」
「User/Source Coding Rule 24. (M impact, H generality) Improve data and code locality to conserve bus command bandwidth.」
「ユーザー/ソース・コーディング規則 24 (影響 M、一般性 H): データおよびコードの局所性を改善し、バスコマンド帯域幅を保持します。」
「User/Source Coding Rule 25. (M impact, L generality) Avoid excessive use of software prefetch instructions and allow automatic hardware prefetcher to work. Excessive use of software prefetches can significantly and unnecessarily increase bus utilization if used inappropriately.」
「ユーザー/ソース・コーディング規則 25 (影響 M、一般性 L): ソフトウェア・プリフェッチ命令の過度な使用は避け、自動ハードウェア・プリフェッチを機能させます。ソフトウェア・プリフェッチを過度に使用すると、バス利用が大幅かつ不必要に増加する可能性があります (不適切に使用されている場合)。」
「User/Source Coding Rule 26. (M impact, M generality) Consider using overlapping multiple back- to-back memory reads to improve effective cache miss latencies.」
「ユーザー/ソース・コーディング規則 26 (影響 M、一般性 M): オーバーラップする複数の連続したメモリー読み込みにより、実効キャッシュ・ミス・レイテンシーを改善することを検討します。」
「User/Source Coding Rule 27. (M impact, M generality) Consider adjusting the sequencing of memory references such that the distribution of distances of successive cache misses of the last level cache peaks towards 64 bytes.」
「ユーザー/ソース・コーディング規則 27 (影響 M、一般性 M): 最終レベルキャッシュの連続するキャッシュミスの間隔が 64 バイトに近づくように、メモリー参照の順序付けを調整することを検討します。」
「User/Source Coding Rule 28. (M impact, M generality) Use full write transactions to achieve higher data throughput.」
「ユーザー/ソース・コーディング規則 28 (影響 M、一般性 M): フルサイズの書き込みトランザクションを使用して、より高いデータ・スループットを達成します。」
「User/Source Coding Rule 29. (H impact, H generality) Use cache blocking to improve locality of data access. Target one quarter to one half of the cache size when targeting Intel processors supporting HT Technology or target a block size that allow all the logical processors serviced by a cache to share that cache simultaneously.」
「ユーザー/ソース・コーディング規則 29 (影響 H、一般性 H): キャッシュ・ブロッキングを使用して、データアクセスの局所性を改善します。HT テクノロジー対応のインテル®プロセッサーが対象の場合、キャッシュサイズの 4 分の 1 から 2 分の 1 を目標とします。または、特定のキャッシュをアクセスするすべての論理プロセッサーがそのキャッシュを同時に共有可能なブロックサイズを目標とします。」
「User/Source Coding Rule 30. (H impact, M generality) Minimize the sharing of data between threads that execute on different bus agents sharing a common bus. The situation of a platform consisting of multiple bus domains should also minimize data sharing across bus domains.」
「ユーザー/ソース・コーディング規則 30 (影響 H、一般性 M): バスを共有する別々のバス・エージェント上で実行されるスレッド間で、データの共有を最小限に抑えます。プラットフォームが複数のバスドメインで構成されている場合、バスドメイン間でのデータ共有も最小限に抑える必要があります。」
User/Source Coding Rule 31. (H impact, H generality) Minimize data access patterns that are offset by multiples of 64 KBytes in each thread.
User/Source Coding Rule 32. (M impact, L generality) Avoid excessive loop unrolling to ensure the LSD is operating efficiently.
User/Source Coding Rule 33. Factor in precision and rounding characteristics of FMA instructions when replacing multiply/add operations executing non-FMA instructions. FMA improves performance when an algorithm is execution-port throughput limited, like DGEMM.
User/Source Coding Rule 34. Factor in result-dependency, latency of FP add vs. FMA instructions when replacing FP add operations with FMA instructions.
User/Source Coding Rule 35. Consider using unrolling technique for loops containing back-to-back dependent FMA, FP Add or Vector MUL operations, The unrolling factor can be chosen by considering the latency of the critical instruction of the dependency chain and the number of pipes available to execute that instruction.
User/Source Coding Rule 36. When using RTM for implementing lock elision, always test for lock inside the transactional region.
User/Source Coding Rule 37. RTM abort handlers must provide a valid tested non transactional fallback path.
Tuning Suggestion
Tuning Suggestion 1. Use the perfmon counter MS_DECODED.MS_ENTRY to find the number of instructions that need the MSROM (the count will include any assist or fault that occurred).
Tuning Suggestion 2. Use the perfmon counter DECODE_RESTRICTION.PREDECODE_WRONG to count the number of times that a decode restriction reduced instruction decode throughput because predecoded bits are incorrect.
Tuning Suggestion 14. Don't use an RTM wrapper if the lock variable is not readable in the wrapper.
Tuning Suggestion 16. Lock Busy retries should wait for the lock to become free again.
文書履歴(document history)
ver. 0.10 Assembly/Compiler Coding Rule 20181206 午前
ver. o.11 追記 午後