On Wed, Jul 24, 2019 at 6:05 PM Zihan Yang <whois.zihan.y...@gmail.com> wrote:
> I should have said that my evaluation is just self-written cycle > measurement, which is very rough and lack of repeated experiment. So the > factor number might be different in your case. But the contention for the > single sync.Mutex really hinders the performance in my case. > > A long shot, but maybe worth trying: If the lock is the contention point, you create N locks, preferably one per core, making sure they are not in the same cache line. Read locking is now "pick random lock, and grab it". Write locking is "pick every lock in the same order for exclusive access". Or "hash the key, select randomly from H, H+1, H+2" and so on. This avoid the single lock contention for a high-core case. But it trades that for more expensive inserts. Of course, having a "per-P" lock would be more efficient, but this converges toward the idea. So if there is a benefit, it is likely to show up. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAGrdgiW%2BqiwccrwakDxy4xZ-dY%3DchwQZQ9_wv2Z%2Bxc9-Sbt__A%40mail.gmail.com.
