[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 <firstname.lastname@example.org>
- Subject: Re: [Public WebGL] Typed Array setter for partial arrays (and typed array performance)
- From: Ben Vanik <email@example.com>
- Date: Thu, 21 Apr 2011 11:57:48 -0700
- Cc: public webgl <firstname.lastname@example.org>
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=kuhJ7e6mW9Uq5BmUbHf/zZtkifx0w7IGMfFLVP03Lo0=; b=anl4MKnCb4E9QRp+hU2fJZ/A/Akp1oSZyuNHU2ZJkKg/+waTRohuY3vPH1n5NaDmji MdxVBFPLqdXDzZAPE1yezGaWkfhkw3J1g/0RisoEEMYp8Lft8KpHHwpVCPneMAsDIFxK 1bli4+SbIZpSU8Z829fyQQk1OHcwvN20+LryQ=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=klozS5AgMiErSLTyqgZSsp0r7OohcuUHr26B9mH8EZ5eBQk4exPmvoEEJ7WM4nuXZo HckSyYT8UQezsvAZrXfTGuITgAOxVmah2jO6juqIw/EUTvhrOSTJnuwrKrGdQkGcJ8X2 roc2A2sSDnFIFxj+z3O/Np8l7c12SfbmjtrMI=
- In-reply-to: <4DB00602.email@example.com>
- List-id: Public WebGL Mailing List <public_webgl.khronos.org>
- References: <4DB00602.firstname.lastname@example.org>
- Sender: email@example.com
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 processing:
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).
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 arrays.
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
Int16Array[j] = data[j] 2000 x 100 times took 6ms
Int16Array.set(200000 byte array) x 1 times took 38ms
Int16Array[j] = data[j] 200000 x 1 times took 24ms
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.