You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since drwmutex is mainly to improve the performance of read-most workload, use a fast hash function also can distribute the lock evenly, which may help to reduce lock contention.
Benchmark shows cost of runtime.fasthashn is very cheap.
Hmm.. While this would help somewhat, it won't have anywhere near the same scalability as using a core-local lock (which CPUID) gives you. It could be that it's a reasonable fall-back for other platforms for the time being, but at the same time I think I'd prefer to say that this is linux_amd64-only so that people don't depend on the scaling behavior of the CPUID implementations and then get disappointed when they don't get the same behavior on other platforms.
Since drwmutex is mainly to improve the performance of read-most workload, use a fast hash function also can distribute the lock evenly, which may help to reduce lock contention.
Benchmark shows cost of runtime.fasthashn is very cheap.
So is it reasonable to use this rand method to choose read lock on platforms other than linux_amd64?
The text was updated successfully, but these errors were encountered: