60

GCC compiler supports __builtin_expect statement that is used to define likely and unlikely macros.

eg.

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

Is there an equivalent statement for the Microsoft Visual C compiler, or something equivalent ?

Edward Z. Yang
  • 26,325
  • 16
  • 80
  • 110
Franck Freiburger
  • 26,310
  • 20
  • 70
  • 95
  • 3
    Vote to add this feature on the [VS feedback](https://connect.microsoft.com/VisualStudio/feedback/details/2394761) site! – rustyx Feb 23 '16 at 14:34
  • 2
    Note that Microsoft stated that they don't like these kind of optimizations [here](https://connect.microsoft.com/VisualStudio/Feedback/Details/804542) and [here](https://connect.microsoft.com/VisualStudio/Feedback/Details/804288). It seems unlikely (no pun intended) that this will be added in the future. `We want people to use profile guided optimizations instead of annotating their code by hand. See `[this blog post](http://blogs.msdn.com/b/vcblog/archive/2013/04/08/profile-guided-optimization-pgo.aspx) `for more info. Profile counts don't lie (or rather, they lie much less than users do).` – jrh Dec 17 '16 at 15:08
  • see also [`BOOST_LIKELY` and `BOOST_UNLIKELY`](https://stackoverflow.com/q/30266738/995714) – phuclv Jun 24 '18 at 11:30
  • @jrh all those links are now dead. Another answer: *[The argument for not implementing this feature is that it is non-standard. MSVC is pushing to implement standards features, not extend the language in ways that are incompatible with other compilers](https://blogs.msdn.microsoft.com/vcblog/2016/05/04/new-code-optimizer/). (We’ve done too much of that in our past.) There is a standards proposal to introduce such an attribute. When it is standardized, we will implement it: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0627r0.pdf – phuclv Jun 24 '18 at 11:35
  • @phuclv unfortunately there's no archive I know of for connect pages. On the connect page a Microsoft employee said that machines did a better job of optimizing, I guess we're getting a slightly different story now ("it's not standards compliant"). – jrh Jun 25 '18 at 12:00
  • 1
    @phuclv See also: [this meta post](https://meta.stackoverflow.com/questions/363610/microsoft-connect-died-and-breaks-lots-of-links) on connect links. – jrh Jun 25 '18 at 12:07

8 Answers8

25

C++20 standard will include [[likely]] and [[unlikely]] branch prediction attributes.

The latest revision of attribute proposal can be found from http://wg21.link/p0479

The original attribute proposal can be found from http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0479r0.html

Programmers should prefer PGO. Attributes can easily reduce performance if applied incorrectly or they later become incorrect when program changes.

phuclv
  • 37,963
  • 15
  • 156
  • 475
Pauli Nieminen
  • 1,100
  • 8
  • 7
  • 2
    [What are the chances of getting something like GCC’s `__builtin_expect` (aka `likely`/`unlikely)?](https://blogs.msdn.microsoft.com/vcblog/2016/05/04/new-code-optimizer/) *The argument for not implementing this feature is that it is non-standard. MSVC is pushing to implement standards features, not extend the language in ways that are incompatible with other compilers. (We’ve done too much of that in our past.) There is a standards proposal to introduce such an attribute. When it is standardized, we will implement it: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0627r0.pdf* – phuclv Jun 24 '18 at 11:19
  • 1
    Now implemented in MSVC, GCC, and Clang. Note that it’s impossible to use this with the ternary operator, for example. – Alex Shpilkin Jan 17 '21 at 18:11
20

According to http://www.akkadia.org/drepper/cpumemory.pdf (page 57), it still makes sense to use static branch prediction even if CPU predicts correctly dynamically. The reason for that is that L1i cache will be used even more efficiently if static prediction was done right.

Gene
  • 209
  • 2
  • 3
17

I say just punt

There is nothing like it. There is __assume(), but don't use it, it's a different kind of optimizer directive.

Really, the reason the gnu builtin is wrapped in a macro is so you can just get rid of it automatically if __GNUC__ is not defined. There isn't anything the least bit necessary about those macros and I bet you will not notice the run time difference.

Summary

Just get rid of (null out) *likely on non-GNU. You won't miss it.

ZachB
  • 13,051
  • 4
  • 61
  • 89
DigitalRoss
  • 143,651
  • 25
  • 248
  • 329
  • 16
    I have a hardware device, after ever function call I need to perform a check like `safeCall(mDevice.doit())`, my `safeCall` is in-lined which increases performance, but only when I have likely/unlikely branch. I want to say that these macros can be useful. – Mikhail Jan 04 '14 at 23:41
  • 4
    "In general, you should prefer to use actual profile feedback for [branch prediction] (-fprofile-arcs), as programmers are notoriously bad at predicting how their programs actually perform." https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html – holgac Dec 19 '14 at 15:12
  • 2
    Well I do miss the `unlikely` intrinsic. Without PGO (which is a PITA) the *stupid* MSVC almost *always* orders instructions the wrong way. – rustyx Feb 20 '16 at 20:37
  • 8
    Although you do advise against it, naming `_assume` as "close" in this context is a bit of an unlucky wording, since it is not even remotely similar. The unaware reader might interprete _"can get incorrect code"_ wrongly. Its meanining is equivalent to `__builtin_unreachable`. Using it for branch hinting is not just dangerous, it is by all means, and always, _incorrect_. – Damon Dec 15 '16 at 08:39
  • 3
    More precisely, `_assume(cond)` is semantically largely equivalent to `if (!(cond)) __builtin_unreachable();` in GCC. Which means using it as a branching hint allows the compiler to delete the whole "unreachable" branch and the condition as well if it does not have side effects. – Arne Vogel Jun 26 '17 at 12:06
  • That link is dead, here's the latest: https://learn.microsoft.com/en-us/cpp/intrinsics/assume – MarcusJ Jun 15 '18 at 22:36
  • benchmark for `__builtin_expect`: https://stackoverflow.com/a/35940041/995714 https://stackoverflow.com/a/31133787/995714 – phuclv Jun 24 '18 at 11:24
9

I know this question is about Visual Studio, but I'm going to try to answer for as many compilers as I can (including Visual Studio)…

A decade later there is progress! As of Visual Studio 2019 MSVC still doesn't support anything like this (even though it's the most popular builtin/intrinsic), but as Pauli Nieminen mentioned above C++20 has likely / unlikely attributes which can be used to create likely/unlikely macros and MSVC usually adds support for new C++ standards pretty quickly (unlike C) so I expect Visual Studio 2021 to support them.

