[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)
- To: Mark Callow <email@example.com>
- Subject: Re: [Public WebGL] Typed Array setter for partial arrays (and typed array performance)
- From: Kenneth Russell <firstname.lastname@example.org>
- Date: Thu, 21 Apr 2011 19:50:42 -0700
- Cc: Ben Vanik <email@example.com>, public webgl <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1303440644; bh=8eq/vqqee4iY093OYEvjaOG/7Wo=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=auGP3etuvuBIM5IKXLrYYXQJZ+RIoCuZHw/Y4919CCiwxbYQZ+J66+McdanK5tpQt 83cBI8DWZJVGdQivELZBA==
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/4iNagbFmWC+6BIO5lbURAKZG045STOpo627H+3NxAk=; b=VA9+YhiBRL3fLYv1CeYxqrdwLlxLkZ9URyfBf7DCP3olDOkxDZGT1C2G1E5KEwrNUn OWF9pUY/Xujis5Mg70dQ==
- Domainkey-signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dLUNWCKk4iJx1Aa5wNyVJPGWHLl8KF1Bw62CiJCToqctK/Rstqz5I/+Z7tuUn2Pums 2FDKgp75Z6rHT5TRrpRg==
- In-reply-to: <4DB0EAC2.email@example.com>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <4DB00602.firstname.lastname@example.org> <BANLkTinJS2CTxpCNdW6msG3wHBhEwV+akQ@mail.gmail.com> <BANLkTi=xiewKi7NWF6JTLhdzZPQgD5k6fA@mail.gmail.com> <4DB0EAC2.email@example.com>
- Sender: firstname.lastname@example.org
On Thu, Apr 21, 2011 at 7:41 PM, Mark Callow <email@example.com> wrote:
> On 22/04/2011 07:25, Kenneth Russell wrote:
>> 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.
> 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
> Also like Ben Vanik, I
> would be really surprised if the JIT generated was faster than memcpy().
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.
engines will make it unnecessary to add more APIs just to avoid the
generation of garbage.
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: