685458 - Add methods to ByteArray to read and write multiple ints/uints (and probably others) to/from vectors

Status: RESOLVED WONTFIX

(Tamarin Graveyard :: Library, enhancement, P3)

Description

[Lars T Hansen]

Grayson Lang says that it would be very helpful for them to have ByteArray methods that read and write multiple uints into vectors.  These methods would effectively mirror readBytes and writeBytes.  Thus for example,

  readUnsignedInts( uints: Vector.<uint>, offset: uint=0, length: uint=0 )
  writeUnsignedInts( uints: Vector.<uint>, offset: uint=0, length: uint=0 )

would mirror the API of readBytes in terms of meaning of parameters and exceptions thrown.

We could discuss whether the vector should be automatically extended to accomodate the data or not.

We could discuss whether the 'uints' parameter could be more lenient in its type, for example, it could allow Array.  I'd probably favor it.

We'd probably also want readInts / writeInts, readDoubles / writeDoubles and readFloat / writeFloats; the latter certainly would have to be able to accept Vector.<Number> now, and Vector.<float> additionally when we get that.

Later we'd also want readFloat4s / writeFloat4s into Vector.<float> and Vector.<float4>.

Comment 1

[Dan Smith]

Seems super useful.    I'll tentatively target for Brannan while you flesh out the proposal.

Comment 2

[Lars T Hansen]

I'm thinking a general block copy primitive might be the better approach.  Suppose v is a Vector.<T> where T is int, uint, float, Number, or float4, and ba is a ByteArray.  Then

  copyToVector(v, voffset:uint, ba:ByteArray, baoffset:uint, length:uint)

copies length*sizeof(T) bytes from ba starting at baoffset to v starting at voffset (with range checking on both sides of course, and obeying current settings for endianness in ba) and 

 copyFromVector(ba:ByteArray, baoffset:uint, v, voffset:uint, length:uint)

copies length*sizeof(T) bytes from v starting at voffset to ba starting at baoffset (ditto).  The methods would probably be static methods on ByteArray, though in principle one could be a method on ByteArray and the other could be a method on Vector.

If the endianness of the ByteArray is the same as the native endianness this is just a memmove.

The weakness of this API relative to the other is that it's less statically type safe, but that's not a big deal.  There's no return value, only the type checking on the v argument suffers. 

It's possible that Boolean belongs in the set of types supported.

It's possible that there's also a need for a widening/narrowing conversion in the copy, eg, copying individual bytes into individual vector elements, or copying floats into Vector.<Number>.  (The Boolean is a behind-the-scenes example of this, since in Vector.<Boolean> each element is currently four bytes wide but in a ByteArray a boolean is one byte.)  This takes us pretty far afield, though.

Comment 3

[Lars T Hansen]

Draft spec on Zerowing: 
/display/flashruntime/2011+-+ByteArray+to+Vector+bulk+copy+methods

Comment 4

[Lars T Hansen]

Attachment: Simple benchmark comparing a loop with the new primitives

Comment 5

[Lars T Hansen]

Attachment: Work in progress

This is the core of the changes to ByteArray, handles native-endian case only (using memmove) but there's a sketch here for the byte-swapping case - small matter of programming.

Performance:

Compared to current TR, the new copyToVector method is about 200x faster at copying 998 ints out of a ByteArray into a Vector than a loop using readInt.

With the pending ByteArray optimizations in bug #692042 the advantage drops to about 100x.

This is all on MacPro 2x2.93GHz Xeon.

The native-endian case is probably optimal for this code but it's not unrealistic to assume that we'd see similar speedups for the opposite-endian case.

Comment 6

[Sylvestre Ledru [:Sylvestre]]

Tamarin is a dead project now. Mass WONTFIX.

Comment 7

[Sylvestre Ledru [:Sylvestre]]

Tamarin isn't maintained anymore. WONTFIX remaining bugs.