Específicamente, si tengo una serie de if... else ifdeclaraciones, y de alguna manera sé de antemano la probabilidad relativa de que cada declaración se evalúe true, ¿cuánta diferencia en el tiempo de ejecución representa ordenarlas en orden de probabilidad? Por ejemplo, debería preferir esto:

if (highly_likely)
  //do something
else if (somewhat_likely)
  //do something
else if (unlikely)
  //do something

¿a esto?:

if (unlikely)
  //do something
else if (somewhat_likely)
  //do something
else if (highly_likely)
  //do something

Parece obvio que la versión ordenada sería más rápida, sin embargo, para facilitar la lectura o la existencia de efectos secundarios, es posible que desee ordenarlos de manera no óptima. También es difícil saber qué tan bien funcionará la CPU con la predicción de bifurcación hasta que realmente ejecute el código.

Entonces, en el transcurso de experimentar con esto, terminé respondiendo mi propia pregunta para un caso específico, sin embargo, también me gustaría escuchar otras opiniones / ideas.

Importante: esta pregunta supone que las ifdeclaraciones se pueden reordenar arbitrariamente sin tener ningún otro efecto sobre el comportamiento del programa. En mi respuesta, las tres pruebas condicionales son mutuamente excluyentes y no producen efectos secundarios. Ciertamente, si las declaraciones deben evaluarse en un cierto orden para lograr el comportamiento deseado, entonces el tema de la eficiencia es discutible.

Como regla general, la mayoría de las CPU de Intel, si no todas, suponen que las ramas hacia adelante no se toman la primera vez que las ven. Ver el trabajo de Godbolt .

Después de eso, la rama entra en un caché de predicción de rama, y ​​el comportamiento pasado se utiliza para informar la predicción de rama futura.

Entonces, en un circuito cerrado, el efecto de la falta de orden será relativamente pequeño. El predictor de rama aprenderá qué conjunto de ramas es más probable, y si tiene una cantidad de trabajo no trivial en el ciclo, las pequeñas diferencias no sumarán mucho.

En general, la mayoría de los compiladores por defecto (sin otro motivo) ordenarán el código de máquina producido aproximadamente de la manera en que lo ordenó en su código. Por lo tanto, si las declaraciones son ramas hacia adelante cuando fallan.

Por lo tanto, debe ordenar sus ramas en el orden de probabilidad decreciente de obtener la mejor predicción de rama de un "primer encuentro".

Un microbenchmark que se repite muchas veces en un conjunto de condiciones y realiza un trabajo trivial estará dominado por pequeños efectos del recuento de instrucciones y similares, y poco en cuanto a los problemas relativos de predicción de ramas. Entonces, en este caso, debe crear un perfil , ya que las reglas generales no serán confiables.

Además de eso, la vectorización y muchas otras optimizaciones se aplican a pequeños bucles estrechos.

Entonces, en el código general, coloque el código más probable dentro del ifbloque, y eso dará como resultado la menor cantidad de errores de predicción de ramificación no almacenados en caché. En bucles ajustados, siga la regla general para comenzar, y si necesita saber más, no tiene más remedio que hacer un perfil.

Naturalmente, todo esto desaparece si algunas pruebas son mucho más baratas que otras.

Hice la siguiente prueba para cronometrar la ejecución de dos if... else ifbloques diferentes , uno ordenado en orden de probabilidad y el otro en orden inverso:

#include <chrono>
#include <iostream>
#include <random>
#include <algorithm>
#include <iterator>
#include <functional>

using namespace std;

