Simple64 - #16245
Conversation
vsop-479
added
the
skip-changelog
|
This change has passed the core tests. And I measured its performance: When suffix lengths are small (1~8), each value fits in a single VInt byte, making VInt extremely fast due to near-perfect branch prediction. Simple64 is slower in this case (~1.6x disadvantage). When suffix lengths are larger (1~200), some values spill into two VInt bytes, causing branch mispredictions. Simple64 pulls ahead here (~1.3x advantage) since it uses pure bitwise operations with no branching. For typical BlockTree suffix lengths (1~15), values stay within the single-byte VInt range, so VInt is likely faster in practice. Simple64's main benefit in this scenario is compression ratio rather than decode speed — it uses roughly half the bytes of VInt for small integers. |
suffix length: 1 ~ 8 integerssuffix length: 1 ~ 200 integers |
|
This PR has not had activity in the past 2 weeks, labeling it as stale. If the PR is waiting for review, notify the dev@lucene.apache.org list. Thank you for your contribution! |
|
After unrolling, Simple64 decode beats VInt across SMALL_1_8, MID_1_64, and LARGE_1_200, with the gap much larger on LARGE_1_200 (~ +47%) than on SMALL_1_8/MID_1_64 (~ +1-8%)： |
|
@mikemccand Please take a look when you get a chance -- there are TODOs mentioning |
|
Thanks @mikemccand for the detailed review and all the suggestions. I pushed updates addressing the comments.
Yes, this change does add allocations for simple64 decoding (but it no longer uses
I looked around but did not find a mature, reasonably licensed Simple64 implementation. |
|
@mikemccand I ran luceneutil on Note: the two indexes did not end up with the same segmentlayout. The baseline has 23 segments( search perfsearch gc stats
Indexing stats
Note: the final segment layout differs between the two runs, so the indexing throughput comparison may include merge/segment-layout effects in addition to the codec change. tim store
|
I will try to implement decoding a single int from one long, instead of decoding all ints from that long. |
Maybe rerun with single segment (force merge to 1)? At least then the results are comparable to one another, though less realistic for near-real-time cases. |
|
Thanks @vsop-479 I'll try to have another look hopefully next few days. |
+1, I think the difference in segments counts comes from the fact that we create baseline index with I will add the same args to |
After setting search perfsearch gc stats
Indexing stats
tim store
|
I implemented decoding a single int from one long, to instead of decoding all ints from that long. When decoding a single int, Simple64 may not have an advantage over VInt for values below 128 (1-byte). Simple64 is more likely to help when the value is above 127 (multi-byte). |
|
Performance fo decoding a single int |
|
@mikemccand I have another idea: |
2 participants
Description
Simple64: pack multiple small non-negative integers into a single long.
This change try to implement Simple64 to bulk encode/decode small ints, and use it to write terms' suffixLengths or somewhere else.