5 ms·
So this was only a MSVC bug? Most people compile Pd with MinGW, which would explain why we never ran into this issue. Do you happen to have a link to the origi
by spacechild1 2y ago
So this was only a MSVC bug? Most people compile Pd with MinGW, which would explain why we never ran into this issue.
Do you happen to have a link to the original MSVC bug report (i.e. the wrong thread locals, not the performance regression)?
- legobmw99 2y agoNote that MinGW uses libwinpthread, which is known to have slow TLS behavior anyway (I've observed a 100% overhead compared to running the same program under WSL using a linux-native GCC). c.f. https://github.com/msys2/MINGW-packages/discussions/13259 https://github.com/msys2/MINGW-packages/discussions/13259
- malkia 2y agoI haven't looked into it, but going through the release notes for tlsGuards showed this - though not directly a bug report https://learn.microsoft.com/en-us/cpp/overview/cpp-conformance-improvements-2019?view=msvc-170#tls-guard-changes https://learn.microsoft.com/en-us/cpp/overview/cpp-conforman... and also the implementation in "clang" (for "clang-cl" being conformant with MSVC) - https://reviews.llvm.org/D115456#3217595 https://reviews.llvm.org/D115456#3217595 then last year clang-cl also added ways to disable this (if need to), probably this hit some internal issue and had to be resolved. Maybe "thread_local" have become more widely used (unlike OS specific "TlsAlloc")
- spacechild1 2y agoThanks! Fortunately, this issue does not affect us because our thread locals are all zero initialized integers or pointers.