Özellikle, bir dizi if... else ififadem varsa ve bir şekilde her ifadenin değerlendireceği göreceli olasılığı önceden biliyorsanız true, yürütme süresinde olasılık sırasına göre sıralamak ne kadar fark yaratır? Örneğin, bunu tercih etmeliyim:

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

buna?:

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

Sıralanan sürümün daha hızlı olacağı açıktır, ancak okunabilirlik veya yan etkilerin varlığı için bunları en uygun şekilde sipariş etmek istemeyebiliriz. Kodu gerçekten çalışana kadar CPU'nun dal tahmini ile ne kadar iyi çalışacağını söylemek de zordur.

Böylece, bunu denerken, belirli bir vaka için kendi sorumu cevapladım, ancak diğer fikirleri / fikirleri de duymak istiyorum.

Önemli: Bu soru, ififadelerin programın davranışı üzerinde başka herhangi bir etkisi olmaksızın keyfi olarak yeniden sıralanabileceğini varsayar . Cevabımda, üç koşullu test birbirini dışlar ve hiçbir yan etki yaratmaz. Kuşkusuz, eğer istenen bir davranışı elde etmek için ifadelerin belirli bir sırada değerlendirilmesi gerekiyorsa, verimlilik konusu tartışmalıdır.

Genel bir kural olarak, tüm Intel CPU'lar ileri dalların ilk görüldüklerinde alınmadığını varsayarsa. Godbolt'un çalışmasına bakın .

Bundan sonra, şube bir şube tahmin önbelleğine girer ve gelecekteki şube tahminini bilgilendirmek için geçmiş davranış kullanılır.

Dolayısıyla, sıkı bir döngüde, yanlış ayarlamanın etkisi nispeten küçük olacaktır. Şube tahmincisi, hangi dal kümesinin büyük olasılıkla olduğunu öğrenecektir ve döngüde önemsiz olmayan bir işiniz varsa, küçük farklılıklar fazla toplanmaz.

Genel kodda, çoğu derleyici varsayılan olarak (başka bir nedenden yoksun) üretilen makine kodunu kabaca kodunuzda sipariş ettiğiniz şekilde sipariş edecektir. Böylece ifadeler başarısız olduklarında ileri dallar ise.

Bu nedenle dallarınızı, "ilk karşılaşma" dan en iyi dal tahminini elde etme olasılığını azaltarak sipariş etmelisiniz.

Bir dizi koşulda birçok kez sıkıca dolaşan ve önemsiz işler yapan bir mikrobenchmark, talimat sayısı ve benzerlerinin küçük etkileri ve göreceli dal tahmini sorunları yolunda çok az olacak. Yani bu durumda profil yapmalısınız , başparmak kuralları güvenilir olmayacağından .

Bunun da ötesinde, vektörleşme ve diğer birçok optimizasyon küçük sıkı döngüler için geçerlidir.

Bu nedenle, genel kodda, büyük olasılıkla kodu ifbloğun içine koyun ve bu, en az önbelleğe alınmamış dal tahmininin kaçırılmasına neden olur. Sıkı döngülerde, başlamak için genel kuralı izleyin ve daha fazlasını bilmeniz gerekiyorsa, profil yapmaktan başka seçeneğiniz yoktur.

Doğal olarak, bazı testler diğerlerinden çok daha ucuzsa, bunların hepsi pencereden dışarı çıkar.

Biri olasılık sırasına göre sıralanmış, diğeri ters sırada sıralanmış iki farklı if... else ifbloğun yürütülmesini zamanlamak için aşağıdaki testi yaptım :

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

Sonuçlar / O2 ile MSVC2017 kullanıldığında, sıralanan sürümün sıralanmamış sürümden sürekli olarak yaklaşık% 28 daha hızlı olduğunu gösterir. Luk32'nin yorumuna göre, iki testin sırasını da değiştirdim, bu da fark edilir bir fark yaratıyor (% 22'ye karşı% 28). Kod, Intel Xeon E5-2697 v2'de Windows 7 altında çalıştırıldı. Bu elbette çok probleme özgüdür ve kesin bir cevap olarak yorumlanmamalıdır.

Hedef sistemin etkilendiğinden gerçekten emin olmadığınız sürece hayır yapmamalısınız. Varsayılan olarak okunabilirlik özelliğini kullanın.

