That's a nice trick, but contrary to function statics, it is susceptible to SIOF.
This kind of optimization is useful only on extraordinarily hot paths, so I wouldn't generally recommend it.
> On ARM, such atomic load incurs a memory barrier---a fairly expensive operation.
Not quite, it is just a load-acquire, which is almost as cheap as a normal load. And on x86 there's no difference.
One thing where both GCC and Clang seem to be quite bad at is code layout: even in the example in the article, the slow path is largely inlined. It would be much better to have just a load, a compare, and a jump to the slow path in a cold section.
In my experience, in some rare cases reimplementing the lazy initialization explicitly (especially when it's possible to use a sentinel value, thus doing a single load for both value and guard) did produce a noticeable win.
The rabbit hole I just went down is called C/C++ Statement Expressions [1] which are a GCC extension:
#define FAST_STATIC(T) \
*({ \
\ // statements separated by semicolons
reinterpret_cast<T *>(ph.buf); \ // the value of the macro as a statement
})
The reinterpret_cast<T*>(...) statement is a conventional C++ Expression Statement, but when enclosed in ({}), GCC considers the whole kit and kaboodle a Statement Expression that propagates a value.
There is no C equivalent, but in in C++, since C++11 you can achieve the same effect with lambdas:
auto value = [](){ return 12345; }();
As noted in the linked SO discussion, this is analogous to a JS Immediately-Invoked Function Expression (IIFE).
Lambdas are not fully equivalent since return statements in statement expressions will return at the function level, whereas return statements in lambdas will only return at the lambda level.
Just for clarity, since I didn't understand on first reading.
int foo() {
int result = ({
if (some_condition)
return -1; // This returns from foo(), not just the statement expression
42;
});
// This line might never be reached
}
Funny enough I recently wrote my own hack using this linker feature in C, to implement an array of static counter definitions that can be declared anywhere and then written out (e.g., to prometheus) in one place.
Note that as I later found out, this doesn't work with Mac OS's linker, so you need to use some separate incantations for Mac OS.
std::launder should probably be used more than it is in low-level code if you care about correctness, even though it doesn’t always bite you in the ass. It is a logical no-op. std::launder is a hint to the compiler to forget everything it thinks it knows about the type instance, sort of like marking it “volatile” only for a specific moment in time.
The use of std::launder should be more common than it is, I’ve seen a few bugs in optimized builds when not used, but compilers have been somewhat forgiving about not using it in places you should because it hasn’t always existed. Rigorous code should be using it instead of relying on the leniency of the compiler.
In database engine code it definitely gets used in the storage layers.
>Even after the static variable has been initialised, the overhead of accessing it is still considerable: a function call to __cxa_guard_acquire(), plus atomic_load_explicit(&__b_guard, memory_order::acquire) in __cxa_guard_acquire().
No. The lock calls are only done during initialization, in case two threads run the initialization concurrently while the guard variable is 0. Once the variable is initialized, this will always be skipped by "je .L3".
Right, I was scratching my head exactly for that reason too. Even if the analysis was correct it would still be a solution for the problem that doesn't exist.
> For this we need a certain old, but little-known feature of UNIX linkers
STOP WRITING NON-PORTABLE CODE YOU BASTARDS.
The correct answer is, as always, “stop using mutable global variables you bastard”.
Signed: someone who is endlessly annoyed with people who incorrectly think Unix is the only platform their code will run on. Write standard C/C++ that doesn’t rely on obscure tricks. Your co-workers will hate you less.
> Every time someone ships successful code that's hard to port to Windows
Until your boss tells you to port your so-far Linux-only code to Windows, and you run that struggle.
Signed, someone who spent the past year or so porting Linux code to Windows and macOS because the business direction changed and the company saw what was the money-maker.
P.S. Not the parent commenter, because I just realised they, too, had a paragraph beginning with 'signed, ...'
I tell my coworkers, "Hey, we need this coded up as a Windows service!" and I get crickets.
So I spin up a Debian VM and POSIX the hell out of it. If they dare to complain, I tell 'em to do their damn jobs and not leave all the hard stuff to the guy that only programs on UNIX.
That's a nice trick, but contrary to function statics, it is susceptible to SIOF. This kind of optimization is useful only on extraordinarily hot paths, so I wouldn't generally recommend it.
> On ARM, such atomic load incurs a memory barrier---a fairly expensive operation.
Not quite, it is just a load-acquire, which is almost as cheap as a normal load. And on x86 there's no difference.
One thing where both GCC and Clang seem to be quite bad at is code layout: even in the example in the article, the slow path is largely inlined. It would be much better to have just a load, a compare, and a jump to the slow path in a cold section. In my experience, in some rare cases reimplementing the lazy initialization explicitly (especially when it's possible to use a sentinel value, thus doing a single load for both value and guard) did produce a noticeable win.
FDO/PGO seem to really improve optimizations for hot/cold functions. I wonder if it does the kind of thing you're suggesting.
The rabbit hole I just went down is called C/C++ Statement Expressions [1] which are a GCC extension:
The reinterpret_cast<T*>(...) statement is a conventional C++ Expression Statement, but when enclosed in ({}), GCC considers the whole kit and kaboodle a Statement Expression that propagates a value.There is no C equivalent, but in in C++, since C++11 you can achieve the same effect with lambdas:
As noted in the linked SO discussion, this is analogous to a JS Immediately-Invoked Function Expression (IIFE).[1] https://stackoverflow.com/questions/76890861/what-is-called-...
Lambdas are not fully equivalent since return statements in statement expressions will return at the function level, whereas return statements in lambdas will only return at the lambda level.
Just for clarity, since I didn't understand on first reading.
Funny enough I recently wrote my own hack using this linker feature in C, to implement an array of static counter definitions that can be declared anywhere and then written out (e.g., to prometheus) in one place.
Note that as I later found out, this doesn't work with Mac OS's linker, so you need to use some separate incantations for Mac OS.
I wrote a portable abstraction for this that works across Linux, MacOS, and Windows: https://github.com/protocolbuffers/protobuf/blob/4917ec250d3...
I call them "linker arrays". They are great when you need to globally register a set of things and the order between them isn't significant.
Looks similar to absl::NoDestructor
https://github.com/abseil/abseil-cpp/blob/master/absl/base/n...
Which is basically the only usage of std::launder I have seen
std::launder should probably be used more than it is in low-level code if you care about correctness, even though it doesn’t always bite you in the ass. It is a logical no-op. std::launder is a hint to the compiler to forget everything it thinks it knows about the type instance, sort of like marking it “volatile” only for a specific moment in time.
The use of std::launder should be more common than it is, I’ve seen a few bugs in optimized builds when not used, but compilers have been somewhat forgiving about not using it in places you should because it hasn’t always existed. Rigorous code should be using it instead of relying on the leniency of the compiler.
In database engine code it definitely gets used in the storage layers.
TIL about encapsulation symbols.
Why not just use constinit (iff applicable), construct_at, or lessen the cost with -fno-threadsafe-statics?
>Even after the static variable has been initialised, the overhead of accessing it is still considerable: a function call to __cxa_guard_acquire(), plus atomic_load_explicit(&__b_guard, memory_order::acquire) in __cxa_guard_acquire().
No. The lock calls are only done during initialization, in case two threads run the initialization concurrently while the guard variable is 0. Once the variable is initialized, this will always be skipped by "je .L3".
Right, I was scratching my head exactly for that reason too. Even if the analysis was correct it would still be a solution for the problem that doesn't exist.
> For this we need a certain old, but little-known feature of UNIX linkers
STOP WRITING NON-PORTABLE CODE YOU BASTARDS.
The correct answer is, as always, “stop using mutable global variables you bastard”.
Signed: someone who is endlessly annoyed with people who incorrectly think Unix is the only platform their code will run on. Write standard C/C++ that doesn’t rely on obscure tricks. Your co-workers will hate you less.
Every time someone ships successful code that's hard to port to Windows the world becomes a better place.
> Every time someone ships successful code that's hard to port to Windows
Until your boss tells you to port your so-far Linux-only code to Windows, and you run that struggle.
Signed, someone who spent the past year or so porting Linux code to Windows and macOS because the business direction changed and the company saw what was the money-maker.
P.S. Not the parent commenter, because I just realised they, too, had a paragraph beginning with 'signed, ...'
Looks like you're complaining about too much job security. Also it's you choice to accept that task and make the world a slightly worse place again.
I tell my coworkers, "Hey, we need this coded up as a Windows service!" and I get crickets.
So I spin up a Debian VM and POSIX the hell out of it. If they dare to complain, I tell 'em to do their damn jobs and not leave all the hard stuff to the guy that only programs on UNIX.
Their tasks would be less hard if the UNIX guy would stop writing non-portable POSIX code =P