per-CPU Caches

[n1ght-hunter]

I was just looking through the code base and was thinking would any of the thread local's benefit from per cpu caches instead of per thread? This would of course only apply on Linux as i don't think any other os's support it. it may not be worth it though since rayon is mostly used which means you normally have the same number of threads as cpus which means there is no memory benefit. But i believe it can be faster then thread locals due to cache line contention.

more info here on what i mean.
https://google.github.io/tcmalloc/rseq.html

[davidlattimore]

Interesting. The only place in the linker itself where I can think that we've used a thread local is in the linker plugin support and that was just to work around awkwardness of the linker plugin API. Linker plugins are super slow regardless of what you do, so there probably isn't really scope for improvement there. Which thread locals do you mean?

[n1ght-hunter]

String merging was the main one i noticed and possibly TRACE_STACK in linker diff. This was an awareness issues which may be completely impractical as i haven't looked into the thread locals in depth.

[davidlattimore]

Linker-diff isn't especially performance critical, so I wouldn't both with it. You're right, I'd forgotten I was using a thread local in string merging.