[Openmp-commits] [PATCH] D67447: Enable tasks dependencies hashmaps resizing

[Philippe Virouleau via Phabricator via Openmp-commits]

viroulep created this revision.
viroulep added reviewers: AndreyChurbanov, jcownie.
Herald added subscribers: openmp-commits, kristof.beyls.
Herald added a reviewer: jdoerfert.
Herald added a project: OpenMP.

This patch is a follow up to https://reviews.llvm.org/D63196.
In this paper <https://link.springer.com/chapter/10.1007/978-3-319-98521-3_14> (full text <https://hal.inria.fr/hal-01901806/document>) we studied the impact of the dependencies hash table capacity on the performance of one of our applications (see section 3.3, experiments are made using the "jacobi" kernel in the KASTORS benchmark suite <https://gitlab.inria.fr/openmp/kastors>).
We did a breakdown of the task management related task (Figure 3) which showed that a lot of time was spent in the check dependencies part, which we narrowed down to the dependency lookup part.
Statically changing the size proved to be an appropriate quickfix, but it would be nicer to have the hashtables be resized automatically when reaching some threshold.

While simply doubling the hashtable capacity would be a quite easy implementation, it also leads to disastrous collisions statistics (see here <https://gitlab.inria.fr/openmp/experiments-hashmaps/blob/master/miriel/run1/plot_haswell_131_even.pdf> and here <https://gitlab.inria.fr/openmp/experiments-hashmaps/blob/master/arm/plot_arm_131_even.pdf> for some experiments on a 24 core haswell architecture and an arm architecture).
It shows how many buckets have x elements just before resizing the hashtable (I removed the 0 elements bar for visibility, as most buckets are actually empty), which basically shows there are a whole lot of collisions.

So instead I went for an arbitrarily fixed amount of resizing, using prime numbers close to twice the previous capacity.
The buckets distributions for the same application executions (here <https://gitlab.inria.fr/openmp/experiments-hashmaps/blob/master/arm/plot_arm_131_prime.pdf> and here <https://gitlab.inria.fr/openmp/experiments-hashmaps/blob/master/miriel/run1/plot_haswell_131_prime.pdf>) look far better as the majority of the buckets are used and collisions don't go as high as before.

The hashtable resizing is triggered when the total number of conflicts in all buckets exceeds the number of buckets.

By using this resizing mechanic we managed to observe roughly the same performance gains as in the paper, but without having to manually change the hashtable size.


Repository:
  rOMP OpenMP

https://reviews.llvm.org/D67447

Files:
  runtime/src/kmp.h
  runtime/src/kmp_taskdeps.cpp
  runtime/test/tasking/omp_task_depend_resize_hashmap.c

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D67447.219714.patch
Type: text/x-patch
Size: 6328 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/openmp-commits/attachments/20190911/f8de4183/attachment.bin>