Default shard amount should be proportional to `cores²`

[HKalbasi]

Similar to the birthday problem, the amount of writer threads required to have contention on a map with T shards with high probablity is O(√T). So I propose setting the default number of shards to something proportional to the square of cores, for example cores²/4 or cores²/2 instead of 4*cores. cores²/2 is what I use in my server with 48 cores, but cores²/4 is not that different.

[xacrimon]

Hi! Of course I'm always interested in potential ways to improve the performance of the library for the "average" user. Previously (like 3 years ago) is when I determined the shard scaling algorithm using https://github.com/xacrimon/conc-map-bench.

I'd be happy to rerun and update these and change any info based on the results accordingly if they are generally applicable, if they would change the results in a measurable way. Do you have substantiated and reliable data to show the outcome if I were to change these and why they are to be more consistent than current ones?

[HKalbasi]

Hi! I tested this on my workload, which is not representative of every workload. I will run your bench suit on my server which has 48 cores and share the results.

[ProgramCrafter]

On an eight-core system (a configuration I commonly see), cores^2/2 and cores*4 are exactly same (namely, 32).

@HKalbasi do you have the bench results by any chance?