On 5/14/06, eks dev <[EMAIL PROTECTED]> wrote:
It is faster than BitSet, even against Mustang. The numbers are a bit less than on Yonik's HW, but quite convincing.
The level of outperformance isn't quite as high on my work box, I think because my home machine has higher memory bandwidth (both P4's but mine has dual channel PC3200)
I did small test on my XP Notebook (Pentium M 1.6GHz). Only "union" test is some 20% slower on 8Mio size with 80k bits set. I did not dig deeper.
Weird... I'm not sure how that could be. Are you sure you didn't get the numbers reversed? I just tried 1.6, and bitset/openbitset = 1.26 for me. Are any memory controllers optimized for forward streaming more than reverse? My union loop counts down to zero, which is often faster since the register status flags are already set as the result of the decrement operation (hence avoiding an additional compare instruction on most processor architectures, including x86). $ c:/opt/jdk16/bin/java -version java version "1.6.0-beta2" Java(TM) SE Runtime Environment (build 1.6.0-beta2-b83) Java HotSpot(TM) Client VM (build 1.6.0-beta2-b83, mixed mode, sharing) [EMAIL PROTECTED] /cygdrive/f/code/solr/classes $ c:/opt/jdk16/bin/java -server -Xbatch org.apache.solr.util.BitSetPerf 1000000 50 10000 union 3000 bit ret=0 TIME=13203 [EMAIL PROTECTED] /cygdrive/f/code/solr/classes $ c:/opt/jdk16/bin/java -server -Xbatch org.apache.solr.util.BitSetPerf 1000000 50 10000 union 3000 open ret=0 TIME=10406
As you all know Big majority of bit vectors usually met in practice
are very to modestly
sparse due to Zipf…
Yeah, that's why I concentrated on performance of the dense bit sets... when the set is sparse, bit sets take up too much room and something else should be used anyway. -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