int main()
{
    long long sortedTime = 0;
    long long reverseTime = 0;

    for (int n = 0; n != 500; ++n)
    {
        //Generate a vector of 5000 random integers from 1 to 100
        random_device rnd_device;
        mt19937 rnd_engine(rnd_device());
        uniform_int_distribution<int> rnd_dist(1, 100);
        auto gen = std::bind(rnd_dist, rnd_engine);
        vector<int> rand_vec(5000);
        generate(begin(rand_vec), end(rand_vec), gen);

        volatile int nLow, nMid, nHigh;
        chrono::time_point<chrono::high_resolution_clock> start, end;

        //Sort the conditional statements in order of increasing likelyhood
        nLow = nMid = nHigh = 0;
        start = chrono::high_resolution_clock::now();
        for (int& i : rand_vec) {
            if (i >= 95) ++nHigh;               //Least likely branch
            else if (i < 20) ++nLow;
            else if (i >= 20 && i < 95) ++nMid; //Most likely branch
        }
        end = chrono::high_resolution_clock::now();
        reverseTime += chrono::duration_cast<chrono::nanoseconds>(end-start).count();

        //Sort the conditional statements in order of decreasing likelyhood
        nLow = nMid = nHigh = 0;
        start = chrono::high_resolution_clock::now();
        for (int& i : rand_vec) {
            if (i >= 20 && i < 95) ++nMid;  //Most likely branch
            else if (i < 20) ++nLow;
            else if (i >= 95) ++nHigh;      //Least likely branch
        }
        end = chrono::high_resolution_clock::now();
        sortedTime += chrono::duration_cast<chrono::nanoseconds>(end-start).count();

    }

    cout << "Percentage difference: " << 100 * (double(reverseTime) - double(sortedTime)) / double(sortedTime) << endl << endl;
}

Usando MSVC2017 con / O2, los resultados muestran que la versión ordenada es consistentemente un 28% más rápida que la versión no ordenada. Según el comentario de luk32, también cambié el orden de las dos pruebas, lo que hace una diferencia notable (22% frente a 28%). El código se ejecutó bajo Windows 7 en un Intel Xeon E5-2697 v2. Esto es, por supuesto, muy específico del problema y no debe interpretarse como una respuesta concluyente.

No, no debería, a menos que esté realmente seguro de que el sistema de destino se ve afectado. Por defecto ir por legibilidad.

Dudo mucho sus resultados. He modificado un poco su ejemplo, por lo que invertir la ejecución es más fácil. Ideone muestra consistentemente que el orden inverso es más rápido, aunque no mucho. En ciertas carreras, incluso esto ocasionalmente se volteó. Yo diría que los resultados no son concluyentes. Coliru tampoco informa una diferencia real. Puedo verificar la CPU Exynos5422 en mi odroid xu4 más adelante.

La cuestión es que las CPU modernas tienen predictores de rama. Hay mucha, mucha lógica dedicada a buscar datos e instrucciones, y las CPU modernas x86 son bastante inteligentes, cuando se trata de esto. Algunas arquitecturas más delgadas como ARM o GPU pueden ser vulnerables a esto. Pero depende mucho del compilador y del sistema de destino.

Yo diría que la optimización de pedidos de sucursales es bastante frágil y efímera. Hazlo solo como un paso de ajuste realmente fino.

Código:

#include <chrono>
#include <iostream>
#include <random>
#include <algorithm>
#include <iterator>
#include <functional>

using namespace std;

int main()
{
    //Generate a vector of random integers from 1 to 100
    random_device rnd_device;
    mt19937 rnd_engine(rnd_device());
    uniform_int_distribution<int> rnd_dist(1, 100);
    auto gen = std::bind(rnd_dist, rnd_engine);
    vector<int> rand_vec(5000);
    generate(begin(rand_vec), end(rand_vec), gen);
    volatile int nLow, nMid, nHigh;

    //Count the number of values in each of three different ranges
    //Run the test a few times
    for (int n = 0; n != 10; ++n) {

        //Run the test again, but now sort the conditional statements in reverse-order of likelyhood
        {
          nLow = nMid = nHigh = 0;
          auto start = chrono::high_resolution_clock::now();
          for (int& i : rand_vec) {
              if (i >= 95) ++nHigh;               //Least likely branch
              else if (i < 20) ++nLow;
              else if (i >= 20 && i < 95) ++nMid; //Most likely branch
          }
          auto end = chrono::high_resolution_clock::now();
          cout << "Reverse-sorted: \t" << chrono::duration_cast<chrono::nanoseconds>(end-start).count() << "ns" << endl;
        }

        {
          //Sort the conditional statements in order of likelyhood
          nLow = nMid = nHigh = 0;
          auto start = chrono::high_resolution_clock::now();
          for (int& i : rand_vec) {
              if (i >= 20 && i < 95) ++nMid;  //Most likely branch
              else if (i < 20) ++nLow;
              else if (i >= 95) ++nHigh;      //Least likely branch
          }
          auto end = chrono::high_resolution_clock::now();
          cout << "Sorted:\t\t\t" << chrono::duration_cast<chrono::nanoseconds>(end-start).count() << "ns" << endl;
        }
        cout << endl;
    }
}

