Especificamente, se eu tenho uma série de if... else ifinstruções, e de alguma forma sei de antemão a probabilidade relativa que cada instrução avaliará true, quanta diferença no tempo de execução faz para classificá-las em ordem de probabilidade? Por exemplo, devo preferir isso:

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

para isso?:

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

Parece óbvio que a versão classificada seria mais rápida; no entanto, para facilitar a leitura ou a existência de efeitos colaterais, podemos solicitá-los de maneira não ideal. Também é difícil dizer o desempenho da CPU com a previsão de ramificação até que você realmente execute o código.

Portanto, durante o experimento, acabei respondendo à minha própria pergunta para um caso específico, mas gostaria de ouvir outras opiniões / insights também.

Importante: esta pergunta pressupõe que as ifdeclarações possam ser reordenadas arbitrariamente sem causar nenhum outro efeito no comportamento do programa. Na minha resposta, os três testes condicionais são mutuamente exclusivos e não produzem efeitos colaterais. Certamente, se as declarações devem ser avaliadas em uma determinada ordem para alcançar o comportamento desejado, a questão da eficiência é discutível.

Como regra geral, a maioria, se não todas, as CPUs Intel assumem ramificações avançadas não são obtidas na primeira vez em que as veem. Veja o trabalho de Godbolt .

Depois disso, a ramificação entra em um cache de previsão da ramificação e o comportamento passado é usado para informar a previsão futura da ramificação.

Assim, em um loop restrito, o efeito da falta de ordem será relativamente pequeno. O preditor de ramificação aprenderá qual conjunto de ramificações é mais provável e, se você tiver uma quantidade não trivial de trabalho no loop, as pequenas diferenças não serão muito importantes.

Em código geral, a maioria dos compiladores por padrão (sem outro motivo) solicitará o código de máquina produzido aproximadamente da maneira que você solicitou em seu código. Portanto, se as instruções são ramificações para a frente quando falham.

Portanto, você deve ordenar seus galhos na ordem decrescente de probabilidade para obter a melhor previsão de galho de um "primeiro encontro".

Uma marca de microssegura que faz loop muitas vezes em um conjunto de condições e faz um trabalho trivial será dominada por pequenos efeitos da contagem de instruções e similares, e pouco em termos de problemas relativos de previsão de ramificação. Portanto, nesse caso, você deve criar um perfil , pois as regras práticas não serão confiáveis.

Além disso, a vetorização e muitas outras otimizações se aplicam a pequenos loops apertados.

Portanto, no código geral, coloque o código mais provável dentro do ifbloco e isso resultará no menor número de erros de previsão de ramificação não armazenada em cache. Em loops apertados, siga a regra geral para começar e, se você precisar saber mais, terá pouca escolha a não ser criar um perfil.

Naturalmente, tudo isso sai pela janela se alguns testes forem muito mais baratos que outros.

Fiz o seguinte teste para cronometrar a execução de dois blocos if... diferentes else if, um classificado em ordem de probabilidade e outro em ordem inversa:

#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 o MSVC2017 com / O2, os resultados mostram que a versão classificada é consistentemente cerca de 28% mais rápida que a versão não classificada. Pelo comentário do luk32, também mudei a ordem dos dois testes, o que faz uma diferença notável (22% vs 28%). O código foi executado no Windows 7 em um Intel Xeon E5-2697 v2. É claro que isso é muito específico do problema e não deve ser interpretado como uma resposta conclusiva.

Não, você não deve, a menos que tenha certeza de que o sistema de destino é afetado. Por padrão, vá pela legibilidade.

Eu duvido muito dos seus resultados. Como modifiquei um pouco o seu exemplo, é mais fácil reverter a execução. A ideia mostra consistentemente que a ordem inversa é mais rápida, embora não muito. Em certas corridas, mesmo isso ocasionalmente virou. Eu diria que os resultados são inconclusivos. O coliru também não reporta nenhuma diferença real. Posso verificar a CPU Exynos5422 no meu odroid xu4 posteriormente.

O problema é que as CPUs modernas têm preditores de ramificação. Há muita lógica dedicada à busca prévia de dados e instruções, e as modernas CPUs x86 são bastante inteligentes quando se trata disso. Algumas arquiteturas mais finas, como ARMs ou GPUs, podem estar vulneráveis ​​a isso. Mas é realmente altamente dependente do compilador e do sistema de destino.

Eu diria que a otimização de pedidos de filiais é bastante frágil e efêmera. Faça isso apenas como uma etapa realmente precisa.

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;
    }
}

Apenas meus 5 centavos. Parece o efeito de ordenar se as instruções devem depender de:

1. Probabilidade de cada declaração if.

2. Número de iterações, para que o preditor de ramificação possa entrar em ação.

3. Dicas de compilador prováveis ​​/ improváveis, ou seja, layout de código.

