Support for mcfgthreads?

[WardBrian]

I work on a project that needs to ship C++ toolchains to users, and I'm excited to try w64devkit as an option. This project also relies heavily on thread-local variables in some situations, which means we have observed dramatic speed differences (in the ballpark of 2x) between winpthreads and other implementations like mcfgthread (or clang-cl using native Windows threading code)

I'm frankly not terribly familiar with the technical details (such as if it is possible to support both winpthreads and mcfgthreads in the same distribution), but there might be more information in issues like this one against msys

[Peter0x44]

#70 covers it. Maybe look at that.
Building your own w64devkit with it should not be difficult.

[Peter0x44]

mcfgthreads seems to require windows 7+. So at best it could only be an option for the x64.

[Peter0x44]

@lhmouse already distributes toolchains with mcfgthreads so the easiest option is to probably use one of those.
https://gcc-mcf.lhmouse.com/

[lhmouse]

In order to improve performance about thread_local, it is recommended to switch to native TLS. It's still incomplete in GCC 16 (not released yet) so requires some patches. After applying these, it can be enabled by configuring GCC with --enable-tls:

• https://github.com/lhmouse/MINGW-packages/blob/archives/2025-08-20/mingw-w64-gcc/9002-native-tls.patch (committed in GCC 16)
• https://github.com/lhmouse/MINGW-packages/blob/archives/2025-08-20/mingw-w64-gcc/9003-libstdc-Avoid-thread-local-states-for-MCF-thread-mod.patch (not upstreamed yet)

I have more patches on mingw-w64-crt which improve standard conformance.

[skeeto]

That msys2 discussion is very informative about the trade-offs, so thanks for sharing it. It's no secret winpthreads performance is not what it should be, and the problems are obvious from reading its source, e.g. all locking passes through a global lock. Even its spinlocks are UB and rely on TU isolation and break in LTO builds. These issues are due to its age, predating the tools we take for granted, but on the other hand it's also why it still works in XP. Though winpthreads clearly has battle scars from lots of use, and so it gets important, subtle details right, e.g. fixing the stack alignment in the _beginthreadex callback (I see mcfgthreads gets this right, too, via __MCF_REALIGN_SP!), which is why, despite the problems I see in the source, I trust it's not broken in practice, just slow.

Keeping winpthreads for x86 but switching to mcfgthreads for x64 seems like it might be a good idea. Except, as noted in the msys2 thread, the primary goal of mcfgthreads appears to be supporting C++ threading (gthread interface), not providing pthreads. The latter is important to me because, due to my personal C bias, I want pthreads-using programs to work, too. So the trade-off is significantly better C++ standard library thread performance (beating SRW is impressive, as SRW is itself really, really good) at the cost of losing pthreads (at least beyond simple use?). Or maybe it's possible to have both: winpthreads for C, mcfgthreads backing libstdc++?

It's unclear how this affects OpenMP, which is also important. (I like to use it myself!) Perhaps @lhmouse can shed light on that? I suspect implementing the gthread interface is enough to get OpenMP, and so it should work.

My core dislike with this trade-off is that it punishes well-written programs in order to improve performance of mediocre programs. What do I mean? A well-written program does not rely on standard library routines in its performance-critical sections. That would mean the performance of your program is no longer in your control, but in the hands of someone who isn't solving your particular problem. You can solve it better yourself, not because you're smarter but because you know your own context. The library solves the general problem with different constraints, and you can nearly always beat it by exploiting your local context. So a C program that doesn't have pthreads in its hot spots (i.e. winpthread performance doesn't matter) breaks so that a C++ program relying too much on libstdc++ is faster, while not still not as fast as it could be had it been written more thoughtfully (in which case switching to mcfgthreads wouldn't matter).

it is recommended to switch to native TLS

Thanks, @lhmouse! That's really interesting. The TLS situation in the mingw ecosystem has been disappointing, and so I happy to see this. In general mcfgthread looks better and better the more I zoom into the details. Aside from my wish to support pthreads, it seems like the obvious choice for the x64 toolchain.

[lhmouse]

In libgomp source, it contains direct references to pthread functions and types and doesn't call them through gthread wrappers, so it requires winpthread, at least for now.

As for native TLS, changing it is an ABI break; but if everything is to be built from source and linked statically, then it's likely fine.

[Peter0x44]

@skeeto if you can merge #292 I am happy to throw up a branch with mcf that any interested parties can download straight from GitHub actions.