Add unsafeCast to Primitive vectors

[lehins]

While reviewing #398 I noticed that there is no unsafeCast for primitive vector.

We can't provide a cast that changes primitive vectors with elements of different sizes in the way that Data.Vector.Storable.unsafeCast does it. For example Vector Word8 -> Vector Word16 cast cannot be implemented with current primitive. However, this doesn't mean a cast like Vector Word8 -> Word Int8 or a Vector Float -> Vector Word32 cannot be useful for some reason.

[Shimuuar]

Or unsafeCast over newtypes for that matter

[qrpnxz]

We can't provide a cast that changes primitive vectors with elements of different sizes in the way that Data.Vector.Storable.unsafeCast does it.

Why not?

[lehins]

@qrpnxz Because unlike Storable vector we cannot start at an arbitrary byte offset, we have to think in element offsets. Unfortunately it is a limitation of Prim type class, which could be fixed.

For example let's try to cast a primitive Vector Word16 -> Vector Word64 and this is the vector we want to cast:

w16vec :: Vector Word16
w16vec = drop 3 $ fromList [1,2,3,4,5,6,7,8]

when we drop 3 elements we do a O(1) slice, which makes

w16vec :: Vector Word16
w16vec = Vector 3 5 (ba :: ByteArray)
  where ba = fromList [1,2,3,4,5,6,7,8]

If we were to convert this vector using the same strategy as in Storable we'd expect a Vector Word64 with a single element, were each of its 16 bit chunks were: [4,5,6,7], but how would you specify the offset?

w32vec :: Vector Word64
w32vec = Vector ? 1 (ba :: ByteArray)

Problem is that the offset must be specified in number of elements, and it must be specified in number of elements because Prim class does not provide us with the ability to index in offsets of bytes, only in elements

[qrpnxz]

How unfortunate. Thanks for explaining.

[qrpnxz]

A pinned Primitive variant could do it by implementing *byteOff :: MutableByteArray# -> Int# -> State# s -> _ helper functions with byteArrayContents#, plusAddr#, and *OffAddr#. For example:

indexByteOffPrim :: Prim a => ByteArray# -> Int# -> a
indexByteOffPrim arr# idx# =
  case byteArrayContents# arr# of
    addr# -> indexOffAddr# (plusAddr# addr# idx#) 0

writeByteOffPrim :: Prim a => MutableByteArray# -> Int# -> a -> State# s -> State# s
writeByteOffPrim marr# idx# a s0# =
  case unsafeFreezeByteArray# marr# st0# of
    (# s1#, arr# #) -> case byteArrayContents arr# of
      addr# -> writeOffAddr# (plusAddr# arr# idx#) 0 a s1#

EDIT:

In the latest base there is now mutableByteArrayContents# :: MutableByteArray# d -> Addr#. I don't know what version exactly it was introduced.

writeByteOffPrim :: Prim a => MutableByteArray# -> Int# -> a -> State# s -> State# s
writeByteOffPrim marr# idx# a s0# =
  case mutableByteArrayContents marr# of
    addr# -> writeOffAddr# (plusAddr# arr# idx#) 0 a s0#

[lehins]

@qrpnxz Your pinned solution would not work for vector first of all. Secondly why would use Primitive for pinned memory, you can just use Storable vector.

I know for certain that this problem is solvable with primitive operations that work on a byte offset, such as indexWord8ArrayAsWord16# for example, however this is not a discussion for vector package, you should open an issue on the primitive repository if you really care about this.

[qrpnxz]

I don't see why it wouldn't work. Perhaps I should mention that the offset would now be in bytes. Offset recalculation would not even be needed at all in a cast; it would stay the same. As to why you would want a pinned version of the primitive vector, here is one use-case: you can zero-copy convert a pinned primitive vector into both Data.Text.Text and into Data.ByteString.ByteString. If you use a storable vector you have to copy to go into text, if you use an unpinned primitive vector you have to copy to go into bytestring.

Although the Prim class could be improved with the functions you mention, I'm not proposing to a change to primitive; I'm talking about what can be done in vector today with what we already have. If the only acceptable solution is to go and change primitive, then yes I can go over there and see what can be done, but already we can do something here.

[lehins]

The whole point of Data.Vector.Primitive.Vector is that it is unpinned memory. If you need pinned memory you should use Data.Vector.Storable.Vector vector.

Switching primitive vector to use byte offset is a serious breaking change, which could happen, but only if primitive supported it and there was enough motivation to get this done.
Switching primitive vector to use pinned memory in order to achieve zero copy to Text and ByteString does not outweigh the issue of memory fragmentation when a lot of small vectors are being used. This is not something we will do today or ever for that matter!

FYI:

• It is possible to cast Primitive vector into Text without copy, since both use unpinned memory.
• It is possible to cast Storable vector into ByteString without copy, since both use pinned memory.

If the only acceptable solution is to go and change primitive, then yes I can go over there and see what can be done

So yes, the only acceptable solution is to go and change primitive

[qrpnxz]

Goodness, I did not mean to imply changing the current Primitive to pinned! (😄) I was talking about having pinned variant; that is, a whole other type. Of course we still want the unpinned one.

It is possible to cast Primitive vector into Text without copy, since both use unpinned memory.
It is possible to cast Storable vector into ByteString without copy, since both use pinned memory.

I said so myself? The plus is being able to do both Text and ByteString. (Useful in parsing.)

[lehins]

I was talking about having pinned variant; that is, a whole other type.

Maintaining five different modules with almost the same API already takes a lot of work, I'd be dreading adding one more module to that list.

It feels like we keep talking past each other. I recommend you open a ticket explaining clearly:

• the goals you are trying to achieve.
• the proposed solution:
  • list all the benefits we would gain from this solution. If performance is your goal, some basic benchmarks would be useful to support the claim.
  • list all the drawbacks that you can think of
  • estimate or summarize in words how much work it would take to implement the solution and maintain it. Evaluate if all the effort is worth the goal.
• compare it to alternative solutions that you know of

If all maintainers will agree that it really is something worthwhile implementing an maintaining then we can come up with the plan on how to get it done. This would also allow other from the community to pitch in with ideas. Discussing this on a merged PR does not make much sense and it doesn't have the same visibility.