Fence ArborX calls in the benchmark and (optionally) DBSCAN #450
Conversation
It may happen that the last kernel in ArborX is a Kokkos::parallel_for. As ArborX does have a guaranteed fence() at the end, what could happen is that that kernel is launched, and ArborX returns. Thus, when the ending timer is called, the kernel has not been completed yet. Thus, the measured time would be wrong in this case.
|
The reason why I also added fences prior to ArborX calls in the loop is to make sure that if now or in the future we add some setup inside the loop, it does not creep in the timers. |
|
This PR also fixes #446, as a side effect. It is still not clear what caused that hanging, though. A guess could be that in this mode we issued too many kernel launches (essentially, we continuously issued launches in the loop), and something happened when we issued too many of them. |
|
So far, I have not observed any significant changes to timings on my workstation, but I've launched some jobs on Summit for observation. |
|
There's no difference on Summit, either 🤷 |
aprokop
changed the title
aprokop
force-pushed
the
benchmark_fences
branch
from
1053e07
to
27eea17
Compare
|
Anything else you guys want to be addressed here? |
It may happen that the last kernel in ArborX is a Kokkos::parallel_for.
As ArborX does have a guaranteed fence() at the end, what could happen
is that that kernel is launched, and ArborX returns. Thus, when the
ending timer is called, the kernel has not been completed yet. Thus, the
measured time would be wrong in this case.