Solo mis 5 centavos. Parece el efecto de ordenar si las declaraciones deberían depender de:

1. Probabilidad de cada enunciado if.

2. Número de iteraciones, por lo que el predictor de rama podría entrar en acción.

3. Sugerencias de compilación probables / improbables, es decir, diseño de código.

Para explorar esos factores, comparé las siguientes funciones:

shown_ifs ()

for (i = 0; i < data_sz * 1024; i++) {
    if (data[i] < check_point) // highly likely
        s += 3;
    else if (data[i] > check_point) // samewhat likely
        s += 2;
    else if (data[i] == check_point) // very unlikely
        s += 1;
}

reversed_ifs ()

for (i = 0; i < data_sz * 1024; i++) {
    if (data[i] == check_point) // very unlikely
        s += 1;
    else if (data[i] > check_point) // samewhat likely
        s += 2;
    else if (data[i] < check_point) // highly likely
        s += 3;
}

shown_ifs_with_hints ()

for (i = 0; i < data_sz * 1024; i++) {
    if (likely(data[i] < check_point)) // highly likely
        s += 3;
    else if (data[i] > check_point) // samewhat likely
        s += 2;
    else if (unlikely(data[i] == check_point)) // very unlikely
        s += 1;
}

reversed_ifs_with_hints ()

for (i = 0; i < data_sz * 1024; i++) {
    if (unlikely(data[i] == check_point)) // very unlikely
        s += 1;
    else if (data[i] > check_point) // samewhat likely
        s += 2;
    else if (likely(data[i] < check_point)) // highly likely
        s += 3;
}

datos

La matriz de datos contiene números aleatorios entre 0 y 100:

const int RANGE_MAX = 100;
uint8_t data[DATA_MAX * 1024];

static void data_init(int data_sz)
{
    int i;
        srand(0);
    for (i = 0; i < data_sz * 1024; i++)
        data[i] = rand() % RANGE_MAX;
}

Los resultados

Los siguientes resultados son para Intel i5 @ 3,2 GHz y G ++ 6.3.0. El primer argumento es check_point (es decir, probabilidad en %% para la declaración if altamente probable), el segundo argumento es data_sz (es decir, número de iteraciones).

---------------------------------------------------------------------
Benchmark                              Time           CPU Iterations
---------------------------------------------------------------------
ordered_ifs/50/4                    4660 ns       4658 ns     150948
ordered_ifs/50/8                   25636 ns      25635 ns      27852
ordered_ifs/75/4                    4326 ns       4325 ns     162613
ordered_ifs/75/8                   18242 ns      18242 ns      37931
ordered_ifs/100/4                   1673 ns       1673 ns     417073
ordered_ifs/100/8                   3381 ns       3381 ns     207612
reversed_ifs/50/4                   5342 ns       5341 ns     126800
reversed_ifs/50/8                  26050 ns      26050 ns      26894
reversed_ifs/75/4                   3616 ns       3616 ns     193130
reversed_ifs/75/8                  15697 ns      15696 ns      44618
reversed_ifs/100/4                  3738 ns       3738 ns     188087
reversed_ifs/100/8                  7476 ns       7476 ns      93752
ordered_ifs_with_hints/50/4         5551 ns       5551 ns     125160
ordered_ifs_with_hints/50/8        23191 ns      23190 ns      30028
ordered_ifs_with_hints/75/4         3165 ns       3165 ns     218492
ordered_ifs_with_hints/75/8        13785 ns      13785 ns      50574
ordered_ifs_with_hints/100/4        1575 ns       1575 ns     437687
ordered_ifs_with_hints/100/8        3130 ns       3130 ns     221205
reversed_ifs_with_hints/50/4        6573 ns       6572 ns     105629
reversed_ifs_with_hints/50/8       27351 ns      27351 ns      25568
reversed_ifs_with_hints/75/4        3537 ns       3537 ns     197470
reversed_ifs_with_hints/75/8       16130 ns      16130 ns      43279
reversed_ifs_with_hints/100/4       3737 ns       3737 ns     187583
reversed_ifs_with_hints/100/8       7446 ns       7446 ns      93782

Análisis

1. El pedido sí importa

Para iteraciones 4K y (casi) 100% de probabilidad de afirmaciones muy apreciadas, la diferencia es enorme 223%:

