1 <10の比較は1 <1000000よりも安価ですか？

z-indexCSSのaのカウントとして〜10億を使用し、比較を検討する必要がありました。非常に大きな数値と非常に小さな数値との比較で、ALUレベルでパフォーマンスに違いはありますか？

たとえば、これら2つのスニペットのうちの1つは他のスニペットよりも高価ですか？

snippet 1

for (int i = 0; i < 10000000; i++){
    if (i < 10000000000000) {
        //do nothing
    }
}

snippet 2

for (int i = 0; i < 10000000; i++){
    if (i < 1000) {
        //do nothing
    }
}

私が取り組んだすべてのプロセッサは、一方のオペランドを他方から減算し、結果を破棄し、プロセッサのフラグ（ゼロ、ネガティブなど）をそのままにして比較を行います。減算は単一の操作として行われるため、オペランドの内容は重要ではありません。

質問に確実に答える最良の方法は、コードをアセンブリにコンパイルし、生成された命令についてターゲットプロセッサのドキュメントを参照することです。現在のIntel CPUの場合、それはIntel 64およびIA-32アーキテクチャソフトウェア開発者マニュアルです。

説明CMP（「比較」）命令は、ボリューム2A、ページ3から126、またはPDFのページ618にあり、且つとしてその動作を説明します。

temp ← SRC1 − SignExtend(SRC2);
ModifyStatusFlags; (* Modify status flags in the same manner as the SUB instruction*)

これは、必要に応じて第2オペランドが符号拡張され、第1オペランドから減算され、結果がプロセッサの一時領域に配置されることを意味します。その後、ステータスフラグはSUB（ "減算"）命令（PDFのページ1492）の場合と同じ方法で設定されます。

そこには言及しませんCMPかSUBオペランドの値は、待ち時間上の任意のベアリングを持っているドキュメントは、あなたが使用するすべての値が安全です。

非常に大きな数値と非常に小さな数値との比較で、ALUレベルでパフォーマンスに違いはありますか？

多数の少数から行くことあなたの数値型を変更しない限り、それは、非常に低いですから、言うintまでlong。それでも、違いはそれほど大きくないかもしれません。プログラミング言語が隠れて任意の精度の算術演算に静かに切り替わると、違いが生じる可能性が高くなります。

それにもかかわらず、あなたの特定のコンパイラは、あなたが知らないいくつかの巧妙な最適化を実行しているかもしれません。調べる方法は測定することです。 コードでプロファイラーを実行します。どの比較に最も時間がかかるかを確認してください。または、単にタイマーを開始および停止します。

多くのプロセッサには、すぐに指定された特定のオペランドに対して比較などの算術演算を実行できる「小さな」命令があります。これらの特別な値以外のオペランドは、より大きな命令形式を使用するか、場合によっては「メモリから値をロードする」命令を使用する必要があります。たとえば、ARM Cortex-M3命令セットでは、少なくとも5つの方法で値を定数と比較できます。

    cmp r0,#1      ; One-word instruction, limited to values 0-255

    cmp r0,#1000   ; Two-word instruction, limited to values 0-255 times a power of 2

    cmn r0,#1000   ; Equivalent to comparing value with -1000
                   ; Two-word instruction, limited to values 0-255 times a power of 2

    mov r1,#30000  ; Two words; can handle any value 0-65535
    cmp r0,r1      ; Could use cmn to compare to values -1 to -65535

    ldr r1,[constant1000000] ; One or two words, based upon how nearby the constant is
    cmp r0,r1
    ...

constant1000000:
    dd  1000000

最初の形式は最小です。2番目と3番目の形式は、コードがフェッチされるメモリの速度に応じて、同じくらい速く実行される場合とされない場合があります。4番目の形式はほぼ確実に最初の3つより遅くなり、5番目の形式はさらに遅くなりますが、後者はどの32ビット値でも使用できます。

古いx86プロセッサでは、短い形式の比較命令は長い形式の命令よりも高速に実行されますが、多くの新しいプロセッサは、長い形式と短い形式の両方を最初にフェッチするときに同じ表現に変換し、その統一表現をキャッシュに保存します。したがって、組み込みコントローラ（多くのモバイルプラットフォームで見られるような）には速度の違いがありますが、多くのx86ベースのコンピュータには違いがありません。

また、ループ内で定数が頻繁に使用される多くの場合、コンパイラーは、定数をレジスターに一度ロードするだけで済みます-ループが開始する前に-タイミングの違いを議論する必要があります。一方、小さなループであっても、常に発生するとは限らない状況があります。ループが小さいが頻繁に実行される場合、短い即時値を含む比較と長い即時値を含む比較の間に大きなパフォーマンスが得られる場合があります。