Para explorar esses fatores, comparei as seguintes funções:

orders_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;
}

orders_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;
}

dados

A matriz de dados contém números aleatórios entre 0 e 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;
}

Os resultados

Os seguintes resultados são para Intel i5 a 3,2 GHz e G ++ 6.3.0. O primeiro argumento é o check_point (ou seja, probabilidade em %% para a declaração if altamente provável), o segundo argumento é data_sz (ou seja, número de iterações).

---------------------------------------------------------------------
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álise

1. A Ordem Importa

Para iterações 4K e (quase) 100% de probabilidade de uma declaração muito apreciada, a diferença é 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 iterações 4K e 50% de probabilidade de uma declaração muito apreciada, a diferença é de cerca de 14%:

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

2. O número de iterações é importante

A diferença entre iterações 4K e 8K para (quase) 100% de probabilidade de uma declaração muito apreciada é cerca de duas vezes (conforme o esperado):

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

Mas a diferença entre iterações 4K e 8K, para uma probabilidade de 50% de uma declaração muito apreciada, é de 5,5 vezes:

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

Por que é assim? Devido a erros do preditor de ramificação. Aqui estão as falhas do ramo para cada caso mencionado acima:

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

Portanto, no i5, o preditor de ramificações falha espetacularmente para ramificações não tão prováveis ​​e grandes conjuntos de dados.

3. Dicas ajudam um pouco

Para iterações 4K, os resultados são um pouco piores para 50% de probabilidade e um pouco melhores para quase 100% de probabilidade:

---------------------------------------------------------------------
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

Mas para iterações de 8K, os resultados são sempre um pouco melhores:

---------------------------------------------------------------------
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

Portanto, as dicas também ajudam, mas um pouquinho.

A conclusão geral é: sempre faça uma referência do código, pois os resultados podem surpreender.

Espero que ajude.

Com base em algumas das outras respostas aqui, parece que a única resposta real é: depende . Depende de pelo menos o seguinte (embora não necessariamente nessa ordem de importância):

• Probabilidade relativa de cada ramo. Esta é a pergunta original que foi feita. Com base nas respostas existentes, parece haver algumas condições sob as quais a ordenação por probabilidade ajuda, mas nem sempre parece ser esse o caso. Se as probabilidades relativas não forem muito diferentes, é improvável que faça diferença em que ordem elas estão. No entanto, se a primeira condição ocorrer 99,999% do tempo e a próxima for uma fração do que resta, então eu faria suponha que colocar o mais provável em primeiro lugar seria benéfico em termos de tempo.
• Custo do cálculo da condição verdadeira / falsa de cada filial. Se o custo do tempo para testar as condições for realmente alto para uma filial em relação a outra, é provável que isso tenha um impacto significativo no tempo e na eficiência. Por exemplo, considere uma condição que leva 1 unidade de tempo para calcular (por exemplo, verificar o estado de uma variável booleana) versus outra condição que leva dezenas, centenas, milhares ou até milhões de unidades de tempo para calcular (por exemplo, verificar o conteúdo de um arquivo em disco ou executando uma consulta SQL complexa em um banco de dados grande). Supondo que o código verifique as condições na ordem de cada vez, as condições mais rápidas provavelmente devem ser as primeiras (a menos que dependam de outras condições que falhem primeiro).
• Compilador / Intérprete Alguns compiladores (ou intérpretes) podem incluir otimizações de um tipo de outro que podem afetar o desempenho (e algumas delas estão presentes apenas se determinadas opções forem selecionadas durante a compilação e / ou execução). Portanto, a menos que você esteja comparando duas compilações e execuções de código idêntico no mesmo sistema, usando exatamente o mesmo compilador, onde a única diferença é a ordem das ramificações em questão, você terá que dar uma margem de manobra para variações do compilador.
• Sistema operacional / hardware Conforme mencionado por luk32 e Yakk, várias CPUs têm suas próprias otimizações (assim como os sistemas operacionais). Portanto, os benchmarks são novamente suscetíveis a variações aqui.
• Frequência de execução do bloco de código Se o bloco que inclui as ramificações raramente é acessado (por exemplo, apenas uma vez durante a inicialização), provavelmente é muito pouco a ordem em que você coloca as ramificações. Por outro lado, se o seu código estiver martelando neste bloco de código durante uma parte crítica do seu código, o pedido poderá ser muito importante (dependendo dos benchmarks).

A única maneira de saber com certeza é avaliar o seu caso específico, de preferência em um sistema idêntico (ou muito semelhante ao) ao sistema pretendido no qual o código finalmente será executado. Se se destina a executar em um conjunto de sistemas variados, com hardware, sistema operacional, etc. diferentes, é uma boa ideia fazer uma comparação entre várias variações para ver qual é o melhor. Pode até ser uma boa idéia compilar o código com uma ordem em um tipo de sistema e outra com outro tipo de sistema.