---------------------------------------------------------------------
Benchmark                              Time           CPU Iterations
---------------------------------------------------------------------
ordered_ifs/100/4                   1673 ns       1673 ns     417073
reversed_ifs/100/4                  3738 ns       3738 ns     188087

Para las iteraciones 4K y el 50% de probabilidad de afirmaciones muy apreciadas, la diferencia es de aproximadamente el 14%:

---------------------------------------------------------------------
Benchmark                              Time           CPU Iterations
---------------------------------------------------------------------
ordered_ifs/50/4                    4660 ns       4658 ns     150948
reversed_ifs/50/4                   5342 ns       5341 ns     126800

2. El número de iteraciones importa

La diferencia entre las iteraciones 4K y 8K para (casi) el 100% de probabilidad de afirmaciones muy apreciadas es aproximadamente dos veces (como se esperaba):

---------------------------------------------------------------------
Benchmark                              Time           CPU Iterations
---------------------------------------------------------------------
ordered_ifs/100/4                   1673 ns       1673 ns     417073
ordered_ifs/100/8                   3381 ns       3381 ns     207612

Pero la diferencia entre las iteraciones 4K y 8K para una probabilidad del 50% de afirmaciones muy apreciadas es 5,5 veces:

---------------------------------------------------------------------
Benchmark                              Time           CPU Iterations
---------------------------------------------------------------------
ordered_ifs/50/4                    4660 ns       4658 ns     150948
ordered_ifs/50/8                   25636 ns      25635 ns      27852

¿Por qué es así? Debido a la falta de predictores de rama. Aquí está la rama se pierde para cada caso mencionado anteriormente:

ordered_ifs/100/4    0.01% of branch-misses
ordered_ifs/100/8    0.01% of branch-misses
ordered_ifs/50/4     3.18% of branch-misses
ordered_ifs/50/8     15.22% of branch-misses

Entonces, en mi i5, el predictor de bifurcación falla espectacularmente para bifurcaciones poco probables y grandes conjuntos de datos.

3. Consejos ayudan un poco

Para las iteraciones 4K, los resultados son algo peores para una probabilidad del 50% y algo mejores para una probabilidad cercana al 100%:

---------------------------------------------------------------------
Benchmark                              Time           CPU Iterations
---------------------------------------------------------------------
ordered_ifs/50/4                    4660 ns       4658 ns     150948
ordered_ifs/100/4                   1673 ns       1673 ns     417073
ordered_ifs_with_hints/50/4         5551 ns       5551 ns     125160
ordered_ifs_with_hints/100/4        1575 ns       1575 ns     437687

Pero para las iteraciones de 8K, los resultados siempre son un poco mejores:

---------------------------------------------------------------------
Benchmark                              Time           CPU Iterations
---------------------------------------------------------------------
ordered_ifs/50/8                   25636 ns      25635 ns      27852
ordered_ifs/100/8                   3381 ns       3381 ns     207612
ordered_ifs_with_hints/50/8        23191 ns      23190 ns      30028
ordered_ifs_with_hints/100/8        3130 ns       3130 ns     221205

Por lo tanto, las sugerencias también ayudan, pero solo un poquito.

La conclusión general es: siempre compara el código, porque los resultados pueden sorprender.

Espero que ayude.

Basado en algunas de las otras respuestas aquí, parece que la única respuesta real es: depende . Depende al menos de lo siguiente (aunque no necesariamente en este orden de importancia):

