Closed WaDelma closed 7 years ago
I guess you did not git add
the new file. Also, we might also just have a par_iter
file to keep the file tree flat.
Which file is missing? I don't see it. Tests seem to fail to stack overflow...
The BitParIter
needs access to BitIter
private fields, so it cannot be flattened (without pub(restrict)).
Now it's there! Hm, seems the recursion is too deep / does not end?
I cannot reproduce it locally and can't tell from the output which test overflowed.
I do no recursion on my end, so the recursion is happening in rayon I think. I have debug it more deeply, but my first guess is that I am splitting too many times (or infinitely).
I also realized yesterday that I am using 32bit rust on my computer (I tried to install 64bit version, but trying to rustup run cargo test
with that toolchain results into infinite recursion‽), so that's probably the difference between travis and local test.
I was able to test it with 64bit rust and couldn't reproduce stack overflow with it either... I even tried test where I fill whole bitset with ones and it still didn't overflow.
So I have no clue what is wrong and now it goes through travis too.
Well, this is unsettling. I'll try to make a close look at the logic then to spot a potential error. Edit: Also, thank you for addressing my comments! I know it's not the easiest PR ever. Given that the crate is rather fundamental and low level, we can't take much risks.
Well I don't expect this getting merged anytime soon: When I started it I had no clue how it would work and I am not 100% confident it's correct now.
Welp... I started to add those asserts you wanted and I actually realised that there is huge oversight: When there is only one bit left descending to the next layer doesn't actually work as the lower levels mask is never set to anything but 0. This means that it couldn't actually split more finely than for the highest level.
When I fixed that I ran into more problems. One of them is that the avarage is rounded down which meant that sometimes it thought that it could split, but splitting actually didn't change anything and there was infinite recursion. After that it still runs to problem that I haven't yet debugged.
I should really look into making the tests better. Biggest problem with them is that it uses the machinary of the normal iterator which masks these kinds of problems as the iteration is still correct, but not split enough.
This PR and the one in specs has turned into quite an adventure :D
@WaDelma IIRC the logic should work now? Would you please rebase onto the latest master?
AFAIK it should work correctly now. I rebased it.
@WaDelma Great, thanks! I couldn't spot any stylistic or doc issues, and I'd rather delegate reviewing the logic to @kvark
Really amazing work here!
@torkleyy I somewhat reviewed it once more. It would be best to have @csherratt glancing at the code. If they don't make it, we can merge and then fix post-release, given that the API will not change. After all, this is an extra feature, not a change in existing logic.
This is seriously cool. I don't see anything I object to in the implementation.
But I would ask that we add a few more targeted tests. All of the tests will tend to fill the tree and maybe leave some empty spaces, even the random number one has no guarantee of this. It would be good to see entire leafs that were empty to make sure there isn't some ugly edge case we overlooked.
Something like this: https://play.rust-lang.org/?gist=387d26b94a6b3cddcd2eb4ff085a4d7e&version=stable&backtrace=0
That should generate clusters of keys that don't completely fill the l3/l2 nodes.
@csherratt thanks for expertise! I hope you'll join us on Gitter, like the olde good times ;)
Added the clustered test. Any other ideas for tests?
Thanks @WaDelma !
Should propably add benchmarks for it.
slide-rs/specs#120