[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Typed Array setter for partial arrays (and typed array performance)

On Thu, Apr 21, 2011 at 7:41 PM, Mark Callow <callow_mark@hicorp.co.jp> wrote:
> On 22/04/2011 07:25, Kenneth Russell wrote:
>> ... However, in an optimizing JavaScript VM, writing the associated
>> JavaScript code to do these sorts of operations will be faster than
>> adding another built-in, because in the former case the JIT has a
>> chance to generate specialized code, and in the latter case you're
>> calling in to and out of the VM's runtime system (typically written in
>> C++) which can't perform the same sorts of optimizations.
> But doesn't each typedarray[x] = y in the Javascript code require
> calling into and out of the VM's runtime system?

Not necessarily. As one example, in the V8 virtual machine, the JIT
has recently been made aware of the typed array types, so specialized
assembly code is generated for the assignment operator which is
extremely efficient.

> Also like Ben Vanik, I
> would be really surprised if the JIT generated was faster than memcpy().

Copying a JavaScript array into a typed array isn't a memcpy()
operation, at least not in V8. Because JavaScript arrays can hold any
kind of object, it's necessary to iterate object-by-object through the
JS array, converting each value to a number. This operation is much
slower when written in C++ using the JS engine's API rather than
allowing the JIT to compile the code which does the conversions.

> At best I would expect it to be the same. Lastly my little benchmark
> shows that the built-in is much faster (at least on FF4).
> I can't agree with your argument.

I hear you.

>> I am not personally convinced that we should add this new entry point.
>> Especially in low-level APIs like typed arrays, every new one has a
>> high maintenance cost. Also, there are API changes lined up which will
>> address known performance bottlenecks on the web platform that I think
>> should take priority.
>> As part of the planned Typed Array API changes to support efficient
>> communication with web workers, the plan is to add convenience methods
>> to copy ArrayBuffers and possibly sub-portions of them. I think we
>> should invest our time in moving those changes forward.
> I will certainly track the API changes and make suggestions. I like
> Ben's suggestion of real slices but those do not address my use case. I
> think support for copying  sub-portions of both JS arrays and
> ArrayBuffers are really useful. The former because of performance and
> the latter because of the garbage generated by making new views or
> subarrays solely for the purpose of being the source of a copy.

I hope that further optimizations in the current crop of JavaScript
engines will make it unnecessary to add more APIs just to avoid the
generation of garbage.


> Regards
>    -Mark

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl