[
https://issues.apache.org/jira/browse/LUCENE-5236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13933030#comment-13933030
]
Sebastiano Vigna commented on LUCENE-5236:
------------------------------------------
Sorry.
http://vigna.di.unimi.it/Sux/select.php
No, as I wrote the select-in-a-word code is the one in it.unimi.dsi.bits.Fast
(DSI utilities). Looping to select works only on very sparse words, and
Elias-Fano upper bits are about half zeroes and half ones (or about two thirds
zeroes and one third ones, for unshifted strictly monotone sequences).
That might change if Oracle give us intrinsified Long.clearLowestBit(). Some
tests on Philip Prunin Facebook's code show that his simple strategy (use
popcount to decide whether to select in the upper or lower half, and then loop)
can be competitive if you have one-clock deletion of the lowest bit.
In any case, we're talking about shaving 0.5 ns from the final phase of a
search. Maybe that's overengineering LOL.
BTW, in principle it could be possible to fix the problem with
non-intrinsifying JVMs by using some replacement tricks like those used for
running Java 6 code on Java 5 (e.g., retroweaver). It should be possible to
have bitCount() running the broadword algorithm at no cost.
> Use broadword bit selection in EliasFanoDecoder
> -----------------------------------------------
>
> Key: LUCENE-5236
> URL: https://issues.apache.org/jira/browse/LUCENE-5236
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Paul Elschot
> Assignee: Adrien Grand
> Priority: Minor
> Fix For: 4.6
>
> Attachments: LUCENE-5236.patch, LUCENE-5236.patch, LUCENE-5236.patch,
> LUCENE-5236.patch, TestDocIdSetBenchmark.java
>
>
> Try and speed up decoding
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
