Consider using u64 or usize for Bitmap elements instead of u8

[Dandandan]

This should probably be quite a bit faster for doing many operations like comparison kernels etc.

I think there is also some potential for simplifying code, as some (unsafe) code now tries to create u64 chunks (see #578 , there are other many other places in the code doing this, i.e. bitwise ops).

Having the bitmap use u64 instead of u8 would reduce the need to do those conversions and also speed up some parts which work at u8 at a time (e.g. comparison kernels currently use u8) without the need to

Some references:

• https://docs.rs/bitvec/0.22.3/bitvec/slice/struct.BitSlice.html#t-bitstore - this is using usize by default

It would be quite an invasive change so I think it's good to discuss potential trade-offs first.

[jorgecarleitao]

:D ahaha, recent discussion on this: https://github.com/teratide/narrow/issues/23

I agree that it is worth trying out. I think that bitvec's semantics is different from arrow on a u64, though. Specifically, on a u64, the indexes of bits here need to be

[7, 6, 5, 4, 3, 2, 1, 0, 15, 14, 13, 12, 11, 10, 9, 8, ...]

because the semantics in arrow is over individual bytes.

[ritchie46]

Another option might be to create a safe API that allows working on slices of &[usize]. For instance the unsafe part could be isolated by a fn split_by_alignment<usize> -> (&[u8], &[usize], &[u8]).