• Probabilidad relativa de cada rama. Esta es la pregunta original que se hizo. En base a las respuestas existentes, parece haber algunas condiciones bajo las cuales el pedido por probabilidad ayuda, pero parece que no siempre es así. Si las probabilidades relativas no son muy diferentes, entonces es poco probable que haga alguna diferencia en el orden en que se encuentran. Sin embargo, si la primera condición ocurre el 99.999% del tiempo y la siguiente es una fracción de lo que queda, entonces lo haría supongamos que poner el más probable primero sería beneficioso en términos de tiempo.
• Costo de calcular la condición verdadera / falsa para cada rama. Si el costo de tiempo de probar las condiciones es realmente alto para una rama versus otra, entonces es probable que esto tenga un impacto significativo en el tiempo y la eficiencia. Por ejemplo, considere una condición que toma 1 unidad de tiempo para calcular (por ejemplo, verificar el estado de una variable booleana) versus otra condición que toma decenas, cientos, miles o incluso millones de unidades de tiempo para calcular (por ejemplo, verificar el contenido de un archivo en el disco o realizar una consulta SQL compleja en una base de datos grande). Suponiendo que el código verifique las condiciones en orden cada vez, las condiciones más rápidas probablemente deberían ser las primeras (a menos que dependan de que otras condiciones fallen primero).
• Compilador / Intérprete Algunos compiladores (o intérpretes) pueden incluir optimizaciones de un tipo de otro que pueden afectar el rendimiento (y algunos de estos solo están presentes si se seleccionan ciertas opciones durante la compilación y / o ejecución). Entonces, a menos que esté comparando dos compilaciones y ejecuciones de código idéntico en el mismo sistema usando el mismo compilador exacto donde la única diferencia es el orden de las ramas en cuestión, tendrá que dar margen para las variaciones del compilador.
• Sistema operativo / hardware Como mencionan luk32 y Yakk, varias CPU tienen sus propias optimizaciones (al igual que los sistemas operativos). Entonces, los puntos de referencia son nuevamente susceptibles de variación aquí.
• Frecuencia de ejecución del bloque de código Si rara vez se accede al bloque que incluye las ramas (por ejemplo, solo una vez durante el inicio), entonces es muy poco importante el orden en que se colocan las ramas. Por otro lado, si su código está golpeando este bloque de código durante una parte crítica de su código, entonces el pedido puede ser muy importante (dependiendo de los puntos de referencia).

La única forma de saberlo con certeza es comparar su caso específico, preferiblemente en un sistema idéntico (o muy similar) al sistema previsto en el que finalmente se ejecutará el código. Si está destinado a ejecutarse en un conjunto de sistemas variables con hardware, sistema operativo, etc. diferente, entonces es una buena idea comparar con múltiples variaciones para ver cuál es el mejor. Incluso puede ser una buena idea que el código se compile con un pedido en un tipo de sistema y otro pedido en otro tipo de sistema.

Mi regla general personal (para la mayoría de los casos, en ausencia de un punto de referencia) es ordenar según:

1. Condiciones que dependen del resultado de condiciones anteriores,
2. Costo de calcular la condición, entonces
3. Probabilidad relativa de cada rama.

La forma en que generalmente veo esto resuelto para el código de alto rendimiento es mantener el orden más legible, pero proporcionar pistas al compilador. Aquí hay un ejemplo del kernel de Linux :

if (likely(access_ok(VERIFY_READ, from, n))) {
    kasan_check_write(to, n);
    res = raw_copy_from_user(to, from, n);
}
if (unlikely(res))
    memset(to + (n - res), 0, res);

Aquí se supone que pasará la verificación de acceso y que no se devolverá ningún error res. Intentar reordenar cualquiera de estas cláusulas si solo confundiría el código, pero las macros likely()y unlikely()realmente ayudan a la legibilidad al señalar cuál es el caso normal y cuál es la excepción.

La implementación de Linux de esas macros utiliza características específicas de GCC . Parece que clang y el compilador Intel C admiten la misma sintaxis, pero MSVC no tiene esa característica .

También depende de su compilador y la plataforma para la que está compilando.

En teoría, la condición más probable debería hacer que el control salte lo menos posible.

Por lo general, la condición más probable debe ser primero:

if (most_likely) {
     // most likely instructions
} else …

Los asm más populares se basan en ramas condicionales que saltan cuando la condición es verdadera . Ese código C probablemente se traducirá a tal pseudoasm:

jump to ELSE if not(most_likely)
// most likely instructions
jump to end
ELSE:
…

Esto se debe a que los saltos hacen que la CPU cancele la canalización de ejecución y se bloquee porque el contador del programa cambió (para arquitecturas que admiten tuberías que son realmente comunes). Luego se trata del compilador, que puede o no aplicar algunas optimizaciones sofisticadas sobre tener la condición estadísticamente más probable para que el control haga menos saltos.

Decidí volver a ejecutar la prueba en mi propia máquina usando el código Lik32. Tuve que cambiarlo debido a que mi compilador o Windows pensaba que la alta resolución es de 1 ms, usando

mingw32-g ++. exe -O3 -Wall -std = c ++ 11 -fexceptions -g