Sonuçlarınızdan şüpheliyim. Örneğinizi biraz değiştirdim, bu yüzden tersine çevirme işlemi daha kolay. Ideone oldukça tutarlı bir şekilde ters sıralamanın daha hızlı olduğunu, ancak çok fazla olmadığını gösteriyor. Bazı koşularda bu bile zaman zaman ters çevrildi. Sonuçların sonuçsuz olduğunu söyleyebilirim. coliru gerçek bir fark olmadığını bildirdi. Daha sonra odroid xu4'ümde Exynos5422 CPU'yu kontrol edebilirim.

Mesele şu ki, modern CPU'ların dal tahmincileri var. Hem verileri hem de talimatları önceden getirmeye adanmış çok fazla mantık var ve bu konuda modern x86 CPU'lar oldukça akıllı. ARM'ler veya GPU'lar gibi bazı ince mimariler buna karşı savunmasız olabilir. Ancak hem derleyici hem de hedef sisteme oldukça bağımlıdır.

Şube sipariş optimizasyonunun oldukça kırılgan ve geçici olduğunu söyleyebilirim. Sadece gerçekten ince ayar adımı olarak yapın.

Kod:

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

Sadece 5 sentim. İfadelerin aşağıdakilere bağlı olması gerekirse sipariş vermenin etkisi görünüyor:

1. Her if ifadesinin olasılığı.

2. Yineleme sayısı, böylece şube tahmincisi devreye girebilir.

3. Olası / olası olmayan derleyici ipuçları, yani kod düzeni.

Bu faktörleri araştırmak için aşağıdaki işlevleri karşılaştırdım:

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

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

veri

Veri dizisi 0 ile 100 arasında rastgele sayılar içerir:

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

Sonuçlar

Aşağıdaki sonuçlar Intel i5 @ 3,2 GHz ve G ++ 6.3.0 içindir. İlk argüman check_point'tir (yani büyük olasılıkla if ifadesi için %% olasılığı), ikinci argüman data_sz'dir (yani yineleme sayısı).

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

analiz

1. Sipariş Önemlidir

4K yinelemeleri ve (neredeyse)% 100 yüksek beğeni oranı olasılığı için, fark çok büyük% 223:

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

4K yinelemeleri ve% 50 oranında çok sevilen ifade olasılığı için fark yaklaşık% 14'tür:

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

2. Yineleme Sayısı Önemli

4K ve 8K yinelemeleri arasındaki (neredeyse)% 100 yüksek oranda beğeni olasılığı olasılığı arasındaki fark yaklaşık iki kattır (beklendiği gibi):

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

Ancak,% 50 oranında çok beğenilen ifadenin olasılığı için 4K ve 8K yinelemeleri arasındaki fark 5,5 kattır:

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

Neden böyle? Şube tahmincisi özlüyor çünkü. Yukarıda belirtilen her vaka için şube özlüyor:

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

Bu yüzden i5'imde dal tahmincisi, çok olası olmayan dallar ve büyük veri setleri için muhteşem bir şekilde başarısız oluyor.

3. İpuçları Biraz Yardım

4K yinelemelerinde sonuçlar% 50 olasılık için biraz daha kötü ve% 100'e yakın olasılık için biraz daha iyidir:

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

Ancak 8K yinelemeleri için sonuçlar her zaman biraz daha iyidir:

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

Yani, ipuçları da yardımcı oluyor, ama sadece biraz.

Genel sonuç şudur: Her zaman kodu kıyaslayın, çünkü sonuçlar şaşırtıcı olabilir.

Umarım yardımcı olur.

Buradaki diğer cevaplardan bazılarına dayanarak, tek gerçek cevap şudur: duruma bağlıdır . En azından aşağıdakilere bağlıdır (bu önem sırasına göre olmasa da):

