Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++: Zero-cost static initialization

cofault.com

Post reply on HN
Print view View original

11–20 of 60 posts

Re: C++: Zero-cost static initialization

#11

Post by spauldo »

forrestthewoods wrote: post #5

> 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 le…

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.

Re: C++: Zero-cost static initialization

#12

Post by forrestthewoods »

spauldo wrote: post #11
forrestthewoods wrote: post #5

> 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 le…

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

Re: C++: Zero-cost static initialization

#13

Post by surajrmal »

ot wrote: post #3

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 Cl…

FDO/PGO seem to really improve optimizations for hot/cold functions. I wonder if it does the kind of thing you're suggesting.

Re: C++: Zero-cost static initialization

#14

Post by viralsink »

naruhodo wrote: post #10

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 (ph.buf); \ // the value of the macro as a statement }) The reinterpret_cast (...) statement is a conventional C++ Expression Statement, but when enclosed in ({}), GCC considers the whole kit and kaboodle a Statement Expression th…

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.

Re: C++: Zero-cost static initialization

#15

Post by menaerus »

pbsd wrote: post #2

>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 wil…

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.

Re: C++: Zero-cost static initialization

#16

Post by jojobas »

forrestthewoods wrote: post #5

> 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 le…

Every time someone ships successful code that's hard to port to Windows the world becomes a better place.

Re: C++: Zero-cost static initialization

#17

Post by quibono »

viralsink wrote: post #14
naruhodo wrote: post #10

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 (ph.buf); \ // the value of the macro as a statement }) The reinterpret_cast (...) statement is a conventional C++ Expression Statement, but when enclosed in ({}), GCC considers the whole kit and kaboodle a Statement Expression th…

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
}

Re: C++: Zero-cost static initialization

#18

Post by delta_p_delta_x »

jojobas wrote: post #16
forrestthewoods wrote: post #5

> 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 le…

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, ...'

Re: C++: Zero-cost static initialization

#19

Post by jojobas »

delta_p_delta_x wrote: post #18
jojobas wrote: post #16

Earlier quoted context omitted.

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 pa…

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.

Re: C++: Zero-cost static initialization

#20

Post by Someone »

ot wrote: post #3

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 Cl…

> That's a nice trick, but contrary to function statics, it is susceptible to SIOF.

For those (like me) who don’t recognize that abbreviation, “The static initialization order fiasco (ISO C++ FAQ) refers to the ambiguity in the order that objects with static storage duration in different translation units are initialized in” (https://en.cppreference.com/w/cpp/language/siof.html)

Post reply on HN