vector<int> rand_vec(10000000);

GCC ha realizado la misma transformación en ambos códigos originales.

Tenga en cuenta que solo las dos primeras condiciones se prueban, ya que la tercera siempre debe ser cierta, GCC es una especie de Sherlock aquí.

Contrarrestar

.L233:
        mov     DWORD PTR [rsp+104], 0
        mov     DWORD PTR [rsp+100], 0
        mov     DWORD PTR [rsp+96], 0
        call    std::chrono::_V2::system_clock::now()
        mov     rbp, rax
        mov     rax, QWORD PTR [rsp+8]
        jmp     .L219
.L293:
        mov     edx, DWORD PTR [rsp+104]
        add     edx, 1
        mov     DWORD PTR [rsp+104], edx
.L217:
        add     rax, 4
        cmp     r14, rax
        je      .L292
.L219:
        mov     edx, DWORD PTR [rax]
        cmp     edx, 94
        jg      .L293 // >= 95
        cmp     edx, 19
        jg      .L218 // >= 20
        mov     edx, DWORD PTR [rsp+96]
        add     rax, 4
        add     edx, 1 // < 20 Sherlock
        mov     DWORD PTR [rsp+96], edx
        cmp     r14, rax
        jne     .L219
.L292:
        call    std::chrono::_V2::system_clock::now()

.L218: // further down
        mov     edx, DWORD PTR [rsp+100]
        add     edx, 1
        mov     DWORD PTR [rsp+100], edx
        jmp     .L217

And sorted

        mov     DWORD PTR [rsp+104], 0
        mov     DWORD PTR [rsp+100], 0
        mov     DWORD PTR [rsp+96], 0
        call    std::chrono::_V2::system_clock::now()
        mov     rbp, rax
        mov     rax, QWORD PTR [rsp+8]
        jmp     .L226
.L296:
        mov     edx, DWORD PTR [rsp+100]
        add     edx, 1
        mov     DWORD PTR [rsp+100], edx
.L224:
        add     rax, 4
        cmp     r14, rax
        je      .L295
.L226:
        mov     edx, DWORD PTR [rax]
        lea     ecx, [rdx-20]
        cmp     ecx, 74
        jbe     .L296
        cmp     edx, 19
        jle     .L297
        mov     edx, DWORD PTR [rsp+104]
        add     rax, 4
        add     edx, 1
        mov     DWORD PTR [rsp+104], edx
        cmp     r14, rax
        jne     .L226
.L295:
        call    std::chrono::_V2::system_clock::now()

.L297: // further down
        mov     edx, DWORD PTR [rsp+96]
        add     edx, 1
        mov     DWORD PTR [rsp+96], edx
        jmp     .L224

Entonces, esto no nos dice mucho, excepto que el último caso no necesita una predicción de rama.

Ahora probé las 6 combinaciones de los if, los 2 primeros son el inverso original y ordenados. alto es> = 95, bajo es <20, medio es 20-94 con 10000000 iteraciones cada uno.

high, low, mid: 43000000ns
mid, low, high: 46000000ns
high, mid, low: 45000000ns
low, mid, high: 44000000ns
mid, high, low: 46000000ns
low, high, mid: 44000000ns

high, low, mid: 44000000ns
mid, low, high: 47000000ns
high, mid, low: 44000000ns
low, mid, high: 45000000ns
mid, high, low: 46000000ns
low, high, mid: 45000000ns

high, low, mid: 43000000ns
mid, low, high: 47000000ns
high, mid, low: 44000000ns
low, mid, high: 45000000ns
mid, high, low: 46000000ns
low, high, mid: 44000000ns

high, low, mid: 42000000ns
mid, low, high: 46000000ns
high, mid, low: 46000000ns
low, mid, high: 45000000ns
mid, high, low: 46000000ns
low, high, mid: 43000000ns

high, low, mid: 43000000ns
mid, low, high: 47000000ns
high, mid, low: 44000000ns
low, mid, high: 44000000ns
mid, high, low: 46000000ns
low, high, mid: 44000000ns

high, low, mid: 43000000ns
mid, low, high: 48000000ns
high, mid, low: 44000000ns
low, mid, high: 44000000ns
mid, high, low: 45000000ns
low, high, mid: 45000000ns

