The usecases:
*1) Filling with custom data*
When writing WebGL or physics or many other things todo with large
collections of data, it's not unusual to have to fill arrays with custom
data of some kind.
someArray.set([
> x0, y0, 1, 0, 0,
> x1, y0, 0, 1, 0,
> x1, y1, 0, 0, 1,
> x0, y0, 1, 0, 0,
> x1, y1, 0, 1, 0,
> x0, y1, 0, 0, 1
> ], i);
*2) Copying in data from another array*
Some data resides in another array and needs to be copied in. A feature
frequently in use by emscripten.
someArray.set(otherArray.subarray(srcOffset, srcSize), dstOffset)
*3) Initializing an existing array with a repeated numerical value*
For audio processing, physics and a range of other tasks it's important to
initialize an array with the same data.
for(var i=0; i<size; i++){ someArray[i] = 0; }
*The problem:* Doing all of these things is slow and/or unsuitable for
realtime code.
1. someArray.set from a new list is slow due to set being slow, and
constructing the list is slow. It's not realtime friendly because it'll
construct a new list, which will have to be GCed.
2. someArray.set is slow due to the new array view construction and it's
not realtime friendly due to GCing.
3. Filling an array one element at a time is slow.
*The test: *http://jsperf.com/typed-array-fast-filling/4 (screenshot here
http://codeflow.org/pictures/typed-array-test.png and attached)
*The status quo:*
The fastest way to fill an array with custom data across browsers is:
r[i] = x0;
> r[i + 1] = y0;
> r[i + 2] = 1;
> r[i + 3] = 0;
> r[i + 4] = 0;
> r[i + 5] = x1;
> r[i + 6] = y0;
*Things that are not faster: *
- pushing to a list: ~93% slower
- a helper function filling from a list: 57-70% slower
- array.set: ~73% slower
- a helper function filling from arguments: 65% - 93% slower
- asm.js: 69-81% slower (even in firefox)
*Suggestions:*
1. Browser engines should get a lot better at arguments handling so that
non sized arguments can be quickly iterated by native code. Firefox is
already pretty good at unboxing a specified argument list (chrome not so
much), but I think that test shows that there's ample room for improvement.
2. *someArray.memcpy*: Add a method to typed arrays that can shuffle
bytes from array A to array B like so: dst.memcpy(dstOffset, src,
srcOffset, size). This is to avoid having to allocate an object to do the
job.
3. *someArray.memset*: Add a method to typed arrays that can initialize
them with a value like so: dst.memset(dstOffset, value, size)
4. *someArray.argcpy*: Add a (fast) method to typed arrays that can copy
the arguments like so: dst.argcpy(dstOffset, 1, 2, 3, 4)
5. Drastically improve the set method.
(naming and semantic don't matter to me, long as the methods do it
efficiently, conveniently and fast what's suggested).
*Related discussion:*
- https://bugzilla.mozilla.org/show_bug.cgi?id=936168
-
https://www.khronos.org/webgl/public-mailing-list/archives/1410/msg00105.html
*Consequence of failure to rectify:*
Fast code will be unreadable and unmaintainable. Sophisticated and speed
requiring code will not be written in ecmascript. Emscripten and asm.js
with its hermetic nature will crowd out ecmascript driven developments.
Other alternatives such as on GPU transform&feedback and compute shaders
will be preferred to solve the problem.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
