GCC'nin şube tahminini her zaman belirli bir yoldan gitmeye zorlaması için bir derleyici ipucu var mı?

Intel mimarileri için, GCC derleyicisine her zaman dal tahminini kodumda belirli bir şekilde zorlayan kod üretmesi talimatını vermenin bir yolu var mı? Intel donanımı bunu destekliyor mu? Diğer derleyiciler veya donanımlar ne olacak?

Bunu C ++ kodunda, hızlı koşmak istediğimi bildiğim ve yakın zamanda o şubeyi aldığında bile diğer şubenin alınması gerektiğinde yavaşlamayı umursamadığım durumlarda kullanırdım.

for (;;) {
  if (normal) { // How to tell compiler to always branch predict true value?
    doSomethingNormal();
  } else {
    exceptionalCase();
  }
}

Evdzhan Mustafa için takip eden bir soru olarak, ipucu, işlemcinin talimatla ilk karşılaşması için bir ipucu belirtebilir mi, sonraki tüm dal tahmini normal çalışıyor mu?

C ++ 20'den itibaren olası ve olası olmayan öznitelikler standartlaştırılmalıdır ve zaten g ++ 9'da desteklenmektedir . Yani burada tartışıldığı gibi yazabilirsiniz

if (a>b) {
  /* code you expect to run often */
  [[likely]] /* last statement */
}

örneğin aşağıdaki kodda başka bloğu için satır içi sayesinde alır [[unlikely]]eğer bloğunda

int oftendone( int a, int b );
int rarelydone( int a, int b );
int finaltrafo( int );

int divides( int number, int prime ) {
  int almostreturnvalue;
  if ( ( number % prime ) == 0 ) {
    auto k                         = rarelydone( number, prime );
    auto l                         = rarelydone( number, k );
    [[unlikely]] almostreturnvalue = rarelydone( k, l );
  } else {
    auto a            = oftendone( number, prime );
    almostreturnvalue = oftendone( a, a );
  }
  return finaltrafo( almostreturnvalue );
}

özniteliğin varlığını / yokluğunu karşılaştıran godbolt bağlantısı

GCC, __builtin_expect(long exp, long c)bu tür bir özelliği sağlamak için işlevi destekler . Belgeleri buradan kontrol edebilirsiniz .

expKoşul nerede kullanılır ve cbeklenen değerdir. Örneğin, istersen

if (__builtin_expect(normal, 1))

Garip sözdizimi nedeniyle bu genellikle iki özel makro tanımlanarak kullanılır.

#define likely(x)    __builtin_expect (!!(x), 1)
#define unlikely(x)  __builtin_expect (!!(x), 0)

sadece görevi kolaylaştırmak için.

Aklında bulunsun:

1. bu standart değil
2. bir derleyici / işlemci dalı tahmin edicisi, bu tür şeylere karar verme konusunda muhtemelen sizden daha yeteneklidir, bu nedenle bu, erken bir mikro optimizasyon olabilir

gcc sahip uzun __builtin_expect (uzun exp, uzun c) ( vurgu mayın ):

Derleyiciye dal tahmin bilgisi sağlamak için __builtin_expect'i kullanabilirsiniz. Genel olarak, programcılar programlarının gerçekte nasıl performans gösterdiğini tahmin etmede kötü şöhretli oldukları için bunun için gerçek profil geri bildirimini kullanmayı tercih etmelisiniz (-fprofile-yaylar) . Ancak, bu verilerin toplanmasının zor olduğu uygulamalar vardır.

Dönüş değeri, integral bir ifade olması gereken exp değeridir. Yerleşik olanın semantiği, exp == c'nin beklenmesidir. Örneğin:

if (__builtin_expect (x, 0))
   foo ();

x'in sıfır olmasını beklediğimiz için foo'yu çağırmayı beklemediğimizi gösterir. Exp için integral ifadelerle sınırlı olduğunuzdan, aşağıdaki gibi yapılar kullanmalısınız.

if (__builtin_expect (ptr != NULL, 1))
   foo (*ptr);

işaretçi veya kayan nokta değerlerini test ederken.

Belgelerin belirttiği gibi, gerçek profil geri bildirimini kullanmayı tercih etmelisiniz ve bu makale bunun pratik bir örneğini ve en azından kullanımdan ziyade en azından nasıl bir gelişme olduğunu gösteriyor __builtin_expect. Ayrıca , g ++ 'da profil kılavuzlu optimizasyonlar nasıl kullanılır? .

Ayrıca , bu özelliği kullanan () ve olası olmayan () çekirdek makroları hakkında bir Linux çekirdek yeni başlayanlar makalesi bulabiliriz :

#define likely(x)       __builtin_expect(!!(x), 1)
#define unlikely(x)     __builtin_expect(!!(x), 0)

!!Makroda kullanılana dikkat edin, bunun açıklamasını (koşul) yerine Neden !! (koşul) kullanmalıyız? .

Bu tekniğin Linux çekirdeğinde kullanılması, onu kullanmanın her zaman mantıklı olduğu anlamına gelmez. Bu sorudan yakın zamanda parametreyi derleme zamanı sabiti veya değişken olarak geçirirken fonksiyon performansı arasındaki farkı yanıtladığım , birçok elle haddelenmiş optimizasyon tekniğinin genel durumda çalışmadığını görebiliriz. Bir tekniğin etkili olup olmadığını anlamak için kodu dikkatli bir şekilde profillememiz gerekir. Çoğu eski teknik, modern derleyici optimizasyonları ile alakalı bile olmayabilir.

Not, yerleşikler taşınabilir olmasa da, __builtin_expect'i de destekler .

Ayrıca bazı mimarilerde bir fark yaratmayabilir .

Hayır yok. (En azından modern x86 işlemcilerde.)

__builtin_expectdiğer yanıtlarda bahsedilen, gcc'nin montaj kodunu düzenleme şeklini etkiler. O değil doğrudan CPU şube öngorücunun etkiler. Elbette, kodun yeniden düzenlenmesinden kaynaklanan şube tahmini üzerinde dolaylı etkiler olacaktır. Ancak modern x86 işlemcilerinde, CPU'ya "bu dalın alındığını / alınmadığını varsayın" şeklinde bir talimat yoktur.

Daha fazla ayrıntı için şu soruya bakın: Intel x86 0x2E / 0x3E Önek Dal Tahmini gerçekten kullanılıyor mu?

Açık olmak gerekirse, __builtin_expectve / veya kullanılması -fprofile-arcs olabilir , hem kod düzeni ile şube ongorücüye ipuçları vererek kodun performansını artırmak (bakınız - Hizalama ve şube tahmini X86-64 montaj Performans optimizasyon ve ayrıca önbellek davranışını iyileştirmek) "olası" olmayan kodu "olası" koddan uzak tutarak.

C ++ 11'de olası / olası olmayan makroları tanımlamanın doğru yolu şudur:

#define LIKELY(condition) __builtin_expect(static_cast<bool>(condition), 1)
#define UNLIKELY(condition) __builtin_expect(static_cast<bool>(condition), 0)

Bu yöntem, farklı olarak tüm C ++ sürümleriyle uyumludur [[likely]], ancak standart olmayan uzantıya dayanır __builtin_expect.

Bu makrolar bu şekilde tanımlandığında:

#define LIKELY(condition) __builtin_expect(!!(condition), 1)

Bu, ififadelerin anlamını değiştirebilir ve kodu bozabilir. Aşağıdaki kodu göz önünde bulundurun:

#include <iostream>

struct A
{
    explicit operator bool() const { return true; }
    operator int() const { return 0; }
};

#define LIKELY(condition) __builtin_expect((condition), 1)

int main() {
    A a;
    if(a)
        std::cout << "if(a) is true\n";
    if(LIKELY(a))
        std::cout << "if(LIKELY(a)) is true\n";
    else
        std::cout << "if(LIKELY(a)) is false\n";
}

Ve çıktısı:

if(a) is true
if(LIKELY(a)) is false

Gördüğünüz gibi, PEK kullanarak tanımı !!için bir döküm olarak boolsonlarını semantik if.

Buradaki mesele o değil operator int()ve operator bool()ilişkili olmalı. Hangisi iyi bir uygulamadır.

Bunun !!(x)yerine kullanmak static_cast<bool>(x), C ++ 11 bağlamsal dönüştürmeler için bağlamı kaybeder .

Diğer cevapların yeterince önerildiği gibi, __builtin_expectderleyiciye montaj kodunu nasıl düzenleyeceğiniz konusunda bir ipucu vermek için kullanabilirsiniz . As resmi dokümanlar işaret çoğu durumda, beyninize yerleştirilen montajcı, GCC ekibi tarafından hazırlanmış olan kadar iyi olmayacaktır. Kodunuzu optimize etmek için tahmin etmek yerine gerçek profil verilerini kullanmak her zaman en iyisidir.

Benzer satırlar boyunca, ancak henüz bahsedilmemiştir, derleyiciyi "soğuk" bir yolda kod oluşturmaya zorlamanın GCC'ye özgü bir yoludur. Bu, kulağa tam olarak yaptıkları gibi yapan noinlineve coldözelliklerinin kullanımını içerir . Bu nitelikler yalnızca işlevlere uygulanabilir, ancak C ++ 11 ile satır içi lambda işlevlerini bildirebilirsiniz ve bu iki özellik lambda işlevlerine de uygulanabilir.

Her ne kadar bu, mikro optimizasyonun genel kategorisine girse de ve bu nedenle standart tavsiye geçerlidir - test tahmin etmeyin - daha genel olarak yararlı olduğunu düşünüyorum __builtin_expect. X86 işlemcisinin neredeyse hiçbir nesli, dal tahmin ipuçlarını ( referans ) kullanmaz, bu nedenle her durumda etkileyebileceğiniz tek şey, montaj kodunun sırasıdır. Hata işlemenin veya "uç durum" kodunun ne olduğunu bildiğinizden, bu açıklamayı derleyicinin ona bir dalı asla tahmin etmemesini ve boyut için optimize ederken onu "etkin" koddan uzaklaştırmasını sağlamak için kullanabilirsiniz.

Örnek kullanım:

void FooTheBar(void* pFoo)
{
    if (pFoo == nullptr)
    {
        // Oh no! A null pointer is an error, but maybe this is a public-facing
        // function, so we have to be prepared for anything. Yet, we don't want
        // the error-handling code to fill up the instruction cache, so we will
        // force it out-of-line and onto a "cold" path.
        [&]() __attribute__((noinline,cold)) {
            HandleError(...);
        }();
    }

    // Do normal stuff
    ⋮
}

Daha da iyisi, GCC, mevcut olduğunda profil geri bildirimi lehine bunu otomatik olarak yok sayacaktır (örneğin, ile derleme yaparken -fprofile-use).

Resmi belgelere buradan bakın: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes

__builtin_expect, derleyiciye bir dalın hangi yöne gitmesini beklediğinizi söylemek için kullanılabilir. Bu, kodun nasıl üretildiğini etkileyebilir. Tipik işlemciler kodu sırayla daha hızlı çalıştırır. Yani yazarsan

if (__builtin_expect (x == 0, 0)) ++count;
if (__builtin_expect (y == 0, 0)) ++count;
if (__builtin_expect (z == 0, 0)) ++count;

derleyici aşağıdaki gibi kod üretecektir

if (x == 0) goto if1;
back1: if (y == 0) goto if2;
back2: if (z == 0) goto if3;
back3: ;
...
if1: ++count; goto back1;
if2: ++count; goto back2;
if3: ++count; goto back3;

İpucunuz doğruysa, bu, gerçekte gerçekleştirilmiş herhangi bir dallanma olmadan kodu çalıştıracaktır. Her if ifadesinin koşullu kod etrafında dallanacağı ve üç dal çalıştıracağı normal diziden daha hızlı çalışacaktır.

Daha yeni x86 işlemcileri, alınması beklenen dallar veya alınmaması beklenen dallar için talimatlara sahiptir (bir talimat öneki vardır; ayrıntılardan emin değilim). İşlemcinin bunu kullandığından emin değilim. Çok kullanışlı değil, çünkü dal tahmini bunu halledecek. Bu yüzden şube tahminini gerçekten etkileyebileceğinizi sanmıyorum .

OP ile ilgili olarak, hayır, GCC'de işlemciye her zaman şubenin alındığını veya alınmadığını varsaymasını söylemenin bir yolu yoktur. Sahip olduğunuz şey __builtin_expect, başkalarının söylediğini yapar. Ayrıca, işlemciye şubenin alınıp alınmadığını her zaman söylemek istemediğinizi düşünüyorum . Intel mimarisi gibi günümüz işlemcileri oldukça karmaşık kalıpları tanıyabilir ve etkili bir şekilde uyum sağlayabilir.

Ancak, varsayılan olarak bir şubenin alınıp alınmayacağının kontrolünü üstlenmek isteyeceğiniz zamanlar vardır : Bildiğiniz zaman, kodun dallanma istatistikleri açısından "soğuk" olarak adlandırılacağını bildiğiniz zaman.

Somut bir örnek: İstisna yönetimi kodu. Tanım gereği yönetim kodu istisnai olarak gerçekleşecektir, ancak belki de oluştuğunda maksimum performans istenir (mümkün olan en kısa sürede ilgilenilmesi gereken kritik bir hata olabilir), bu nedenle varsayılan tahmini kontrol etmek isteyebilirsiniz.

Başka bir örnek: Girişinizi sınıflandırabilir ve sınıflandırmanızın sonucunu işleyen koda atlayabilirsiniz. Çok sayıda sınıflandırma varsa, işlemci istatistikleri toplayabilir ancak bunları kaybedebilir, çünkü aynı sınıflandırma yeterince erken gerçekleşmez ve tahmin kaynakları yakın zamanda adlandırılan koda ayrılmıştır. Keşke işlemciye bazen "bunu önbelleğe almayın" diyebileceğiniz şekilde "lütfen tahmin kaynaklarını bu koda ayırmayın" diyen bir ilkel olsaydı.