Wie viel Gebrauch von "wahrscheinlichen" und "unwahrscheinlichen" Makros ist zu viel?

Die häufig als likelyund bezeichneten unlikelyMakros helfen dem Compiler zu wissen, ob ifnormalerweise ein eingegeben oder übersprungen wird. Die Verwendung führt zu einigen (eher geringfügigen) Leistungsverbesserungen.

Ich habe vor kurzem angefangen, sie zu verwenden, und ich bin mir nicht sicher, wie oft solche Hinweise verwendet werden sollten. Ich benutze es derzeit mit Fehlerprüfungen if, die in der Regel als gekennzeichnet sind unlikely. Beispielsweise:

mem = malloc(size);
if (unlikely(mem == NULL))
  goto exit_no_mem;

Es scheint in Ordnung zu sein, aber Fehlerprüfungen ifkommen ziemlich oft vor und folglich die Verwendung der genannten Makros.

Meine Frage ist, ist es zu viel zu haben likelyund unlikelyMakros auf jeder Fehlerprüfung if?

Welche anderen Orte werden oft benutzt, wenn wir schon dabei sind?

In meiner jetzigen Verwendung befindet es sich in einer Bibliothek, die eine Abstraktion vom Echtzeit-Subsystem vornimmt, sodass Programme zwischen RTAI, QNX und anderen portierbar werden. Die meisten Funktionen sind jedoch eher klein und rufen direkt eine oder zwei andere Funktionen auf. Viele sind sogar static inlineFunktionen.

Zuallererst ist es also keine Anwendung, die ich profilieren könnte. Es ist nicht sinnvoll, Engpässe zu identifizieren, da es sich um eine Bibliothek und nicht um eine eigenständige Anwendung handelt.

Zweitens ist es wie "Ich weiß, dass dies unwahrscheinlich ist, ich könnte es auch dem Compiler sagen". Ich versuche nicht aktiv, das zu optimieren if.

Benötigen Sie eine so hohe Leistung, dass Sie bereit sind, Ihren Code damit zu verschmutzen? Es ist eine kleine Optimierung.

• Läuft der Code in einer engen Schleife?
• Hat Ihre Anwendung Leistungsprobleme?
• Haben Sie Ihre Anwendung profiliert und festgestellt, dass diese bestimmte Schleife viel CPU-Zeit kostet?

Wenn Sie nicht yesauf alles oben Genannte antworten können, kümmern Sie sich nicht um solche Dinge.

Bearbeiten: als Antwort auf die Bearbeitung. Selbst wenn Sie kein Profil erstellen können, können Sie in der Regel Hotspots schätzen. Eine von jedem aufgerufene Speicherzuweisungsfunktion ist ein guter Kandidat, zumal für die gesamte Bibliothek nur eine einzige Verwendung des Makros erforderlich ist.

Wenn Sie für x86 / x64 schreiben (und keine 20 Jahre alten CPUs verwenden), ist der Leistungsgewinn durch die Verwendung von __builtin_expect () vernachlässigbar. Der Grund dafür ist, dass moderne x86 / x64-CPUs (die sich in Bezug auf Atom nicht 100% sicher sind) eine dynamische Verzweigungsvorhersage haben, sodass die CPU im Wesentlichen von der Verzweigung "erfährt", die häufiger in Anspruch genommen wird. Natürlich können diese Informationen nur für eine begrenzte Anzahl von Zweigen gespeichert werden, es sind jedoch nur zwei Fälle möglich. Wenn (a) es sich um einen "häufig verwendeten" Zweig handelt, profitiert Ihr Programm von dieser dynamischen Verzweigungsvorhersage, und wenn (b) es sich um einen "seltenen" Zweig handelt, werden Sie aufgrund von Fehleinschätzungen in keinen realistischen Leistungseinbruch feststellen Solche seltenen Verzweigungen (20 CPU-Zyklen der Verzweigungsfehlervorhersage sind nicht ZU schlecht, wenn sie einmal in einem blauen Mond vorkommen).

NB: Dies bedeutet NICHT, dass auf modernen x86 / x64-Systemen die Wichtigkeit von Verzweigungsfehlervorhersagen geringer geworden ist: Bei Verzweigungen mit einer Wahrscheinlichkeit von 50-50 von Sprung-Nojump wird immer noch eine Strafe verhängt (IIRC 10-20 CPU-Zyklen) müssen noch vermieden werden. Es ist nur wichtig, dass __builtin_expect () unter x86 / x64 abgenommen hat (IIRC vor etwa 10-15 Jahren) - hauptsächlich aufgrund der dynamischen Verzweigungsvorhersage.

NB2: für andere Plattformen als x86 / x64, YMMV.