この質問に対する簡単な答えは、いいえ、それらが同じデータ型に格納されていると仮定して、それらの数値の大きさに基づいて2つの数値を比較する時間差はありません（たとえば、両方の32ビット整数または両方の64ビット長）

さらに、ALUのワードサイズまでは、2つの整数を比較するのに1クロックサイクル以上かかることはほとんどありません。これは、減算と同等の簡単な操作だからです。私がこれまでに扱ったすべてのアーキテクチャには、シングルサイクル整数比較があったと思います。

2つの数値の比較が単一サイクル操作ではなかった場合に遭遇したと考えることができる唯一のケースは次のとおりです。

• 実際にオペランドをフェッチする際にメモリレイテンシがある命令ですが、比較自体の動作とは関係ありません（通常、RISCアーキテクチャでは不可能ですが、通常x86 / x64などのCISC設計では可能です）。
• アーキテクチャに応じて、浮動小数点比較はマルチサイクルになる場合があります。
• 問題の数値はALUのワードサイズに適合しないため、比較は複数の命令に分割する必要があります。

@RobertHarveyの答えは良いです。この回答を彼の補足と考えてください。

分岐予測も考慮する必要があります。

コンピュータアーキテクチャでは、分岐予測子は、分岐（if-then-else構造など）が確実に知られる前にどの方向に進むかを推測しようとするデジタル回路です。分岐予測の目的は、命令パイプラインのフローを改善することです。分岐予測器は、x86などの多くの最新のパイプラインマイクロプロセッサアーキテクチャで高い効果的なパフォーマンスを達成する上で重要な役割を果たします。

基本的に、あなたの例でifは、ループ内のステートメントが常に同じ答えを返す場合、システムは分岐する方法を正しく推測することでそれを最適化できます。この例でifは、最初のケースのステートメントは常に同じ結果を返すため、2番目のケースよりもわずかに高速に実行されます。

件名に関する優れたスタックオーバーフローの質問

それは実装に依存しますが、非常にありそうにないでしょう。

さまざまなブラウザエンジンの実装の詳細を読んでいないことを認めます。CSSは、数値用の特定の種類のストレージを指定しません。しかし、主要なブラウザはすべて、64ビットの倍精度浮動小数点数（「double」、C / C ++から用語を借用）を使用して、CSSでの数値ニーズのほとんどを処理していると考えるのが安全だと思いますこれはJavaScriptが数値に使用するものであり、同じ型を使用すると統合が容易になるためです。

コンピューターの観点から見ると、すべてのdoubleは同じ量のデータ（値が1または-3.14または1000000または1e100であるかどうかに関係なく64ビット）を保持します。これらの数値を操作するのにかかる時間は、常に同じ量のデータを処理しているため、それらの数値の実際の値に依存しません。このように物事を行うにはトレードオフがあります。doublesはすべての数字（または範囲内のすべての数字）を正確に表すことができませんが、ほとんどの問題に対して十分に近づくことができ、CSSが行う種類のことは数字ではありません-それ以上の精度が必要なほど要求が厳しい。これとJavaScriptとの直接的な互換性の利点を組み合わせると、倍精度の非常に強力なケースが得られます。

数値に可変長エンコードを使用してCSSを実装することは不可能ではありません。誰かが可変長符号化を使用した場合は、その後、多数のクランチより多くのデータを持っているので、小さな数字と比較することは、大きな数字と比較するよりも安価になります。これらの種類のエンコードは、バイナリよりも正確ですが、非常に低速です。特にCSSの場合、精度の向上はおそらくパフォーマンスヒットに見合うほど十分ではありません。どんなブラウザでもこのように動作することを知って非常に驚いたでしょう。

さて、理論的には、私が上で述べたことすべてに1つの例外があります。ゼロとの比較は、他の数値との比較よりも速いことがよくあります。これは、ゼロが短いためではありません（それが理由である場合、1は同様に高速であるべきですが、そうではありません）。ゼロはチートできるからです。これは、すべてのビットがオフになっている唯一の数値です。したがって、値の1つがゼロであることがわかっている場合、他の値を数値として見る必要さえありません。ゼロの場合は、1ビットだけを見て、ゼロより大きいか小さいかを確認します。

このコードは、それが実行するたびに解釈されていた場合、それはtokeniseと解釈するのに長い時間を要するとして、違いがあると思います10000000000000に比べて1000。ただし、これはこの場合のインタープリターの明らかな最初の最適化です：一度トークン化し、トークンを解釈します。