+1 - especially the lack of something like the proposed memset() has been a massive headache for me.
Semantics (I'm quite nitpicky on them)... I'd prefer the argument order for memcpy() to be (src, dstOffset, srcOffset, size) to be consistent with set(). As for memset(), I'd prefer (value, dstOffset, size) because I've so far actually never needed offset and size. I'd also prefer memcpy to be named closer to set(), because it's basically the same thing with two extra arguments. I'm not sure what the performance implications would be to actually just add the extra two parameters to set as optional, so maybe someone smarter than me can chime in on whether it's better to add a separate method or overload the existing set()? It's worth noting that set() currently gets relatively faster the bigger the data is, and the last I tested (also confirmed by Jukka Jylänki), at around 4k (surprisingly many) elements it becomes faster than manually assigning values. On Thu, Oct 30, 2014 at 10:29 AM, Florian Bösch <[email protected]> wrote: > 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 > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