• Her dalın nispi olasılığı. Bu sorulan orijinal soru. Mevcut cevaplara dayanarak, olasılıkla sıralamanın yardımcı olduğu bazı durumlar var gibi görünüyor, ancak her zaman böyle değil. Göreceli olasılıklar çok farklı değilse, hangi sırayla oldukları konusunda herhangi bir fark yaratma olasılığı düşüktür. Ancak, ilk koşul zamanın% 99,999'u olur ve bir sonraki durum kalanın bir kısmı ise, o zaman ben en muhtemel olanı ilk sıralamanın zamanlama açısından yararlı olacağını varsayalım.
• Her dal için doğru / yanlış koşulu hesaplama maliyeti. Koşulları test etmenin zaman maliyeti bir dal için diğerine karşı gerçekten yüksekse, bunun zamanlama ve verimlilik üzerinde önemli bir etkisi olması muhtemeldir. Örneğin, hesaplanması için 1 zaman birimi alan (örneğin, bir Boole değişkeninin durumunu kontrol etme) on bir, yüzlerce, binlerce ve hatta milyonlarca zaman birimini hesaplayan başka bir koşula (örneğin, diskteki bir dosya veya büyük bir veritabanına karşı karmaşık bir SQL sorgusu gerçekleştirme). Kodun koşulları her seferinde sırayla kontrol ettiği varsayılarak, daha hızlı koşullar ilk önce olmalıdır (önce başarısız olan diğer koşullara bağlı olmadıkça).
• Derleyici / Tercüman Bazı derleyiciler (veya tercümanlar) performansı etkileyebilecek bir tür diğerinin optimizasyonunu içerebilir (ve bunların bazıları yalnızca derleme ve / veya yürütme sırasında belirli seçenekler seçiliyse mevcuttur). Dolayısıyla, tek farkın söz konusu dalların sırası olduğu tam olarak aynı derleyiciyi kullanarak aynı sistemde aynı kodun iki derlemesini ve yürütülmesini kıyaslamadığınız sürece, derleyici varyasyonları için biraz boşluk vermeniz gerekecektir.
• İşletim Sistemi / Donanım luk32 ve Yakk tarafından belirtildiği gibi, çeşitli CPU'ların kendi optimizasyonları vardır (işletim sistemlerinde olduğu gibi). Bu yüzden kıyaslama kriterleri yine buradaki varyasyona açıktır.
• Kod bloğu yürütme sıklığı Şubeleri içeren bloğa nadiren erişilirse (örneğin, başlatma sırasında yalnızca bir kez), şubeleri hangi sıraya koyduğunuz büyük olasılıkla çok az önemlidir. Öte yandan, kodunuzun kritik bir kısmı sırasında kodunuz bu kod bloğuna çarpıyorsa, sipariş vermek çok önemli olabilir (kıyaslama ölçütlerine bağlı olarak).

Kesin olarak bilmenin tek yolu, özel durumunuzu, tercihen kodun nihayet çalışacağı amaçlanan sistemle özdeş (veya çok benzer) bir sistemde karşılaştırmaktır. Farklı donanım, işletim sistemi vb. İle değişen bir dizi sistemde çalışması amaçlanıyorsa, hangisinin en iyi olduğunu görmek için birden fazla varyasyon arasında karşılaştırma yapmak iyi bir fikirdir. Kodun bir tür sistemde bir siparişle ve başka bir sistemde başka bir siparişle derlenmesi iyi bir fikir olabilir.

Kişisel kuralım (çoğu durumda, bir kıyaslama yokluğunda) aşağıdakilere dayanarak sipariş vermektir:

1. Önceki koşulların sonucuna dayanan koşullar,
2. Durumu hesaplama maliyeti, o zaman
3. Her dalın nispi olasılığı.

Bunu genellikle yüksek performanslı kod için çözdüğüm şekilde, en okunaklı olan sıralamayı korumak, ancak derleyiciye ipuçları sağlamaktır. İşte Linux çekirdeğinden bir örnek :

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

Burada varsayım, erişim kontrolünün geçeceği ve hiçbir hatanın döndürülmediği varsayımıdır res. Yan tümceler kodu karıştırırsa, bunlardan birini yeniden sıralamaya çalışmak, ancak likely()veunlikely() makroları aslında normal durumun ve istisnanın ne olduğunu göstererek okunabilirliğe yardımcı olur.

Bu makroların Linux uygulaması GCC'ye özgü özellikler kullanır . Görünüşe göre clang ve Intel C derleyicisi aynı sözdizimini destekliyor, ancak MSVC'nin böyle bir özelliği yok .

Ayrıca derleyicinize ve derlediğiniz platforma da bağlıdır.

Teorik olarak, en olası durum, kontrolün mümkün olduğunca az sıçramasını sağlamalıdır.

Genellikle en olası koşul ilk olmalıdır:

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

En popüler asmlar koşul doğru olduğunda atlayan koşullu dallara dayanır . Bu C kodu muhtemelen bu tür sahte asma tercüme edilecektir:

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

