# Boolean operations on large bit vectors / arrays

**URL:** <https://discourse.julialang.org/t/boolean-operations-on-large-bit-vectors-arrays/1137>\
**Category:** Internals & Design\
**Created:** [December 24, 2016, 3:24pm UTC](https://discourse.julialang.org/t/boolean-operations-on-large-bit-vectors-arrays/1137 "2016-12-24T15:24:59Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![ScottPJones](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/scottpjones/32/146_2.png) [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)\
**Post date:** [December 24, 2016, 3:24pm UTC](https://discourse.julialang.org/t/boolean-operations-on-large-bit-vectors-arrays/1137/1 "2016-12-24T15:24:59Z")

</div>

In [https://github.com/JuliaLang/julia/pull/17623#issuecomment-268703295](https://github.com/JuliaLang/julia/pull/17623#issuecomment-268703295), @stevengj had asked how common operations on large bit arrays were. For database queries, they are very common (it is a common technique to use bitmap and/or bitslice indices, esp. for decision support sorts of applications), where bit vectors representing millions of rows are anded, ored, or negated (we actually use bit vectors representing up to 4 billion rows for our product).  
I was concerned about the comment by @carlobaldassi:

> This has removed a few optimizations for BitArrays. One in particular is the case A .\* B when A and B have the same shape, which previously was specialized and called A & B. The difference is quite significant, e.g. for 1000x1000 BitArrays it’s almost 40-fold.

For these sorts of applications, it would be quite useful also for the SIMD instructions to be used (previously, I asm. optimized these to use the AVX instructions on x86), and to make that work best, Julia would need to give 32 or 64 alignment to the chunk array in the BitArray.

---

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [December 24, 2016, 3:52pm UTC](https://discourse.julialang.org/t/boolean-operations-on-large-bit-vectors-arrays/1137/2 "2016-12-24T15:52:46Z")

</div>

The discussion here on specialized versions for `Vector` is highly related at a more abstract level:

> [@What is the future of \`sin(::Vector)\` when there is \`sin.(::Vector)\`?](https://discourse.julialang.org/t/what-is-the-future-of-sin-vector-when-there-is-sin-vector/677):
>
> Since - as I understand it - the new broadcast sugar is the new way of computing the element-wise value of a function I wonder what the plan is with the special vectorized versions, such as sin(::Vector) for example. Is the plan that they will continue to work as is or are there thoughts about repurposing the signature? I am asking because I contemplate how to go about this with LossFunctions.jl and I do try to keep things “julian”. Personally, at least for my use-case, I am considering making …

---

<div class="post-metadata">

**Author:** ![carlobaldassi](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/carlobaldassi/32/37_2.png) [@carlobaldassi](https://discourse.julialang.org/u/carlobaldassi)\
**Post date:** [December 26, 2016, 3:26pm UTC](https://discourse.julialang.org/t/boolean-operations-on-large-bit-vectors-arrays/1137/3 "2016-12-26T15:26:40Z")

</div>

I don’t think that that change is too concerning, that comment is about `.*`, which can be directly replaced with `&` for that specific case. Therefore, that is only going to affect generic code which calls `.*`; if you already know you are dealing with bit masks you should probably use `&` anyway. If you also want to avoid allocations, it’s best to use `map!`, which also has a specialized version when the operation is `&` and the arguments are BitArrays. (The same is true for other bitwise operators of course.)

(For what it’s worth, I also use large BitArrays quite frequently, unsurprisingly…)