New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Iterative comparisons #85
Conversation
Also remove the dead _compare_object().
This reverts commit 7293476. This slowed down dletablue and made no differenceto richards.
Tiny speedup in deltablue.
No functional change.
This gives roughly a 5% speed increase on DeltaBlue.
Beef up the explanation for what's going on, as otherwise the code makes very little sense.
This and the previous commit speed up object comparison by almost 16x.
Means we don't allocate or iterate over another list.
This reverts commit 788359d. This won't work, as object comparisons need to happen left to right.
No functional change.
This also opens up a couple of opportunities to bypass redundant identity checks.
I got this wrong. We want to inline hippy's default instance object comparison, but allow subclasses to override it. This mechanism is a simpler version of UseFastComparison, but achieves the same effect.
Previously this meant that when we hit the slow case, we needlessly redid all the fast work that we'd already done. This gives about ~8-9% speedup on Deltablue.
We rely on the fact that typically objects of the same type will return attributes in the same order to avoid this.
Often we can expect that their keys follow the same order, which stops us doing lookups in cases where that property holds. Previously, comparisons were particularly annoying as the current array API forced us to do 2 lookups per key on average.
No functional change.
Gives ~4% speedup on Deltablue.
This patch makes two related changes: 1) We only need to push aggregate thingies onto the stack, as we can compare primitive thingies as we're going. If they're definitely equal, they don't need to go on the stack at all. 2) As soon as we encounter primitive thingies which we can tell aren't equal, there's no point pushing anything further onto the stack: what we have will be enough to tell us the answer, so we can then break. Together they give ~17% increase on DeltaBlue.
This allows us to hit all of our fast cases.
The failing tests are orthogonal. See #87. |
Merged the regex fixes. Should now pass. |
The remaining failing test is a cycle test. This was probably passing by luck before, as hippy does not handle cycles properly. I'm inclined to mark it skip until someone addresses cycles. |
I have marked the bug 63882 test as skipped, as discussed above. 4 phpt tests will now fail:
These are failing on master already. |
Hrm, odd -- the tests I expected to fail did not. Must be something to do with our test environment. Unrelated to this pull anyhow. |
I didn't really review it, but the tests seem comprehensive. I'd say go ahead! |
In response to #83, this pull request implements an (optimised) iterative comparison.
Prior to this change, I was unable to run deltablue with a parameter of more than about 1650. Now it runs larger numbers fine.
Below are the results before and after on richards and deltablue. Richards is ever so slightly slower, but deltablue is dramatically faster (on par with the same benchmark in python running under pypy).
Note that our method _compare() is not being compiled, probably due to the loop. @cfbolz suggested to add a jit merge point for this loop. This should be a separate unit of work.
Note that hippy does not deal with comparison cycles very well. I will raise an issue for this.
Sorry about the large number of commits, it has been quite a journey, with the algorithm evolving over time.
This needs to be carefully reviewed.