0+0 > 0: C++ thread-local storage performance - comments

octordle

octordle — Thu, 12 Feb 2026 01:00:52 +0000

The alternative would be to use "ADD/SUB RSP, 8" but those take 4 bytes while PUSH/POP are 1 byte only and execute just as fast.

F16

F16 — Thu, 22 Jan 2026 15:44:08 +0000

Two workarounds:

On x64 Linux, the %gs register is free. Put your own TCB there. Initialize with arch_ptrctl(ARCH_SET_GS) on thread start.
On ARM64 Linux you don't have userspace access to a secondary thread-local register. In this case, put an inital-exec thread local in the top-level executable file. Compute an offset of this variable from the TCB. Pass that offset into your library's init function. This offset is negative on x64 and positive on ARM.
Compiler Explorer: https://godbolt.org/z/1vfzro3oP

slope 2

slope 2 — Sun, 07 Dec 2025 23:38:45 +0000

they could just as well LD_PRELOAD the shared library… though I suppose there are scenarios where using the tunable ends up being the cleaner approach.

Joker_vD

Joker_vD — Tue, 11 Mar 2025 00:32:58 +0000

Well, that orange-coloured code is not really about spilling and restoring registers, nothing touches RBP in the between and it's a call-preserved register anyway. It's about maintaining the proper stack alignment: you see, Linux's ABI on x64 mandates that before doing a CALL, the stack must be aligned at 16 bytes, but since a CALL naturally ruins this property, every non-leaf function has to push and pop an odd number of registers in its prologue/epilogue, RBP being particularly popular for this purpose. The alternative would be to use "ADD/SUB RSP, 8" but those take 4 bytes while PUSH/POP are 1 byte only and execute just as fast.

Yossi Kreinin

Yossi Kreinin — Wed, 19 Feb 2025 11:03:19 +0000

You're right, though I guess if you can have the user set this "tunable" via an env var, you can usually also have them LD_PRELOAD the shared library?.. But maybe in some cases the tunable is the better way

Aaron Puchert

Aaron Puchert — Tue, 18 Feb 2025 13:01:39 +0000

You have already mentioned the initial-exec model and how it is constrained by the static TLS reserve in case of dlopen. This reserve seems to be configurable in glibc via the tunable glibc.rtld.optional_static_tls.

Yossi Kreinin

Yossi Kreinin — Tue, 18 Feb 2025 07:17:19 +0000

@billythefisherman: I endorse this scheme and it's consistent with the guidelines above; though making the structure thread_local is probably faster most of the time (with the colorful exception of it being more likely to fail under -ftls-model=initial-exec if your shared library is neither LD_PRELOADed nor DT_NEEDED)

@Daniel Cranford: even without symbol interposition, you will get calls to __tls_get_addr, though you will get less such calls, hopefully one per function with a recent clang on x86 (I updated the post with some details of what hidden visibility (which precludes interposition) does to code generation based on input from the same MaskRay whose writing you're linking to; not sure if you commented before this update or not, quite possibly it was before.) If this was just about interposition, then with hidden visibility you wouldn't need __tls_get_addr (and a lot of work was put in by (some of the) compiler writers to use less __tls_get_addr calls given hidden visibility; had they been able to avoid calling it completely, I'm sure they would.)

So I maintain that this is first and foremost the result of TLS being allocated non-contiguously by libc and the resulting need to find out the module base pointer before you can add the offset to it.

billythefisherman

billythefisherman — Mon, 17 Feb 2025 23:17:52 +0000

Just put a single u64 into thread local storage and have it point to a structure that contains all your thread local stuff. No need for multiple thread local objects etc. This scheme has worked for me over the years at least but maybe Im missing the requirements above?

Daniel Cranford

Daniel Cranford — Mon, 17 Feb 2025 16:07:52 +0000

The reason the dynamic linker does not (and can not) compute a simple offset for the tls storage in the shared object case is the fault of something called "elf symbol interpositition". The default flags on the linker make every symbol in an .so potentially replaceable by another .so loaded into the process, and so every function call and (static) variable access is indirectly through the global offset table.

See https://www.facebook.com/story.php?story_fbid=10107358290728348&id=15706763 and https://maskray.me/blog/2021-05-16-elf-interposition-and-bsymbolic