I'd also like to chime in since this is a real problem for performance-sensitive JSIL code: The idea that JS runtimes will just optimize all our performance-sensitive loops is lovely. It also appears to be a fantasy, because we've been writing those loops for years and they're still slow. I did some extensive testing and experimentation with spidermonkey a year or so back, examining how it optimized various forms of a memcpy loop, and the results were pretty dire. V8 didn't seem to fare much better, though it is harder to tell because they don't trivially expose generated native code for functions.
In my testing, even best-case optimized memcpy/memset loops did not produce the kind of efficient code you want. There were always bounds checks and in some cases I saw other overhead. The set/copy definitely weren't vectorized. In the best case I saw bounds checks getting hoisted out of the loop body (great!) I feel like at this point the claim that we don't need better copy/set APIs is the 'sufficiently smart compiler' trope all over again, though in this case perhaps it is wholly possible and it's just not happening because it isn't important enough to VM implementers. TypedArray.prototype.fill is perfect for that scenario, so all we need is a copy. It's essential that the copy support the source array being distinct from the destination one (a previous proposal - did it go through? - required the source & destination arrays to be the same, presumably micro-optimizing for emscripten.) In the short term these new methods could be self-hosted and would at least be no worse than existing hand-authored loops. If the runtime uses the equivalent of Spidermonkey's callsite cloning, the copy/fill loops would be specialized based on element type, which would *increase* performance. If the VM were to actually generate fully optimal copy/fill code, it would be a sizable improvement. At a bare minimum, having the 'best' copy/fill loop JS for a given runtime in the stdlib is much better than developers having to figure out the best loop type - especially if that type varies across browsers. The performance of memcpy and memset is extremely important. Off the top of my head, I'm aware of a Google paper where they experimented with using instrumentation and specialized code to improve memcpy performance across some of their key applications and the results were (IMO) quite significant: http://static.googleusercontent.com/media/research.google.com/en/us/pubs/archive/40679.pdf In some of their applications a *significant* chunk of time is spent just inside memcpy - 20% or more - with memset and memcmp adding up to a couple more percentage points. Any optimizations to these functions can pay dividends, obviously. For real-world applications being ported to JS, if memcpy and memset are already at a performance disadvantage vs the 'standard' ones used in native C, this will be more dramatic. Related: https://bugzilla.mozilla.org/show_bug.cgi?id=862249 On 30 October 2014 11:46, Florian Bösch <[email protected]> wrote: > On Thu, Oct 30, 2014 at 6:44 PM, Steve Fink <[email protected]> wrote: >> >> Now there is %TypedArray%.prototype.fill. But I've become generally >> skeptical about it as an answer to performance concerns. I would rather >> see engines hyperoptimize >> >> for(var i=0; i<size; i++){ someArray[i] = 0; } >> >> based on observed type information. Which is not to say that we wouldn't >> want to make TA#fill fast too, but the above seems more generally useful. > > While useful, it's not a substitute for a convenient and fast method. Also, > I presented severe usuability issues with that approach if you need more > than one value (such as computed values). Usability issues which can be > resolved by using set + a new list for every assignment, which, > unfortunately, is also quite slow. It's slow because say, for a loop that's > running a million times, it makes a million lists. > > _______________________________________________ > 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
