Why Const Doesn't Make C Code Faster

Post by icedchai » Tue, Aug 20, 2019, 2:25 PM UTC

will4274 wrote: post #104

stephc_int13 wrote: post #97

I once had a very stubborn intern who decided to add as much const as he could in our codebase. What followed was a heated discussion and I did a global replace of const by nothing. The main problem with const is that it's ugly, it's viral and it does not add any value to the code. And I know all the supposedly good things about this, but I never found any real usage in practice.

You should fire yourself. Seriously. Understanding which object parameters to a function are inputs and which ones are modified is key information about the behavior of a function. It's omission requires devs to divine the intent from the name and hope that every previous dev was a good citizen w.r.t keeping function names accurate to intent. Finding and replace const with empty is the moral equivalent of replacing a…

Post by boomlinde » Tue, Aug 20, 2019, 2:56 PM UTC

boomlinde wrote: post #170

DagAgren wrote: post #156

Earlier quoted context omitted.

Static but not inline functions will trigger warnings of unused functions. Static and inline does not trigger this.

> Static but not inline functions will trigger warnings of unused functions. Well, isn't it true? It's true also in the inline case. I consider it strange behavior not to emit an explicitly enabled warning for a case that definitely satisfies the warning conditions. > Static and inline does not trigger this. Tried -Wunused-function in gcc 6.3.0 and clang 3.8.1-24, with an unused-but-defined function declared "static…

Post by Buge » Tue, Aug 20, 2019, 3:58 PM UTC

daemin wrote: post #171

Buge wrote: post #108

Earlier quoted context omitted.

While specifying inline alone is useless for optimization, the inline specifier is important for another type of optimization: putting a function in a header file. If you put a function in a header file and don't mark it inline, that tends to be undefined behavior because it tends to violate the One Definition Rule, (both C and C++).

Force inlining code is actually quite a useful optimisation still. We have found many instances that after a few inline functions the compiler gives up and just calls the function instead. Force inlining certain low level functions has actually improved performance by several percent in our codebase.

Post by sdinsn » Tue, Aug 20, 2019, 6:25 PM UTC

BubRoss wrote: post #63

sdinsn wrote: post #58

Earlier quoted context omitted.

Having a constant size probably made it easy for the compiler to properly generate bytecode that uses vectorized instructions

I would say that's unlikely. SIMD instructions don't usually get used by normal compilers without very specific loops that make sure there are no obstacles to vectorization. Also the best way to use SIMD is to loop through a large array of two and do very simple operations with them. Modern CPUs actually have three (I think) floating point slots so their total floating point throughput isn't simply a fraction of the…

Post by dmitrygr » Tue, Aug 20, 2019, 8:35 PM UTC

fluffything wrote: post #165

gpderetta wrote: post #153

Earlier quoted context omitted.

Not if it is defined in another translation unit and you are not using LTO.

In other words, the compiler can infer this from the function definition (or at least clang does), but it cannot infer this from a function declaration, because the implementation is missing - unless you are using LTO like the parent mentions.

  void* __attribute__((const)) getGlobals(void) {
    void* ret;

    asm (
      " ldr %0, [r9]      \n"
      " ldr %0, [%0, %1]  \n"
      : "=r"(ret)
      : "I"(MY_MODULE_ID)
      :
    );
    return ret;
  }