[
https://issues.apache.org/jira/browse/LUCENE-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12636685#action_12636685
]
Michael McCandless commented on LUCENE-1410:
--------------------------------------------
bq. A: PFor.getNumFrameBits() does this for a given int[] at offset and size.
Super, I missed that -- I'll use it.
bq. Btw. after decompressing, the things are ints not vInts.
Oh yeah, I'll fix the prints in my test.
bq. There is some fallback code (decodeAnyFrame) that will decompress for any
frame or reference
Right I was wanting the unrolled version to see the fastest result we can get
for pfor, but your next observation is spooky so maybe this isn't really going
to help our test:
{quote}
Btw. on my machine the unrolled 9 bit version is actually a bit slower than the
loop, I don't know why,
maybe there are too many buffer references (9) in the loop for the jit to cope
with.
{quote}
We should look at the asm that's produced?
bq. it's probably the JIT jumping in.
But strangely with -Xbatch I still see the effect. And even stranger, on
another machine (Mac OS X) it gets *slower* when the JIT jumps in. I'm spooked.
bq. Which block size did you use for PFor?
I used 128 but I'll try different sizes.
bq. For practical use, the start of each compressed block must be known, either
from somewhere else, or from the size of the previously encoded block.
But can I also get the "bytes consumed" when I ask decompress() to
run?
When we really integrate, things like term infos and skipping data
will know how to jump to the start of blocks. But for raw sequential
scanning, if the header is self-punctuating we would not need to store
the block size between each block.
> PFOR implementation
> -------------------
>
> Key: LUCENE-1410
> URL: https://issues.apache.org/jira/browse/LUCENE-1410
> Project: Lucene - Java
> Issue Type: New Feature
> Components: Other
> Reporter: Paul Elschot
> Priority: Minor
> Attachments: LUCENE-1410b.patch, TestPFor2.java
>
> Original Estimate: 21840h
> Remaining Estimate: 21840h
>
> Implementation of Patched Frame of Reference.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
