Cache Issues -- False Sharing -- Mike Bailey, Oregon State University
Why Stack Overflow recommends it
Stack Overflow users link it when explaining or answering questions about false sharing and why parallel code on shared data can run slower than sequential code.
Recommended by 1 people across 1 different months, 2018 to 2020.
What it is
A short university lecture segment by Mike Bailey of Oregon State University explaining false sharing, where threads on different cores slow each other down by writing to variables that share a CPU cache line. It covers how cache lines and coherence work and why this hurts parallel performance.
What people said
Recommends pingsoli · 2018-04 · Stack Overflow · on “What is "false sharing"? How to reproduce / avoid it?”
here [this video] is a video about false sharing, hope that help. I can't add a comment without 50 reputation, It's really awkward.
Cites Humphrey Winnebago · 2018-09 · Stack Overflow · on “Worker Thread permanently hibernates, after executing too fast”
All shared data should be protected by a mutex. The mutex should have (at least) the same scope as the shared data. Your _thread_shouldWork container is shared data. You can make a global array of mutexes and each one can protect its own _thread_shouldWork element. (see note below). You should also have at least as many condition variables as you have mutexes. (You can use 1 mutex with several different condition variables, but you should not use several different mutexes with 1 condition variable.) A condition_variable should protect an actual condition (in this case, the state of an individual element of _thread_shouldWork at any given point) and the mutex is used to protect the variables
Cites Den-Jason · 2020-10 · Stack Overflow · on “c++ std library parallel execution with for_each slower than sequential loop”
I would posit that for a small amount of work it may be the case that a tight loop could execute in one CPU by purely keeping within the L1 cache context. As soon as you increase the amount of parallelism on the same data you begin to invoke overhead with cache consistency and page faults. It would probably be worth you looking at ways of counting cache misses such as those suggested here: Programmatically counting cache faults [LINK] and also see: What is a "cache-friendly" code? [LINK] plus other resources on "cache friendly code" and "data oriented design": [LINK] and [LINK] This is related to false sharing which is explained here: [this video]