> On Oct 30, 2014, at 10:44 AM, Steve Fink <sphink at gmail.com> wrote:
> 
> On 10/30/2014 06:14 AM, Adrian Perez de Castro wrote:
>> On Thu, 30 Oct 2014 09:29:36 +0100, Florian Bösch <pyalot at gmail.com> wrote:
>> 
>>> The usecases:
>>> 
>>> [...]
>>> 
>>> *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; }
>> For this use case there is %TypedArray%.prototype.fill(), see:
>> 
>>  http://people.mozilla.org/~jorendorff/es6-draft.html#sec-%typedarray%.prototype.fill
>> 
>> JavaScript engines are expected to implement it at some point. For example
>> I am implementing this in V8, along with other new typed array methods. The
>> engines should be able to generate quite good code for uses of this function
>> and/or provide optimized versions relying on knowledge of the underlying
>> element type of the typed array they are applied to.
> 
> I implemented this for Firefox 2 years ago, but never landed it -
> https://bugzilla.mozilla.org/show_bug.cgi?id=730880 <https://bugzilla.mozilla.org/show_bug.cgi?id=730880>
> 
> 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.

I agree with this philosophy.  I would just point out that both in C and Java, having some way for the programmer to say “fill” (i.e. memset/bzero in C, and I forget what it is in Java) has survived despite the compilers being super mature, probably because idiom recognition on loops like this is too fallible in the general case.  So, I’d like to see .fill() be part of the language.

Anyway, I just filed a bug on our end for this: https://bugs.webkit.org/show_bug.cgi?id=138218

-Filip


> 
> On a related note, I *would* like to have some way of getting the OS to
> decommit memory. See https://bugzilla.mozilla.org/show_bug.cgi?id=855669 <https://bugzilla.mozilla.org/show_bug.cgi?id=855669>
> (start reading at about comment 22) for our discussion and attempt at
> this, which looks like it mysteriously trailed off this last March.
> Theoretically, the above loop could also trigger a decommit, but I think
> it's too much to expect the engine to guess when that's going to be a
> good idea. On the other hand, from a spec POV it's unobservable
> behavior, which makes it weird.
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss <https://mail.mozilla.org/listinfo/es-discuss>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141030/3d8b71d2/attachment-0001.html>

On Oct 30, 2014, at 10:44 AM, Steve Fink <sphink at gmail.com> wrote:

> I would rather
> see engines hyperoptimize
> 
> ```js
> 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.

I agree with this philosophy.  I would just point out that both in C and Java, having some way for the programmer to say “fill” (i.e. memset/bzero in C, and I forget what it is in Java) has survived despite the compilers being super mature, probably because idiom recognition on loops like this is too fallible in the general case.  So, I’d like to see .fill() be part of the language.

Anyway, I just filed a bug on our end for this: https://bugs.webkit.org/show_bug.cgi?id=138218