Scalable barrier #2321
Scalable barrier #2321
Conversation
# Conflicts: # hpx/runtime/agas/component_namespace.hpp # hpx/runtime/agas/primary_namespace.hpp # hpx/runtime/agas/symbol_namespace.hpp # src/runtime/agas/addressing_service.cpp # src/runtime/agas/detail/bootstrap_component_namespace.cpp # src/runtime/agas/detail/bootstrap_locality_namespace.cpp # src/runtime/agas/detail/hosted_component_namespace.cpp # src/runtime/agas/primary_namespace.cpp # src/runtime/agas/server/primary_namespace_server.cpp # src/runtime/agas/symbol_namespace.cpp # src/util/logging.cpp
|
The config settings need to be added to the docs, still. |
hkaiser
force-pushed
the
scalable_barrier
branch
from
270bbd4
to
dd3af7a
Compare
The barrier was implemented using a K-ary tree approach with the algorithm as presented here: http://www.cs.fsu.edu/~asriniva/papers/HiPC15.pdf The arity is configurable through hpx.lcos.collectives.arity and the cut off when to switch to the tree based algorithm is hpx.lcos.collectives.cut_off.
- flyby: adapt to new sync/async API - making things compile for MSVC - adding missing headers - removed old barrier component
sithhell
force-pushed
the
scalable_barrier
branch
from
c03d259
to
f761308
Compare
Those numbers have been determined experimentally on edison
|
Can anyone review this please? |
|
It was not clear to me that the changed boundaries would fix the issue. I think there should be some code checking pre-conditions if the barrier breaks with boundaries set too low. |
|
What do you mean? Which boundaries? The code is fine, the arity and cut off were chosen experimentally to get the best performance. Every value here should work |
|
Sure. I trust the values used as a default now are fine. What I meant was that those values could be changed by the user and as we have seen, providing bad values not only could slow down the execution (I wouldn't care about this case, the user is not supposed to play with those values), but could break the barrier altogether (as the failing test has shown). So what I'd suggest is to add tests verifying that the selected values don't break the barrier functionally. |
|
On Mittwoch, 5. Oktober 2016 11:25:33 CEST Hartmut Kaiser wrote:
The failing test was due to a bug in the algorithm which has been fixed. |
Ok. This was a misunderstanding on my end, then. LGTM, please go ahead and merge it (after resolving the conflicts, that is). |
Conflicts: hpx/lcos/server/barrier.hpp src/lcos/barrier.cpp
This change prevents the condition variable to wait in non HPX thread contexts.
|
The remaining problem has been fixed. |
The barrier was implemented using a K-ary tree approach with the algorithm
as presented here: http://www.cs.fsu.edu/~asriniva/papers/HiPC15.pdf
The arity is configurable through hpx.lcos.collectives.arity and the cut off when
to switch to the tree based algorithm is hpx.lcos.collectives.cut_off.