TypedArrays are much slower than Arrays about gl-matrix HOT 4 CLOSED

Wow! That's a pretty significant difference!

Like you, I was fairly surprised by the results so I decided to do a bit more digging, because I had benchmarked this same scenario earlier in the libraries life and found TypedArrays to be faster. So I tinkered with it a bit and eventually landed on the following: In your tests the TypedArray is slower because you create a new one every pass.

If you check out my variation of your test that creates the tests once in the setup and then reuses them for all the iterations the Typed array does come out on top. (Not by a huge margin, but it is faster).

http://jsperf.com/vec3-performances/2

This is concerning to me because it means that you won't get the performance benefits unless you are using the library the "right" way, which is obviously going to depend on the programmer. That said, glMatrix was architected in such a way as to encourage variable reuse anyway.

Finally, if you're using glMatrix with WebGL then you'd be forced to construct a new Float32Array anyway each time you passed a matrix to your shader if we forced it to use JS Arrays. That would probably nullify any performance gains you got from making the initial create faster. :(

So, long story short: I think I'm going to leave the library as-is of the moment and maybe add some more documentation about "best practices". It's probably also worthwhile to prod at the Chrome and Firefox teams to see if there's any performance gains to be had with TypedArray construction.

Thanks for pointing this issue out!

from gl-matrix.

Thanks for the tip about object creation. I'm going to try and reuse a lot my variables. I believe that typed arrays are allocated in a special memory space where malloc is more costly. Do you know a way to report this behavior to the Chrome devs?

I'm working on a ray tracer so I'm not too concerned about webgl interoperability. When I changed from Typed Array to Array and it took 1s instead of 10 I was shocked and quite happy :p

Thanks

Christopher Chedeau

On 24 déc. 2011, at 18:31, Brandon [email protected] wrote:

Wow! That's a pretty significant difference!

Like you, I was fairly surprised by the results so I decided to do a bit more digging, because I had benchmarked this same scenario earlier in the libraries life and found TypedArrays to be faster. So I tinkered with it a bit and eventually landed on the following: In your tests the TypedArray is slower because you create a new one every pass.

If you check out my variation of your test that creates the tests once in the setup and then reuses them for all the iterations the Typed array does come out on top. (Not by a huge margin, but it is faster).

http://jsperf.com/vec3-performances/2

This is concerning to me because it means that you won't get the performance benefits unless you are using the library the "right" way, which is obviously going to depend on the programmer. That said, glMatrix was architected in such a way as to encourage variable reuse anyway.

Finally, if you're using glMatrix with WebGL then you'd be forced to construct a new Float32Array anyway each time you passed a matrix to your shader if we forced it to use JS Arrays. That would probably nullify any performance gains you got from making the initial create faster. :(

So, long story short: I think I'm going to leave the library as-is of the moment and maybe add some more documentation about "best practices". It's probably also worthwhile to prod at the Chrome and Firefox teams to see if there's any performance gains to be had with TypedArray construction.

Thanks for pointing this issue out!

---

Reply to this email directly or view it on GitHub:
#11 (comment)

from gl-matrix.

http://fooo.fr/~vjeux/epita/raytracer/trace.html

It's work in progress but you might be interested :)

from gl-matrix.

Awesome raytracer! Thanks for sharing!

from gl-matrix.