Changes

Jump to: navigation, search

GPU621/Analyzing False Sharing

18 bytes removed, 14:48, 30 November 2022
Preface
= '''Preface''' =
In concurrencymulticore concurrent programming, pseudo-sharing if mutual exclusion is equivalent to a "performance killer in multicore concurrent programming", and contention then false sharing is equivalent to a worthy "performance assassin”assassin". Assassins differ from killers because The difference between "killer" and "assassin" is that a killer can be seen easily detected, and foughtwe always have many ways to deal with a killer when we fight it, runsuch as fighting, running away, detoureddetouring, begged and begging for mercy, or be stopped, but a killer cannot be seen and disguisedan assassin is completely different. It is impossible to prevent the "assassin" from lurking Assassins are good at hiding in the shadows and waiting for an opportunity to can strike. We can take a variety of measures (such as shortening the critical areafatal blow at any time, atomic operationswhich makes people defenceless. In our concurrent development, etc.) when we encounter lock contention situations that affects affect concurrency performance in concurrent programming. The code we write does not see pseudo-sharing, so we are unable always have many ways to find it and cannot fix it, so we cannot improve the concurrency performance of the program. We can't make any changes to this, which results But false sharing leaves no trace in pseudo-sharing our code that it is in the "dark, which slows " and seriously slowing down concurrency performance down significantly, making it hard to find the root cause of the problem, let alone fix it.
= '''What you need to know before understanding false sharing''' =
118
edits

Navigation menu