[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: Ben Vanik <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 15:25:43 -0700
- Cc: Mark Callow <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=1303424747; bh=x9fetAwFWe39WxDGDQidaXDb/V8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=KbH0mooKmTr/1TeYkR9IKQ8WMv1lKrT4QY9SCiRfp+ohD5iyojA/sYS8q77KMPrae uNjRLXGebdT4M7yKK3SAA==
- 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=gQiqQwURgen8Ky09T0Bk6Smq9/v28T0FthU4wtCZLdU=; b=URxincCLilq8F06mW5M9KfFHh+tgEF1o1KXNpcAJl44pHXPEwuzFL5XGutkoLQfJRV 3GkSxw1dRXYnhFUFSnzw==
- 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=C+EerteMzmpHdfUKs51iwhl1yzffTTLYUCG1oZUA09pty3+cFw5FnhnkW7F0OviOP4 Uq6OtFpcWs0EiH4y3BEA==
- In-reply-to: <BANLkTinJS2CTxpCNdW6msG3wHBhEwV+akQ@mail.gmail.com>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <4DB00602.email@example.com> <BANLkTinJS2CTxpCNdW6msG3wHBhEwV+akQ@mail.gmail.com>
- Sender: firstname.lastname@example.org
Mark: the poor performance of the set(Array, offset) variant in
Chromium is surprising, and I would encourage you to file a bug about
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.
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.
Ben: since it sounds like you are doing network I/O, should you be
using DataView instead of the typed array view types?
On Thu, Apr 21, 2011 at 11:57 AM, Ben Vanik <email@example.com> wrote:
> I agree this method would be really helpful. If the offset/count values were
> in bytes, it would allow for some awesome uses of typed arrays.
> The primary use case that comes to mind is packed data transfer. I've been
> experimenting with loading geometry/textures/etc from data blobs, and being
> able to subset the data efficiently (without using views, as I want an
> actual copy for modification) would make things much nicer. The other side
> of this is using it to construct data blobs - saving off content from
> client->server that contains large typed array chunks would greatly benefit
> from the speed boost.
> And as a nodejs user, this would be a tremendously useful thing when using
> protocol buffers and other sorts of binary message formats where perf really
> matters or doing large file system manipulations.
> As for the microbenchmarks, I've noticed the same thing. I just whipped this
> one up yesterday for testing out some common patterns I need for image
> The time for creating and initializing a JS array is two orders of magnitude
> longer than for typed arrays, but all other operations are 2x+ faster than
> typed arrays.
> I threw in CanvasPixelArray just to see if there were any
> special optimizations there - it's pretty much the same as Uint8Array (which
> makes sense).
> Here's a great blog post on perf comparison that just came
> out: http://blog.n01se.net/?p=248
> Ben Vanik
> 2011/4/21 Mark Callow <firstname.lastname@example.org>
>> Because I keep needing to do it, I have become irritated by the lack of a
>> function in the typed array specification do copy the partial contents of a
>> JS source array, something like:
>> void set(type array, optional unsigned long offset, unsigned long
>> srcOffset, unsigned long count)
>> The obvious answer is a wrapper but I suspected that a loop of, e.g,
>> i16array[i] = src[i] in JS would be slower than something internal to the
>> typed array implementation. I wrote a short test for this. The result on FF4
>> is as I expected:
>> Int16Array.set(2000 byte array) x 100 times took 1ms (400000000
>> Int16Array[j] = data[j] 2000 x 100 times took 4ms (100000000
>> Int16Array.set(200000 byte array) x 1 times took 1ms (400000000
>> Int16Array[j] = data[j] 200000 x 1 times took 4ms (100000000
>> To ensure the result is not influenced by smart optimizers the test is
>> repeated with a longer array and a single iteration. The bytes copied is the
>> same in each case.
>> The "wrapper" runs at one quarter the speed of a native implementation so
>> I think the above described set function is a badly needed addition to typed
>> If the source is a typed array, one can always create another view or
>> subarray so it is not so important to add a new function for this case,
>> though there is the issue of the garbage that must then be collected.
>> When I ran the same test on Chromium 12.0.717.0 (79525) I got a very
>> surprising result:
>> Int16Array.set(2000 byte array) x 100 times took 49ms (8163265.306122449
>> Int16Array[j] = data[j] 2000 x 100 times took 6ms (66666666.666666664
>> Int16Array.set(200000 byte array) x 1 times took 38ms (10526315.789473685
>> Int16Array[j] = data[j] 200000 x 1 times took 24ms (16666666.666666666
>> It is surprising for 3 reasons:
>> the overall poor performance
>> the fact that the Int16Array.set takes longer than a JS loop setting
>> individual elements
>> the fact that a single loop of 200,000 setting individual elements took 4
>> times longer than a double loop of 100 x 2000.
>> The test is attached.
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: