Altivec bitshuffle

[FrancescAlted]

This PR is for:

• Extend work to types larger than 8-bit
• Handle the leftovers (buffer size is not a multiple of the block size)

It is still work in progress.

[FrancescAlted]

This is complete and ready for merging (bar some suggestions or comments). @kif can you review?

[FrancescAlted]

I have removed a duplicated bitshuffle1_altivec function, but bitunshuffle1_altivec is different because the function that replicates its functionality (bshuf_trans_byte_bitrow_altivec) is implemented quite differently. @kif could you please do some performance measurements and tell me whether bitunshuffle1_altivec has an advantage for type_size == 1?

[kif]

I am running the benchmark ...

[kif]

Here are some graphs I obtained versus the master (using the SSE2 auto-translated code) on various block size:

[kif]

I also performed a benchmark of the bitshuffle1_altivec (labelled JK) versus bshuf_trans_byte_bitrow_altivec (labelled FA):

[FrancescAlted]

Yes, I did notice the drop in performance of the VSX version for bitunshuffle for typesize > 1. However, as Blosc2 typically shuffles/unshuffles blocks of 1 MB as maximum, I don't think the drop in performance in this region is too bad.

But if for some reason, one absolutely wants better performance for blocks > 1 MB, another possibility is to find a direct replacement for __mm_store_pi and come with a similar algorithm like in master but using VSX. Finally, if getting rid of SSE2 is not deemed absolutely necessary, one may want to go back to the original bshuf_trans_byte_bitrow_altivec.

[FrancescAlted]

@kif Something went wrong in pasting the plot for bitshuffle1_altivec versus bshuf_trans_byte_bitrow_altivec.

[kif]

I noticed, but my notebook kernel crashed and I had to relaunch it to get the last image.

[FrancescAlted]

I also performed a benchmark of the bitshuffle1_altivec (labelled JK) versus bshuf_trans_byte_bitrow_altivec (labelled FA):

That's pretty cool. I'd say that we want to use the bitunshuffle1_altivec instead of bshuf_trans_byte_bitrow_altivec for typesize == 1. A switch case would be enough for this.

OTOH, I am not sure why bitshuffle1_altivec is faster than bshuf_trans_byte_bitrow_altivec as at a glance they look pretty much the same. @kif are you aware of a significant difference?

[kif]

If I remember well the code is not working in all conditions (there are additional constrains on the bloc size which has to be a multiple of 16(vector size)*8(bits/item)) which makes it not that easy to use.

[FrancescAlted]

I see. Well, a possibility is to use the accelerated path just when the condition blocksize % (16 * 8) == 0 holds (which should be a fairly common case, as Blosc typically splits blocks in figures that are a power of 2). I think this approach will allow to quickly get low-hanging performance fruits.

[FrancescAlted]

Merging.