Bunun nedeni, atlamaların cpu'yu yürütme ardışık düzenini ve duraklamasını iptal ettirmesidir, çünkü program sayacı değişmiştir (gerçekten yaygın olan boru hatlarını destekleyen mimariler için). Daha sonra, derleyici hakkındadır; bu, kontrolün daha az sıçrama yapmasını sağlamak için istatistiksel olarak en olası koşula sahip olma konusunda bazı gelişmiş optimizasyonlar uygulayabilir veya uygulamıyor olabilir.

Testi Lik32 kodunu kullanarak kendi makinemde tekrar çalıştırmaya karar verdim. Windows veya derleyicimin yüksek çözünürlük 1 ms olduğunu düşünerek değiştirmek zorunda kaldım,

mingw32-g ++. exe -O3 -Duvar -std = c ++ 11 -özellikler -g

vector<int> rand_vec(10000000);

GCC, her iki orijinal kodda da aynı dönüşümü gerçekleştirdi.

Üçüncünün her zaman doğru olması gerektiği için sadece ilk iki koşulun test edildiğine dikkat edin, GCC burada bir Sherlock türüdür.

Tersine çevirmek

.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

Yani bu bize çok fazla şey anlatmıyor, ancak son durum bir şube tahmininin gerekmediği.

Şimdi if'lerin 6 kombinasyonunun hepsini denedim, ilk 2 orijinal ters ve sıralanmıştır. yüksek> = 95, düşük <20, orta 20-94 ve her biri 10000000 yineleme.

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.

Peki neden sipariş yüksek, düşük, med sonra daha hızlı (marjinal)

Çünkü en tahmin edilemez sondur ve bu nedenle hiçbir zaman bir dal öngörücüsünden geçmez.

          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.

Böylece şubelerin alınacağı, alınacağı ve

% 6 + (0,94 *)% 20 yanlış tahmin.

"Sıralama"

          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

Dallar alınmaz, alınmaz ve Sherlock ile tahmin edilir.

% 25 + (0,75 *)% 24 yanlış tahminler

% 18-23 fark veriyor (~% 9 ölçülen fark), ancak% tahmin etmek yerine döngüleri hesaplamamız gerekiyor.

Nehalem CPU'mdaki 17 döngünün cezayı yanlış tahmin ettiğini ve her kontrolün 1 döngünün (4-5 talimat) ve döngü de bir döngünün alındığını varsayalım. Veri bağımlılıkları sayaçlar ve döngü değişkenleridir, ancak yanlış tahminler yoldan çıktığında zamanlamayı etkilememelidir.

Yani "geri" için zamanlamaları alıyoruz (bu Bilgisayar Mimarisinde kullanılan formül olmalı: Sayısal Bir Yaklaşım 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

ve "sıralama" için de aynı

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 = ölçülen ~% 9'a karşılık% 13.8 (ölçülene yakın!?!).

Yani OP'nin barizliği belli değil.

Bu testlerle, daha karmaşık kodlu veya daha fazla veri bağımlılığına sahip diğer testler kesinlikle farklı olacaktır, bu nedenle durumunuzu ölçün.

Testin sırasını değiştirmek sonuçları değiştirdi, ancak bunun nedeni döngü başlangıcının farklı yeni hizalamalar nedeniyle olabilir; bu, ideal olarak tüm yeni Intel CPU'larda 16 bayt hizalanmalıdır, ancak bu durumda değildir.

Onları istediğiniz mantıksal sıraya koyun. Tabii, şube daha yavaş olabilir, ancak dallanma bilgisayarınızın yaptığı işin çoğunluğu olmamalıdır.

Kodun performans açısından kritik bir kısmı üzerinde çalışıyorsanız, o zaman kesinlikle mantıksal düzen, profil güdümlü optimizasyon ve diğer teknikleri kullanın, ancak genel kod için, bunun gerçekten daha stilistik bir seçim olduğunu düşünüyorum.

İf-else ifadesinin göreceli olasılığını zaten biliyorsanız, performans amacıyla, yalnızca bir koşulu (doğru olanı) kontrol edeceği için sıralı yolu kullanmak daha iyi olacaktır.

Derleyici sıralanmamış bir şekilde tüm koşulları gereksiz yere kontrol eder ve zaman alır.