Does Int32Array look horrible only to me? What if I want an array of my own custom types - say vec2f. Do I have to use 2 Float32Array's? Javascript is a horrible language where you have the tradeoff between performance and expressibility. Seriously, this whole web development thing needs to be fixed.
Binary data processing in JavaScript
11–20 of 32 posts
Re: Binary data processing in JavaScript
#12Couple of things to be aware of from a V8 perspective: - to make "creation" test more fair for normal arrays they should be preallocated with new Array(arraySize), if arraySize does not exceed 90000. This will ensure that you are not wasting time reallocating backing store as it grows. - It has been pointed to the test author a year ago that having a single test_SMTH function and calling it with different array types…
Any idea as to how other JS engines handle polymorphism?
I am not very familiar with internals of other engines. AFAIK both SpiderMonkey and Safari have polymorphic inline caches for a.foo property access sites. I can't say if the leverage PICs for a[i] access sites.
But from what I see from a quick glance over JavaScriptCore sources they do not seem to handle any kind of polymorphism for a[i] kind of sites in their new optimizing compiler (aka DFG). Additionally they do seem to handle polymorphism for a.foo sites in DFG only if foo always has the same offset in all structures this site have seen. I might be wrong about it though, it was just a quick flight over the source, without even checking it out to the disk.
Re: Binary data processing in JavaScript
#13Does Int32Array look horrible only to me? What if I want an array of my own custom types - say vec2f. Do I have to use 2 Float32Array's? Javascript is a horrible language where you have the tradeoff between performance and expressibility. Seriously, this whole web development thing needs to be fixed.
You can use one Float32Array: x component gets even indices, y gets odd ones.
The next standard might have a better binary data support:
http://wiki.ecmascript.org/doku.php?id=harmony:binary_data
I am not sure though where you tradeoffs between expressibility and performance. Typed arrays came to our world only recently, when needs of WebGL gave them birth. So they ended up being bolted on top of an existing language.
Re: Binary data processing in JavaScript
#14Earlier quoted context omitted.
Any idea as to how other JS engines handle polymorphism?
I am not very familiar with internals of other engines. AFAIK both SpiderMonkey and Safari have polymorphic inline caches for a.foo property access sites. I can't say if the leverage PICs for a[i] access sites. But from what I see from a quick glance over JavaScriptCore sources they do not seem to handle any kind of polymorphism for a[i] kind of sites in their new optimizing compiler (aka DFG). Additionally they do s…
Yes, other engines do not seem to handle polymorphism well. I just amended the code to use separate test_something_arraytype for each array type. And, it turns out that the performance of other browsers have improved significantly and they look closer to Chrome now. Check out the updated charts in the blog post.
Re: Binary data processing in JavaScript
#15Earlier quoted context omitted.
I am not very familiar with internals of other engines. AFAIK both SpiderMonkey and Safari have polymorphic inline caches for a.foo property access sites. I can't say if the leverage PICs for a[i] access sites. But from what I see from a quick glance over JavaScriptCore sources they do not seem to handle any kind of polymorphism for a[i] kind of sites in their new optimizing compiler (aka DFG). Additionally they do s…
Yes, other engines do not seem to handle polymorphism well. I just amended the code to use separate test_something_arraytype for each array type. And, it turns out that the performance of other browsers have improved significantly and they look closer to Chrome now. Check out the updated charts in the blog post.
Thanks for the update!
I suggest you add a note to the text hinting that you are not using original tests anymore. It would be even cooler if you publish both results of original (polymorphic) and your (non-polymorphic) runs.
I find results for "random read" particularly interesting. I need to take a look at the generated code. It might be that there is something in the way V8 compiles integer modulo operation that makes it slower than SpiderMonkey.
[though for this test to be comparable across browsers you should really fix function init_randlist not to use Math.random but use a pseudo-random generator with a _fixed_ seed. Uncontrolled sources of randomness should be discouraged in microbenchmarks and they lead to flaky unreproducible benchmarks. Though I don't think that it's the reason here].
Re: Binary data processing in JavaScript
#16Earlier quoted context omitted.
Any idea as to how other JS engines handle polymorphism?
I am not very familiar with internals of other engines. AFAIK both SpiderMonkey and Safari have polymorphic inline caches for a.foo property access sites. I can't say if the leverage PICs for a[i] access sites. But from what I see from a quick glance over JavaScriptCore sources they do not seem to handle any kind of polymorphism for a[i] kind of sites in their new optimizing compiler (aka DFG). Additionally they do s…
I have added an update note to the post. Also, I have added a table comparison between polymorphic & non-polymorphic runs.
I will fix the code to use pseudo-random function to make the test results more meaningful.Also, I will try to send a pull request to the original test author.
Re: Binary data processing in JavaScript
#17Jdataview handles this already. Except for Internet Explorer of course, which can't handle arrays with null characters in it. No matter what you do, IE won't let you see beyond the null char. No other browser has this issue.
I once pointed this out, but got a "holy edge case, Batman!" [1], and got voted to -1...
Re: Binary data processing in JavaScript
#18Does Int32Array look horrible only to me? What if I want an array of my own custom types - say vec2f. Do I have to use 2 Float32Array's? Javascript is a horrible language where you have the tradeoff between performance and expressibility. Seriously, this whole web development thing needs to be fixed.
You can use one Float32Array: x component gets even indices, y gets odd ones. The next standard might have a better binary data support: http://wiki.ecmascript.org/doku.php?id=harmony:binary_data I am not sure though where you tradeoffs between expressibility and performance. Typed arrays came to our world only recently, when needs of WebGL gave them birth. So they ended up being bolted on top of an existing language…
"You can use one Float32Array: x component gets even indices, y gets odd ones."
That is exactly my point of choosing the performance vs expressibility. But then how do I write algorithms in a generic fashion for them? In C++ I have templates and template functions, so I can write algorithm that will work for any type of the array. And I'm not even talking about STL which decouples algorithms from containers, by making the latter provide a hierarchy of iterators. Other languages like Haskell also provide compile-time polymorphism. And here we are in 2012 - there is an ad-hoc solution that only works in few browsers, and a proper one is only down the road.
Re: Binary data processing in JavaScript
#19Earlier quoted context omitted.
Any idea as to how other JS engines handle polymorphism?
I am not very familiar with internals of other engines. AFAIK both SpiderMonkey and Safari have polymorphic inline caches for a.foo property access sites. I can't say if the leverage PICs for a[i] access sites. But from what I see from a quick glance over JavaScriptCore sources they do not seem to handle any kind of polymorphism for a[i] kind of sites in their new optimizing compiler (aka DFG). Additionally they do s…
Thank you mraleph for suggesting these benchmark changes! We already looked at this a while back, but it doesn't look like we kept looking at it. https://bugzilla.mozilla.org/show_bug.cgi?id=650939
A quick look with the JIT inspector addon (https://addons.mozilla.org/en-US/firefox/addon/jit-inspector...) seems to tell me that a lot of performance is gated on the array[i] index access, which you already mentioned. Indeed the polymorphic lookups are hurting us very badly and I think we don't inline cache anything and always take stub call. (Screenshot: http://i.imgur.com/UKL0t.png) All the red sections are the very hot stubcalls.
We only IC properties of regular objects (but also with different shapes and offsets) and indexes into some optimized array kind. But _not_ typed arrays. We used to do this, but Type Inference is usually very good with "normal" usages of typed arrays.
Re: Binary data processing in JavaScript
#20Hmm, I must have a differing understanding of 'support' Global user stats*:Support: 52.22% Yet no version of IE supports it, that ranks support close to 0% IMO. I'm no IE lover, but lots of users still have it as their main browser.
All the more reason to move away from IE, if your market doesn't really require it :-)