Czy istnieje wskazówka kompilatora dla GCC, aby wymusić przewidywanie gałęzi, aby zawsze iść w określony sposób?

Czy w przypadku architektur Intela istnieje sposób, aby poinstruować kompilator GCC, aby generował kod, który zawsze wymusza przewidywanie gałęzi w określony sposób w moim kodzie? Czy sprzęt Intel w ogóle to obsługuje? A co z innymi kompilatorami lub oprogramowaniem sprzętowym?

Użyłbym tego w kodzie C ++, w którym znam przypadek, w którym chcę działać szybko i nie przejmuję się spowolnieniem, gdy inna gałąź musi zostać podjęta, nawet jeśli niedawno zajęła tę gałąź.

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

Jako następne pytanie dla Evdzhana Mustafy, czy wskazówka może po prostu podać wskazówkę po raz pierwszy, gdy procesor napotka instrukcję, wszystkie kolejne przewidywania gałęzi, działają normalnie?

Począwszy od C ++ 20 prawdopodobne i mało prawdopodobne atrybuty powinny być znormalizowane i są już obsługiwane w g ++ 9 . Jak omówiono tutaj , możesz pisać

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

np. w poniższym kodzie blok else jest wstawiany dzięki [[unlikely]]blokowi in the if

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

łącze godbolt porównujące obecność / brak atrybutu

GCC obsługuje funkcję __builtin_expect(long exp, long c)dostarczania tego rodzaju funkcji. Możesz sprawdzić dokumentację tutaj .

Gdzie expjest używany warunek i cjest wartością oczekiwaną. Na przykład, jeśli chcesz

if (__builtin_expect(normal, 1))

Ze względu na niezręczną składnię jest to zwykle używane przy definiowaniu dwóch niestandardowych makr, takich jak

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

tylko po to, aby ułatwić zadanie.

Weź to pod uwagę:

1. to jest niestandardowe
2. kompilator / predyktor gałęzi procesora prawdopodobnie ma większe umiejętności niż ty w podejmowaniu takich decyzji, więc może to być przedwczesna mikro-optymalizacja

gcc ma long __builtin_expect (długie exp, długie c) ( moje podkreślenie ):

Możesz użyć __builtin_expect, aby dostarczyć kompilatorowi informacje przewidywania gałęzi. Ogólnie rzecz biorąc, do tego celu należy używać rzeczywistych opinii o profilu (-fprofile-arcs), ponieważ programiści są notorycznie źli w przewidywaniu rzeczywistego działania ich programów . Są jednak aplikacje, w których trudno jest zebrać te dane.

Wartość zwracana to wartość exp, która powinna być wyrażeniem całkowitym. Semantyka funkcji wbudowanej polega na tym, że oczekuje się, że exp == c. Na przykład:

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

wskazuje, że nie oczekujemy wywołania foo, ponieważ spodziewamy się, że x będzie równe zero. Ponieważ jesteś ograniczony do wyrażeń całkowych dla exp, powinieneś używać konstrukcji takich jak

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

podczas testowania wartości wskaźnikowych lub zmiennoprzecinkowych.

Jak zauważa dokumentacja, powinieneś preferować użycie rzeczywistych opinii o profilu, a ten artykuł pokazuje praktyczny przykład tego i jak w ich przypadku przynajmniej kończy się to ulepszeniem w stosunku do używania __builtin_expect. Zobacz także Jak korzystać z optymalizacji sterowanej profilem w g ++?.

Możemy również znaleźć artykuł dla początkujących użytkowników jądra Linuksa na temat prawdopodobnie () i mało prawdopodobnych () makr jądra, które używają tej funkcji:

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

Zwróć uwagę na !!używane w makrze wyjaśnienie tego problemu w Dlaczego używać !! (warunek) zamiast (warunek)?.

Tylko dlatego, że ta technika jest używana w jądrze Linuksa, nie oznacza, że ​​zawsze ma sens. Z tego pytania widzimy, że ostatnio odpowiedziałem na różnicę między wydajnością funkcji podczas przekazywania parametru jako stałej czasu kompilacji lub zmiennej że wiele ręcznych technik optymalizacji nie działa w ogólnym przypadku. Musimy uważnie profilować kod, aby zrozumieć, czy technika jest skuteczna. Wiele starych technik może nawet nie mieć zastosowania w przypadku nowoczesnych optymalizacji kompilatorów.

Uwaga, chociaż wbudowane elementy nie są przenośne, clang obsługuje również __builtin_expect .

Również w przypadku niektórych architektur może to nie mieć znaczenia .

Nie, nie ma. (Przynajmniej na nowoczesnych procesorach x86).

__builtin_expectwspomniany w innych odpowiedziach wpływa na sposób, w jaki gcc organizuje kod asemblera. Nie wpływa bezpośrednio na predyktor gałęzi procesora.Oczywiście, zmiana kolejności kodu będzie miała pośredni wpływ na przewidywanie gałęzi. Ale na nowoczesnych procesorach x86 nie ma instrukcji, która mówi procesorowi „załóżmy, że ta gałąź jest / nie jest zajęta”.

Zobacz to pytanie, aby uzyskać więcej szczegółów: Czy faktycznie używana predykcja rozgałęzienia prefiksu Intel x86 0x2E / 0x3E?

Aby było jasne, __builtin_expecti / lub użycie -fprofile-arcs może poprawić wydajność twojego kodu, zarówno poprzez udzielanie wskazówek predyktorowi gałęzi poprzez układ kodu (patrz Optymalizacja wydajności zestawu x86-64 - Wyrównanie i przewidywanie gałęzi ), a także poprawienie zachowania pamięci podręcznej zachowując „mało prawdopodobny” kod z dala od „prawdopodobnego” kodu.

Prawidłowy sposób definiowania prawdopodobnych / mało prawdopodobnych makr w C ++ 11 jest następujący:

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

Ta metoda jest zgodna ze wszystkimi wersjami C ++, w przeciwieństwie do [[likely]], ale opiera się na niestandardowym rozszerzeniu __builtin_expect.

Gdy te makra są zdefiniowane w ten sposób:

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

Może to zmienić znaczenie ifinstrukcji i złamać kod. Rozważ następujący kod:

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

I jego wynik:

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

Jak widać, definicja PRAWDOPODOBNEGO używania !!jako rzutowania boolłamie semantykę if.

Nie o to chodzi operator int()i operator bool()powinno być powiązane. Co jest dobrą praktyką.

Raczej używanie !!(x)zamiast static_cast<bool>(x)traci kontekst dla konwersji kontekstowych C ++ 11 .

Ponieważ wszystkie inne odpowiedzi odpowiednio zasugerowały, możesz użyć, __builtin_expectaby dać kompilatorowi wskazówkę, jak zorganizować kod asemblera. Jak wskazują oficjalne dokumenty , w większości przypadków asembler wbudowany w twój mózg nie będzie tak dobry, jak ten stworzony przez zespół GCC. Zawsze najlepiej jest używać rzeczywistych danych profilu do optymalizacji kodu, zamiast zgadywać.

W podobny sposób, ale jeszcze nie wspomniano, znajduje się specyficzny dla GCC sposób wymuszenia na kompilatorze generowania kodu na „zimnej” ścieżce. Obejmuje to użycie atrybutów noinlinei cold, które robią dokładnie to, na co wyglądają. Te atrybuty można zastosować tylko do funkcji, ale w C ++ 11 można deklarować wbudowane funkcje lambda, a te dwa atrybuty można również zastosować do funkcji lambda.

Chociaż nadal należy to do ogólnej kategorii mikrooptymalizacji, a zatem ma zastosowanie standardowa rada - test nie zgaduj - wydaje mi się, że jest ona bardziej użyteczna niż __builtin_expect. Prawie żadne generacje procesorów x86 nie używają wskazówek dotyczących przewidywania rozgałęzień ( odniesienie ), więc jedyną rzeczą, na którą i tak będziesz mógł wpłynąć, jest kolejność kodu asemblera. Ponieważ wiesz, co to jest kod obsługi błędów lub kod „przypadków skrajnych”, możesz użyć tej adnotacji, aby upewnić się, że kompilator nigdy nie przewidział do niego gałęzi i połączy go z „gorącym” kodem podczas optymalizacji pod kątem rozmiaru.

Przykładowe użycie:

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

Co więcej, GCC automatycznie zignoruje to na korzyść opinii o profilu, gdy jest dostępna (np. Podczas kompilacji -fprofile-use).

Zobacz oficjalną dokumentację tutaj: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes

__builtin_expect może służyć do wskazania kompilatorowi, w którą stronę ma iść gałąź. Może to wpłynąć na sposób generowania kodu. Typowe procesory sekwencyjnie uruchamiają kod szybciej. Więc jeśli piszesz

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

kompilator wygeneruje kod podobny do

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;

Jeśli twoja wskazówka jest poprawna, spowoduje to wykonanie kodu bez żadnych faktycznie wykonanych gałęzi. Będzie działać szybciej niż normalna sekwencja, w której każda instrukcja if będzie rozgałęziać się wokół kodu warunkowego i wykona trzy gałęzie.

Nowsze procesory x86 mają instrukcje dotyczące gałęzi, które mają zostać pobrane, lub dla gałęzi, które mają nie zostać pobrane (istnieje przedrostek instrukcji; nie jestem pewien szczegółów). Nie jestem pewien, czy procesor tego używa. Nie jest to zbyt przydatne, ponieważ przewidywanie gałęzi poradzi sobie z tym dobrze. Więc nie sądzę, że możesz faktycznie wpłynąć na przewidywanie gałęzi .

Jeśli chodzi o OP, nie, w GCC nie ma sposobu, aby powiedzieć procesorowi, aby zawsze zakładał, że gałąź jest lub nie jest zajęta. To, co masz, to __builtin_expect, co robi to, co mówią inni. Ponadto myślę, że nie chcesz mówić procesorowi, czy gałąź jest zajęta, czy nie zawsze . Dzisiejsze procesory, takie jak architektura Intela, potrafią rozpoznawać dość złożone wzorce i skutecznie się dostosowywać.

Jednak są chwile, kiedy chcesz przejąć kontrolę nad tym, czy domyślnie przewiduje się, że gałąź jest brana, czy nie: Kiedy wiesz, że kod będzie nazywany „zimnym” w odniesieniu do statystyk rozgałęzień.

Jeden konkretny przykład: kod zarządzania wyjątkami. Z definicji kod zarządzający będzie działał wyjątkowo, ale być może gdy wystąpi, wymagana jest maksymalna wydajność (może wystąpić błąd krytyczny, aby zająć się jak najszybciej), dlatego warto kontrolować domyślną prognozę.

Inny przykład: możesz sklasyfikować swoje dane wejściowe i przejść do kodu, który obsługuje wynik Twojej klasyfikacji. Jeśli istnieje wiele klasyfikacji, procesor może zbierać statystyki, ale je tracić, ponieważ ta sama klasyfikacja nie następuje wystarczająco szybko, a zasoby prognozowania są przeznaczone na ostatnio wywołany kod. Chciałbym, żeby było prymitywne powiedzenie procesorowi „proszę nie poświęcać zasobów prognozowania temu kodowi”, tak jak czasami można powiedzieć „nie buforuj tego”.