aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/CodeGen/MachineModuleInfo.cpp
diff options
context:
space:
mode:
authorEric <eric@efcs.ca>2024-04-13 03:16:11 -0400
committerGitHub <noreply@github.com>2024-04-13 03:16:11 -0400
commit11f22f1a963ab3c8949cb723a63c07d7a409c8a8 (patch)
tree257709dccd655f68bb84255e180aa49929ec4d73 /llvm/lib/CodeGen/MachineModuleInfo.cpp
parent6d66db3890a18e3926a49cbfeb28e99c464cfcd5 (diff)
downloadllvm-11f22f1a963ab3c8949cb723a63c07d7a409c8a8.zip
llvm-11f22f1a963ab3c8949cb723a63c07d7a409c8a8.tar.gz
llvm-11f22f1a963ab3c8949cb723a63c07d7a409c8a8.tar.bz2
[tzdb] Replace shared_mutex with mutex. (#87929)
The overhead of taking a std::mutex is much lower than taking a reader lock on a shared mutex, even under heavy contention. The benefit of shared_mutex only occurs as the amount of time spent in the critical sections grows large enough. In our case all we do is read a pointer and return the lock. As a result, using a shared lock can be ~50%-100% slower Here are the results for the provided benchmark on my machine: ``` 2024-04-07T12:48:51-04:00 Running ./libcxx/benchmarks/shared_mutex_vs_mutex.libcxx.out Run on (12 X 400 MHz CPU s) CPU Caches: L1 Data 32 KiB (x6) L1 Instruction 32 KiB (x6) L2 Unified 1024 KiB (x6) L3 Unified 32768 KiB (x1) Load Average: 2.70, 2.70, 1.63 --------------------------------------------------------------------- Benchmark Time CPU Iterations --------------------------------------------------------------------- BM_shared_mutex/threads:1 13.9 ns 13.9 ns 50533700 BM_shared_mutex/threads:2 34.5 ns 68.9 ns 9957784 BM_shared_mutex/threads:4 38.4 ns 137 ns 4987772 BM_shared_mutex/threads:8 51.1 ns 358 ns 1974160 BM_shared_mutex/threads:32 57.1 ns 682 ns 1043648 BM_mutex/threads:1 5.54 ns 5.53 ns 125867422 BM_mutex/threads:2 15.5 ns 30.9 ns 21830116 BM_mutex/threads:4 15.4 ns 57.2 ns 12136920 BM_mutex/threads:8 19.3 ns 140 ns 4997080 BM_mutex/threads:32 20.8 ns 252 ns 2859808 ```
Diffstat (limited to 'llvm/lib/CodeGen/MachineModuleInfo.cpp')
0 files changed, 0 insertions, 0 deletions