high, low, mid: 43000000ns
mid, low, high: 47000000ns
high, mid, low: 45000000ns
low, mid, high: 45000000ns
mid, high, low: 46000000ns
low, high, mid: 44000000ns

high, low, mid: 43000000ns
mid, low, high: 47000000ns
high, mid, low: 45000000ns
low, mid, high: 45000000ns
mid, high, low: 46000000ns
low, high, mid: 44000000ns

high, low, mid: 43000000ns
mid, low, high: 46000000ns
high, mid, low: 45000000ns
low, mid, high: 45000000ns
mid, high, low: 45000000ns
low, high, mid: 44000000ns

high, low, mid: 42000000ns
mid, low, high: 46000000ns
high, mid, low: 44000000ns
low, mid, high: 45000000ns
mid, high, low: 45000000ns
low, high, mid: 44000000ns

1900020, 7498968, 601012

Process returned 0 (0x0)   execution time : 2.899 s
Press any key to continue.

Entonces, ¿por qué el orden es alto, bajo, medio y luego más rápido (marginalmente)

Porque lo más impredecible es el último y, por lo tanto, nunca se ejecuta a través de un predictor de rama.

          if (i >= 95) ++nHigh;               // most predictable with 94% taken
          else if (i < 20) ++nLow; // (94-19)/94% taken ~80% taken
          else if (i >= 20 && i < 95) ++nMid; // never taken as this is the remainder of the outfalls.

Entonces las ramas serán predichas tomadas, tomadas y el resto con

6% + (0.94 *) 20% de predicciones erróneas.

"Ordenado"

          if (i >= 20 && i < 95) ++nMid;  // 75% not taken
          else if (i < 20) ++nLow;        // 19/25 76% not taken
          else if (i >= 95) ++nHigh;      //Least likely branch

Las ramas serán predichas con no tomado, no tomado y Sherlock.

25% + (0.75 *) 24% predicciones erróneas

Dando una diferencia del 18-23% (diferencia medida de ~ 9%) pero necesitamos calcular ciclos en lugar de predecir erróneamente el%.

Supongamos una penalización de predicción errónea de 17 ciclos en mi CPU Nehalem y que cada verificación demora 1 ciclo en emitirse (4-5 instrucciones) y el ciclo también toma un ciclo. Las dependencias de datos son los contadores y las variables de bucle, pero una vez que las predicciones erróneas están fuera del camino, no debería influir en el tiempo.

Entonces, para "reversa", obtenemos los tiempos (esta debería ser la fórmula utilizada en Computer Architecture: A Quantitative Approach IIRC).

mispredict*penalty+count+loop
0.06*17+1+1+    (=3.02)
(propability)*(first check+mispredict*penalty+count+loop)
(0.19)*(1+0.20*17+1+1)+  (= 0.19*6.4=1.22)
(propability)*(first check+second check+count+loop)
(0.75)*(1+1+1+1) (=3)
= 7.24 cycles per iteration

y lo mismo para "ordenado"

0.25*17+1+1+ (=6.25)
(1-0.75)*(1+0.24*17+1+1)+ (=.25*7.08=1.77)
(1-0.75-0.19)*(1+1+1+1)  (= 0.06*4=0.24)
= 8.26

(8.26-7.24) /8.26 = 13.8% vs. ~ 9% medido (¡cerca del medido!?!).

Entonces, lo obvio del OP no es obvio.

Con estas pruebas, otras pruebas con código más complicado o más dependencias de datos serán diferentes, así que mida su caso.

Cambiar el orden de la prueba cambió los resultados, pero eso podría deberse a diferentes alineamientos del inicio del bucle, que idealmente deberían estar alineados a 16 bytes en todas las CPU Intel más nuevas, pero no en este caso.

Póngalos en el orden lógico que desee. Claro, la ramificación puede ser más lenta, pero la ramificación no debería ser la mayoría del trabajo que está haciendo su computadora.

Si está trabajando en una porción de código de rendimiento crítico, entonces ciertamente use el orden lógico, la optimización guiada por el perfil y otras técnicas, pero para el código general, creo que es más una elección estilística.

Si ya conoce la probabilidad relativa de la declaración if-else, entonces, para fines de rendimiento, sería mejor usar la forma ordenada, ya que solo verificará una condición (la verdadera).

De manera no ordenada, el compilador verificará todas las condiciones innecesariamente y llevará tiempo.