[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Using __builtin_expect (likely/unlikely macros)
From: |
Óscar Fuentes |
Subject: |
Re: Using __builtin_expect (likely/unlikely macros) |
Date: |
Sat, 20 Apr 2019 21:35:47 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Paul Eggert <address@hidden> writes:
> Óscar Fuentes wrote:
>>> For improvements where the
>>> generated code is "obviously" faster (fewer and simpler instructions,
>>> say), I typically don't bother with measurements as my own time is
>>> limited too.
>> You will be surprised.
>>
>> Modern hardware is complex.
>
> I'm often surprised :-), but I don't expect to be surprised when the
> generated code seems obviously faster to me. Although I'm not as
> expert as the computer architecture researcher whose office sits next
> to mine, I know how modern hardware works reasonably well and
> regularly give lectures on topics like μops and TLBs so I won't be
> surprised as often as a naive programmer might be.
I served many years as an Assembler programmer replacing C code where it
was considered too slow so, excuse my arrogance, I'm far from being a
naive programmer.
I've seen many times cases where removing code (deleting unnecessary
instructions and even full procedure calls) made the program run
noticeably slower. "noticeably" as in "you don't need a stopwatch to
notice it".
Also, I've seen plenty of speedups on my development machine that
vanished or even reversed when tried on a different microarchitecture,
or the same microarchitecture with different cache sizes, or even the
same CPU with different RAM modules.
On our time of multi-level caches, branch prediction, speculative
execution and what-not, acting as if your hard-earned 1% speedup will
apply to most machines out there is a risky bet.
>> If the 1.3% improvement in performance requires non-minimal source
>> code complexity growth
>
> It doesn't. In this case the source code shrank slightly. Only very
> slightly: just by 0.001% (this counts all files under Git control).
> Still, a win's a win.
Yea, but now everybody has to learn about and, worse, deal with those
non-standard macros. That's added complexity. And I'm pretty sure that
the speedup will vanish as code is modified and compilers and CPUs
change.
- Re: Using __builtin_expect (likely/unlikely macros), (continued)
- Re: Using __builtin_expect (likely/unlikely macros), Andy Moreton, 2019/04/20
- Re: Using __builtin_expect (likely/unlikely macros), Paul Eggert, 2019/04/20
- Re: Using __builtin_expect (likely/unlikely macros), Eli Zaretskii, 2019/04/20
- Re: Using __builtin_expect (likely/unlikely macros), Paul Eggert, 2019/04/20
- Re: Using __builtin_expect (likely/unlikely macros), Eli Zaretskii, 2019/04/20
- Re: Using __builtin_expect (likely/unlikely macros), Paul Eggert, 2019/04/20
- Re: Using __builtin_expect (likely/unlikely macros), Eli Zaretskii, 2019/04/20
- Re: Using __builtin_expect (likely/unlikely macros), Paul Eggert, 2019/04/20
- Re: Using __builtin_expect (likely/unlikely macros), Óscar Fuentes, 2019/04/20
- Re: Using __builtin_expect (likely/unlikely macros), Paul Eggert, 2019/04/20
- Re: Using __builtin_expect (likely/unlikely macros),
Óscar Fuentes <=
- Re: Using __builtin_expect (likely/unlikely macros), Paul Eggert, 2019/04/20