Minha regra pessoal (na maioria dos casos, na ausência de um benchmark) é pedir com base em:

1. Condições que dependem do resultado de condições anteriores,
2. Custo de calcular a condição, então
3. Probabilidade relativa de cada ramo.

A maneira como costumo ver isso resolvido para código de alto desempenho é manter a ordem mais legível, mas fornecer dicas para o compilador. Aqui está um exemplo do kernel do 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);

Aqui, a suposição é de que a verificação de acesso será aprovada e que nenhum erro será retornado res. Tentando reordenar qualquer uma dessas cláusulas if apenas confundiria o código, mas o likely()eunlikely() macros realmente ajudam na legibilidade, apontando qual é o caso normal e qual é a exceção.

A implementação do Linux dessas macros usa recursos específicos do GCC . Parece que o clang e o compilador Intel C suportam a mesma sintaxe, mas o MSVC não possui esse recurso .

Também depende do seu compilador e da plataforma para a qual você está compilando.

Em teoria, a condição mais provável deve fazer o controle saltar o menos possível.

Normalmente, a condição mais provável deve ser a primeira:

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

Os asm mais populares são baseados em ramificações condicionais que pulam quando a condição é verdadeira . Esse código C provavelmente será traduzido para esse pseudo asm:

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

Isso ocorre porque os saltos fazem com que a CPU cancele o pipeline de execução e pare porque o contador do programa foi alterado (para arquiteturas que suportam pipelines realmente comuns). Depois, trata-se do compilador, que pode ou não aplicar algumas otimizações sofisticadas sobre ter a condição estatisticamente mais provável de obter o controle com menos saltos.

Decidi executar novamente o teste em minha própria máquina usando o código Lik32. Eu tive que mudar isso devido ao meu windows ou compilador pensando que a alta resolução é de 1ms, usando

mingw32-g ++. exe -O3 -Wall -std = c ++ 11 -exceções -g

vector<int> rand_vec(10000000);

O GCC fez a mesma transformação nos dois códigos originais.

Observe que apenas as duas primeiras condições são testadas, pois a terceira sempre deve ser verdadeira; o GCC é uma espécie de Sherlock aqui.

Reverter

.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

Portanto, isso não nos diz muito, exceto que o último caso não precisa de uma previsão de ramificação.

Agora eu tentei todas as 6 combinações dos if's, os 2 primeiros são o reverso original e classificados. high é> = 95, low é <20, mid é 20-94 com 10000000 iterações cada.

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.

Então, por que o pedido é alto, baixo, médio e mais rápido (marginalmente)

Porque o mais imprevisível é o último e, portanto, nunca é executado através de um preditor de ramificação.

          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.

Portanto, os galhos serão preditos tomados, tomados e restantes com

6% + (0,94 *) 20% de imprevistos.

"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

Os galhos serão previstos com não capturados, não capturados e Sherlock.

25% + (0,75 *) 24% de imprevistos

Dando diferença de 18 a 23% (diferença medida de ~ 9%), mas precisamos calcular ciclos em vez de% imprevisível.

Vamos assumir uma pena de 17 ciclos de imprevisibilidade na minha CPU Nehalem e que cada verificação leva 1 ciclo para emitir (4-5 instruções) e o loop também leva um ciclo. As dependências de dados são os contadores e as variáveis ​​de loop, mas uma vez que os erros de previsão estão fora do caminho, isso não deve influenciar o tempo.

Portanto, para "reverso", obtemos os horários (essa deve ser a fórmula usada em Arquitetura de Computadores: Uma Abordagem Quantitativa 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

e o mesmo para "classificado"

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 (próximo ao medido!?!).

Portanto, o óbvio do OP não é óbvio.

Com esses testes, outros testes com código mais complicado ou mais dependências de dados certamente serão diferentes; portanto, avalie seu caso.

Alterar a ordem do teste alterou os resultados, mas isso pode ser devido a diferentes alinhamentos do início do loop, que devem idealmente ser alinhados em 16 bytes em todas as CPUs Intel mais recentes, mas não são neste caso.

Coloque-os na ordem lógica que desejar. Claro, a ramificação pode ser mais lenta, mas a ramificação não deve ser a maior parte do trabalho que seu computador está executando.

Se você estiver trabalhando em uma parte crítica do desempenho, certamente use ordem lógica, otimização guiada por perfil e outras técnicas, mas para o código geral, acho que é realmente uma escolha estilística.

Se você já conhece a probabilidade relativa da instrução if-else, então, para fins de desempenho, seria melhor usar a maneira classificada, pois ela verificará apenas uma condição (a verdadeira).

De uma maneira não classificada, o compilador verificará todas as condições desnecessariamente e levará tempo.