Conversation
ctk21
left a comment
There was a problem hiding this comment.
I haven't spent quality time reviewing the underlying data structure (which looks interesting and worthwhile).
However there are a couple of problems with the work distribution; these could be easily fixed by using domainslib's parallel_for.
I would also recommend increasing the benchmark size; looking at scaling up above 16 domains when the runtime is already 0.7s might get quite noise.
I'd be interested if that improves the scaling you see.
| @@ -0,0 +1,27 @@ | |||
| let threads = int_of_string Sys.argv.(1) | |||
| let insert_percent = int_of_string Sys.argv.(2) | |||
| let num_opers = int_of_string Sys.argv.(3) / threads | |||
There was a problem hiding this comment.
There will be settings of Sys.argv.(3) and threads where the total number of operations is not the same between runs.
e.g. Sys.argv.(3) = 100 and threads=128
Better to use parallel_for in domainslib.
| | 0 -> [] | ||
| | _ -> (Domain.spawn work) :: spawn_thread (n-1) | ||
| in | ||
| let threads = spawn_thread (threads - 1) in |
There was a problem hiding this comment.
Might be better to use domainslib parallel_for if you want scaling beyond 16-32 cores.
|
Thank you for the review. I will get to it this weekend and resolve the issues, so that we can hopefully add it to the sandmark testsuite. |
0d50936 to
7919791
Compare
|
Hey @anmolsahoo25, lockfree might be a good place for the lockfree map. Feel free to submit a patch! |
|
Thanks @Sudha247 , will do! :D |




This patch implements a lock-free map using tries. The design is inspired by this paper - Link.
This benchmark is a decent mix between domains performing work, synchronization via CAS and garbage collection. Preliminary results on my laptop seemed to produce speedups, but testing on IITM machines is producing a slowdown, as cores are added. Debugging before merge.