整数が既知の値のセットを持つ2つの整数（両端を含む）の間にあるかどうかを判断する最速の方法

x >= start && x <= endCまたはC ++ よりも整数が2つの整数の間にあるかどうかをテストするより速い方法はありますか？

更新：私の特定のプラットフォームはiOSです。これは、ピクセルを特定の正方形の円に制限するボックスぼかし関数の一部です。

更新：受け入れられた回答を試した後、通常のx >= start && x <= end方法よりも1行のコードで桁違いに高速化しました。

更新：XCodeからのアセンブラーを使用した前後のコードは次のとおりです。

新しい方法

// diff = (end - start) + 1
#define POINT_IN_RANGE_AND_INCREMENT(p, range) ((p++ - range.start) < range.diff)

Ltmp1313:
 ldr    r0, [sp, #176] @ 4-byte Reload
 ldr    r1, [sp, #164] @ 4-byte Reload
 ldr    r0, [r0]
 ldr    r1, [r1]
 sub.w  r0, r9, r0
 cmp    r0, r1
 blo    LBB44_30

古い方法

#define POINT_IN_RANGE_AND_INCREMENT(p, range) (p <= range.end && p++ >= range.start)

Ltmp1301:
 ldr    r1, [sp, #172] @ 4-byte Reload
 ldr    r1, [r1]
 cmp    r0, r1
 bls    LBB44_32
 mov    r6, r0
 b      LBB44_33
LBB44_32:
 ldr    r1, [sp, #188] @ 4-byte Reload
 adds   r6, r0, #1
Ltmp1302:
 ldr    r1, [r1]
 cmp    r0, r1
 bhs    LBB44_36

分岐を削減または排除することで、このような劇的なスピードアップを実現できることは驚くべきことです。

1つの比較/ブランチだけでこれを行うには古いトリックがあります。速度が本当に向上するかどうかは疑問視される可能性があり、たとえそうであっても、おそらく気づいたり気にかけたりするには少なすぎますが、2つの比較から始めただけでは、大幅な改善の可能性はかなり低いものです。コードは次のようになります。

// use a < for an inclusive lower bound and exclusive upper bound
// use <= for an inclusive lower bound and inclusive upper bound
// alternatively, if the upper bound is inclusive and you can pre-calculate
//  upper-lower, simply add + 1 to upper-lower and use the < operator.
    if ((unsigned)(number-lower) <= (upper-lower))
        in_range(number);

典型的な現代のコンピューター（つまり、2の補数を使用するもの）では、unsignedへの変換は実際にはnopです。同じビットの表示方法が変更されるだけです。

典型的なケースではupper-lower、（推定）ループの外側で事前計算できるため、通常は大幅な時間の増加にはなりません。これにより、分岐命令の数が減るだけでなく、（一般的に）分岐予測も改善されます。この場合、数値が範囲の下端より上か上端かにかかわらず、同じ分岐が行われます。

これがどのように機能するかについては、基本的な考え方はかなり単純です。負の数は、符号なしの数として見た場合、正の数として始まったものよりも大きくなります。

実際には、この方法は、変換numberと原点とのチェックポイントに間隔があればnumber区間である[0, D]場合、D = upper - lower。number下限を下回る場合：負、上限を上回る場合：より大きいD。

そのような小規模でコードを大幅に最適化できることはまれです。パフォーマンスを大幅に向上させるには、上位レベルからコードを監視および変更します。範囲テストを完全に不要にするか、O（n ^ 2）ではなくO（n）のみを実行できる場合があります。不等式の片側が常に暗示されるように、テストを並べ替えることができる場合があります。アルゴリズムが理想的であるとしても、このコードが範囲テストを1000万回実行する方法を見て、それらをバッチ処理し、SSEを使用して多くのテストを並行して実行する方法を見つけると、利益が得られる可能性が高くなります。

同じデータに対してテストを何回実行するかによって異なります。

テストを1回実行する場合、アルゴリズムを高速化する意味のある方法はおそらくありません。

非常に有限な値のセットに対してこれを行う場合は、ルックアップテーブルを作成できます。インデックス作成の実行はコストが高くなる可能性がありますが、テーブル全体をキャッシュに収めることができる場合は、コードからすべての分岐を削除できます。これにより、処理速度が向上します。

データの場合、ルックアップテーブルは128 ^ 3 = 2,097,152になります。3つの変数のいずれかを制御して、一度にすべてのインスタンスを考慮することができる場合start = N、ワーキングセットのサイズは128^2 = 16432バイトに下がり、ほとんどの最新のキャッシュにうまく収まります。

ブランチレスルックアップテーブルが明らかな比較よりも十分に速いかどうかを確認するには、実際のコードをベンチマークする必要があります。

この回答は、受け入れられた回答で行われたテストについて報告することです。私はソートされたランダムな整数の大きなベクトルに対してクローズドレンジテストを実行しましたが、驚いたことに（low <= num && num <= high）の基本的な方法は実際には上記の受け入れられた回答よりも高速です！テストはHP Pavilion g6（AMD A6-3400APUと6GB RAM）で行われました。テストに使用されたコアコードは次のとおりです。

int num = rand();  // num to compare in consecutive ranges.
chrono::time_point<chrono::system_clock> start, end;
auto start = chrono::system_clock::now();

int inBetween1{ 0 };
for (int i = 1; i < MaxNum; ++i)
{
    if (randVec[i - 1] <= num && num <= randVec[i])
        ++inBetween1;
}
auto end = chrono::system_clock::now();
chrono::duration<double> elapsed_s1 = end - start;

上記で受け入れられた答えである以下と比較してください：

int inBetween2{ 0 };
for (int i = 1; i < MaxNum; ++i)
{
    if (static_cast<unsigned>(num - randVec[i - 1]) <= (randVec[i] - randVec[i - 1]))
        ++inBetween2;
}

randVecはソートされたベクトルであることに注意してください。MaxNumのサイズに関係なく、私のマシンでは最初の方法が2番目の方法よりも優れています！

変数の範囲をチェックする場合：

if (x >= minx && x <= maxx) ...

ビット操作を使用する方が高速です。

if ( ((x - minx) | (maxx - x)) >= 0) ...

これにより、2つのブランチが1つに削減されます。

タイプセーフに関心がある場合：

if ((int32_t)(((uint32_t)x - (uint32_t)minx) | ((uint32_t)maxx - (uint32_t)x)) > = 0) ...

より多くの変数範囲チェックを組み合わせることができます。

if (( (x - minx) | (maxx - x) | (y - miny) | (maxy - y) ) >= 0) ...

これにより、4つのブランチが1つに削減されます。

これはgccの古いものより3.4倍高速です。

整数に対してビット演算を実行することは不可能ですか？

0から128の間でなければならないため、8番目のビットが設定されている場合（2 ^ 7）、128以上になります。ただし、包括的な比較が必要なため、エッジケースは面倒です。