[erlang-questions] A bug? - bloom filters - and loadable BIFs

[Mikael Pettersson]

Steve Kirsch writes:
 > I've tried that and you still get about 100% storage overhead.
 > 
 > So what is the undocumented BIF? 
 > 
 > -----Original Message-----
 > From: Bjorn Gustavsson [mailto:bgustavsson@REDACTED] 
 > Sent: Thursday, April 30, 2009 12:14 AM
 > To: Steve Kirsch
 > Cc: Mikael Pettersson; Joe Armstrong; Erlang
 > Subject: Re: [erlang-questions] A bug? - bloom filters - and loadable BIFs
 > 
 > On Wed, Apr 29, 2009 at 8:09 PM, Steve Kirsch <steve.kirsch@REDACTED> wrote:
 > > Great, that explains the crash.
 > >
 > > All your caveats are duly noted. We promise to be careful.
 > >
 > > So now can you tell us how to use these functions that are already 
 > > there?
 > >
 > 
 > Maybe you should first try the suggestion by Paulo Almeida above? That is, use an array (as provided by the 'array' module) to store big integers in.
 > For instance, each entry in the array could could store an integer that can hold 256 bits. That would most definitely be an improvement over using binaries and might work good enough to work in your application.

hipe_bifs:bitarray(NrArrayBits, InitialBitValue) -> BitArray
hipe_bifs:bitarray_sub(BitArray, BitNr) -> BitValue
hipe_bifs:bitarray_update(BitArray, BitNr, BitValue) -> BitArray

Bit values are the booleans true and false.
Array indexing is 0-based (1-based indexing is just sooo wrong).
The update operation returns the updated array.

The number of elements in a bit array is limited to what can be
described by non-negative fixnums (immediate "small" integers),
which is something like 2^27 - 1 on 32-bit machines. Larger bitarrays
than that must be emulated using a chunked representation.
See lib/hipe/regalloc/hipe_ig.erl for an example (look for
the USE_NEW_BITARRAY_BIFS define and the adjset code following it).

/Mikael