Currently (2019-10-14) only GCC supports these attributes, and even then only applied to labels, but it is sufficient to at least do some basic testing. Here is a quick implementation which you can test on Compiler Explorer:

#define LIKELY(expr) \
  ( \
    ([](bool value){ \
      switch (value) { \
        [[likely]] case true: \
          return true; \
        [[unlikely]] case false: \
          return false; \
      } \
    }) \
  (expr))
#define UNLIKELY(expr) \
  ( \
    ([](bool value){ \
      switch (value) { \
        [[unlikely]] case true: \
          return true; \
        [[likely]] case false: \
          return false; \
      } \
    }) \
  (expr))

Edit (2022-05-02): MSVC 2022 supports C++20, including [[likely]]/[[unlikely]], but generates absolutely terrible code for this (see the comments on this post)... don't use it there.

You'll probably want to #ifdef around it to support compilers that can't handle it, but luckily most compilers support __builtin_expect:

  • GCC 3.0
  • clang
  • ICC since at least 13, probably much longer.
  • Oracle Development Studio 12.6+, but only in C++ mode.
  • ARM 4.1
  • IBM XL C/C++ since at least 10.1, probably longer.
  • TI since 6.1
  • TinyCC since 0.9.27

GCC 9+ also supports __builtin_expect_with_probability. It's not available anywhere else, but hopefully one day… It takes a lot of the guesswork out of trying to figure out whether to use ilkely/unlikely or not—you just set the probability and the compiler (theoretically) does the right thing.

Also, clang supports a __builtin_unpredictable (since 3.8, but test for it with __has_builtin(__builtin_unpredictable)). Since a lot of compilers are based on clang these days it probably works in them, too.

If you want this all wrapped up and ready to go, you might be interested in one of my projects, Hedley. It's a single public-domain C/C++ header which works on pretty much all compilers and contains lots of useful macros, including HEDLEY_LIKELY, HEDLEY_UNLIKELY, HEDLEY_UNPREDICTABLE, HEDLEY_PREDICT, HEDLEY_PREDICT_TRUE, and HEDLEY_PREDICT_FALSE. It doesn't have the C++20 version quite yet, but it should be there soon

Even if you don't want to use Hedley in your project, you might want to check the the implementations there instead of relying on the lists above; I'll probably forget to update this answer with new information, but Hedley should always be up-to-date.

nemequ
  • 16,623
  • 1
  • 43
  • 62
  • MSVC 2022 supports [[likely]] and [[unlikely]] - but generates terrible code with your lambda macros. The code MSVC generates if you put the [[likely]] attribute directly in the code is _much_ better. – Paul Groke May 01 '22 at 01:28
  • Even with optimization enabled? IIRC I tried it to verify it worked well, though (obviously) not with 2022. Anyways, good to know `[[likely]]`/`[[unlikely]]` work, I'll try to update Hedley soon. – nemequ May 01 '22 at 23:03
  • Yes, even with optimizations. MSVC 2022 seems to be unable to completely optimize away the switch-case. See https://godbolt.org/z/xhar5WWv5 The generated code improves dramatically when using if-else instead of switch-case. But in both cases, it loses the hint. Seems it cannot propagate it out of the inlined lambda. https://godbolt.org/z/fsqd4o5fM – Paul Groke May 02 '22 at 11:22
  • Okay, thanks! It looks like I didn't include this version in Hedley anyways (at the time only GCC supported it, and there wasn't a good reason not to just always use `__builtin_expect`), so no need to update it after all. I'll add a note to this answer and try to remember to file the issue with MS, though I'm not going to hold my breath for a fix :( – nemequ May 02 '22 at 13:01
7

According to Branch and Loop Reorganization to Prevent Mispredicts document from Intel:

In order to effectively write your code to take advantage of these rules, when writing if-else or switch statements, check the most common cases first and work progressively down to the least common.

Unfortunately you cannot write something like

#define if_unlikely(cond) if (!(cond)); else 

because MSVC optimizer as of VS10 ignores such "hint".

As I prefer to deal with errors first in my code, I seem to write less efficient code. Fortunately, second time CPU encounters the branch it will use its statistics instead of a static hint.

jww
  • 97,681
  • 90
  • 411
  • 885
  • 7
    In answer to Xentrax: Your statement regarding MSVC does not seem to match with my observation. I'm using VS 2010 and see the compiler generating a "jne" when using a normal if. But when using an else instead, the compiler generates a "je", and puts the else block after the main flow. So, with MSVC, your define does seems to work. Now if only I could find a statement from MS that this is intended, supported behavior... – Ruben Apr 23 '13 at 07:52
  • @Ruben: I was exploiting this code-gen trick since at least MSVC 2005. It still works like this in all versions since. – Yakov Galka Jan 21 '21 at 03:55
6

__assume should be similar.

However, if you want to do this really well you should use Profile Guided Optimization rather than static hints.

SamB
  • 9,039
  • 5
  • 49
  • 56
Michael
  • 54,279
  • 5
  • 125
  • 144
  • 12
    I think this might be dangerous. According to Microsoft: "Because the compiler generates code based on __assume, that code might not run correctly if the expression inside the __assume statement is false at run time." – DigitalRoss Sep 17 '09 at 19:38
  • @Digital - Very true, the linked to MSDN article describes the pitfalls. Again, static hints like this should be avoided and you should try to use PGO if at all possible. – Michael Sep 17 '09 at 20:30
  • 5
    Sorry but PGO is PITA, especially in libraries of any decent complexity. I know better what is likely and what is unlikely in my own code. – rustyx Feb 10 '16 at 16:02
5

Now MS said they have implemented likely/unlikely attributes

But in fact there isn't any different between using "likely" or not using.

I have compiled these codes and is produce same result.

    int main()
    {
        int i = rand() % 2;
        if (i) [[likely]]
        {
           printf("Hello World!\n");
        }
        else
        {
            printf("Hello World2%d!\n",i);
        }
    }
    int main()
    {
        int i = rand() % 2;
        if (i)
        {
           printf("Hello World!\n");
        }
        else [[likely]]
        {
            printf("Hello World2%d!\n",i);
        }
    }
int pdb._main (int argc, char **argv, char **envp);
0x00401040      push    ebp
0x00401041      mov     ebp, esp
0x00401043      push    ecx
0x00401044      call    dword [rand] ; pdb.__imp__rand
                                   ; 0x4020c4
0x0040104a      and     eax, 0x80000001
0x0040104f      jns     0x401058
0x00401051      dec     eax
0x00401052      or      eax, 0xfffffffe ; 4294967294
0x00401055      add     eax, 1
0x00401058      je      0x40106d
0x0040105a      push    str.Hello_World ; pdb.___C__0O_NFOCKKMG_Hello_5World__CB_6
                                   ; 0x402108 ; const char *format
0x0040105f      call    pdb._printf ; int printf(const char *format)
0x00401064      add     esp, 4
0x00401067      xor     eax, eax
0x00401069      mov     esp, ebp
0x0040106b      pop     ebp
0x0040106c      ret
0x0040106d      push    0
0x0040106f      push    str.Hello_World2_d ; pdb.___C__0BB_DODJFBPJ_Hello_5World2__CFd__CB_6
                                   ; 0x402118 ; const char *format
0x00401074      call    pdb._printf ; int printf(const char *format)
0x00401079      add     esp, 8
0x0040107c      xor     eax, eax
0x0040107e      mov     esp, ebp
0x00401080      pop     ebp
0x00401081      ret
Yue Yin
  • 61
  • 1
  • 2
  • 2
    This is correct. [[likely]] and [[unlikely]] are noops. The feature tracking this being hooked to the optimizer is here: https://developercommunity2.visualstudio.com/t/unlikelylikely-have-no-effect-i/1383350 – Mac Mar 28 '21 at 21:18
2

As the question is old, the answers saying there's no [[likely]] / [[unlikely]] in MSVC, or that there's no impact are obsolete.

Latest MSVC supports [[likely]] / [[unlikely]] in /std:c++20 and /std:c++latest modes.

See demo on Godbolt's compiler explorer that shows the difference.

As can be seen from the link above, one visible effect on x86/x64 for if-else statement is that the conditional jump forward will be for unlikely branch. Before C++20 and supporting VS version the same could be achieved by placing the likely branch into if part, and the unlikely branch into else part, negating the condition as needed.

Note that the effect of such optimization is minimal. For frequently called code in a tight loop, the dynamic branch prediction would do the right thing anyway.

Alex Guteniev
  • 12,039
  • 2
  • 34
  • 79