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
sticky: fix extreme edge case for complex balancing
I've been trying to trigger this edge case since I first thought of the
complex balancing: this was the original purpose of the "odd pyramid"
test case.
It is possible for a series of steals to result in one member being
stolen from, only for it to need to steal partitions back from the
original stealing member.
This can be triggered in the new test added for this commit. Since
iteration order is hard / impossible to guarantee, to explicitly trigger
this behavior, you would need to add a sort when balancing such that the
min member chosen to balance to is always chosen in alphabetic order.
If that is done, then B steals from A, only for A to later steal from B.
The problem this triggers is that when A steals back from B, it can
steal a different partition than the one it lost. If the original one it
lost was one it was consuming prior, we lose some stickiness.
A fix for this is to, when stealing, prefer partitions that a member
originally owned.
To do this, we keep track of the original owner, but that alone is not
enough. We must also **prefer** search paths that steal back to original
owners. The original-owner search path could actually have a longer
distance than otherwise, so we now have to fix the heap when we update a
search path.
There are some more comments within the commit that hopefully explains
this a bit more fully. This commit closes out the last aspect of the
graph search that has been on my mind for some time. I'm hoping that
this addresses the final aspect of path finding & stealing such that the
algorithm is now perfect, but it's difficult to say and realistically I
would need to prove the algorithm to be sure (which would be rather
difficult for me).
Realistically, no join pattern would actually trigger this behavior, but
I'm happy that it's addressed.
There is a bit of slowdown due to having one more comparison when heap
searching, as well as from the slightly larger allocation.
name old time/op new time/op delta
Large-8 2.14ms ± 0% 2.13ms ± 1% ~ (p=0.156 n=9+10)
LargeWithExisting-8 8.65ms ± 1% 8.67ms ± 1% ~ (p=0.353 n=10+10)
LargeImbalanced-8 2.89ms ± 3% 3.00ms ± 6% +3.86% (p=0.001 n=9+9)
LargeWithExistingImbalanced-8 8.75ms ± 0% 8.79ms ± 1% ~ (p=0.065 n=9+10)
Java/large-8 160ms ± 1% 160ms ± 1% ~ (p=0.393 n=10+10)
Java/large_imbalance-8 193ms ± 3% 197ms ± 4% +2.29% (p=0.043 n=10+10)
Java/medium-8 8.82ms ± 1% 8.98ms ± 2% +1.85% (p=0.000 n=10+10)
Java/medium_imbalance-8 10.4ms ± 2% 10.8ms ± 1% +4.17% (p=0.000 n=10+10)
Java/small-8 6.80ms ± 2% 7.00ms ± 2% +2.98% (p=0.000 n=10+10)
Java/small_imbalance-8 8.32ms ± 2% 8.72ms ± 3% +4.85% (p=0.000 n=10+10)
name old alloc/op new alloc/op delta
Large-8 1.92MB ± 0% 1.96MB ± 0% +2.57% (p=0.000 n=9+10)
LargeWithExisting-8 3.69MB ± 0% 3.74MB ± 0% +1.39% (p=0.000 n=10+10)
LargeImbalanced-8 2.12MB ± 1% 2.17MB ± 1% +2.51% (p=0.000 n=10+10)
LargeWithExistingImbalanced-8 3.72MB ± 0% 3.77MB ± 0% +1.30% (p=0.000 n=10+10)
Java/large-8 127MB ± 0% 129MB ± 0% +1.58% (p=0.000 n=9+8)
Java/large_imbalance-8 131MB ± 0% 133MB ± 0% +1.54% (p=0.000 n=9+9)
Java/medium-8 7.78MB ± 0% 7.88MB ± 0% +1.26% (p=0.000 n=10+10)
Java/medium_imbalance-8 8.05MB ± 0% 8.16MB ± 0% +1.32% (p=0.000 n=10+10)
Java/small-8 6.20MB ± 0% 6.28MB ± 0% +1.32% (p=0.000 n=10+10)
Java/small_imbalance-8 6.42MB ± 0% 6.51MB ± 0% +1.38% (p=0.000 n=10+7)
name old allocs/op new allocs/op delta
Large-8 335 ± 0% 335 ± 0% ~ (p=0.429 n=6+10)
LargeWithExisting-8 18.6k ± 1% 18.6k ± 0% ~ (p=0.739 n=10+10)
LargeImbalanced-8 786 ± 5% 786 ± 4% ~ (p=0.870 n=10+10)
LargeWithExistingImbalanced-8 18.4k ± 0% 18.4k ± 0% ~ (p=0.518 n=10+7)
Java/large-8 6.04k ± 0% 6.04k ± 0% ~ (all equal)
Java/large_imbalance-8 7.43k ± 0% 7.42k ± 0% ~ (p=0.072 n=9+8)
Java/medium-8 3.03k ± 0% 3.03k ± 0% ~ (all equal)
Java/medium_imbalance-8 3.15k ± 0% 3.15k ± 0% ~ (p=0.322 n=10+10)
Java/small-8 2.46k ± 0% 2.46k ± 0% ~ (p=0.591 n=10+9)
Java/small_imbalance-8 2.55k ± 0% 2.55k ± 0% ~ (p=0.232 n=10+9)
0 commit comments