You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So here the neighbor counting is the same time, but the query is 13% slower.
In fact, when using the standard benchmark, it is almost always either the same, or slower for Cuda, with a couple benchmarks up to 50% slower.
I don't understand this at all. It boggles my mind that some simple changes in intersect implementation could have such a disproportionate effect on the overall time.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I've been playing around with
intersects(Sphere, Box)
and observed a weird behavior.I've been trying to use a (modified) Jim Arvo's algorithm. Something like this patch (diff to fb59980):
I've been running it on A100 using FDBSCAN with 37M HACC data. When running
minPts = 2
, it is much faster than original:So the query is 27% faster. However, running
mintPts = 5
, the situation is reversed:So here the neighbor counting is the same time, but the query is 13% slower.
In fact, when using the standard benchmark, it is almost always either the same, or slower for Cuda, with a couple benchmarks up to 50% slower.
I don't understand this at all. It boggles my mind that some simple changes in intersect implementation could have such a disproportionate effect on the overall time.
Beta Was this translation helpful? Give feedback.
All reactions