Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TypedArrays are much slower than Arrays #11

Closed
vjeux opened this issue Dec 24, 2011 · 4 comments
Closed

TypedArrays are much slower than Arrays #11

vjeux opened this issue Dec 24, 2011 · 4 comments

Comments

@vjeux
Copy link

vjeux commented Dec 24, 2011

Hi,

For fun I've tried to replace typed arrays into normal arrays and I was shocked by the results. It's 10 times faster in Chrome. It's also faster in Firefox.

http://jsperf.com/vec3-performances

You might want to switch back to normal arrays as it gives a huge speed up for free :)

@toji
Copy link
Owner

toji commented Dec 24, 2011

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!

@toji toji closed this as completed Dec 24, 2011
@vjeux
Copy link
Author

vjeux commented Dec 24, 2011

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 Jonesreply@reply.github.com 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)

@vjeux
Copy link
Author

vjeux commented Dec 25, 2011

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

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

@toji
Copy link
Owner

toji commented Dec 27, 2011

Awesome raytracer! Thanks for sharing!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants