9 ms·

Binary data processing in JavaScript

18 points by varunkumar 14y ago

jacobolus 14y ago
This test should also add strings where the least significant byte of each character is used a byte (i.e. '\x00' = 0 up through '\xff' = 0xff). For many operations, these end up being faster than arrays of numbers.
- varunkumar 14y ago
  But, the immutable nature of strings should slow down the whole conversion right? Correct me if I am wrong.
tezza 14y ago
Hmm, 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.
- masklinn 14y ago
  > I must have a differing understanding of 'support' One which makes no sense apparently. > Yet no version of IE supports it Which is why global user support is 52%: 48% of users have browsers which do not implement typed arrays.
- varunkumar 14y ago
  Its 52.22% after considering the usage of IE. Otherwise, it would have 90+
- Posibyte 14y ago
  > I'm no IE lover, but lots of users still have it as their main browser. About as many users have browsers that support typed arrays as those who don't. > Yet no version of IE supports it, that ranks support close to 0% IMO. While the former is true, I don't see how you came to the latter.
- chris_wot 14y ago
  All the more reason to move away from IE, if your market doesn't really require it :-)
mraleph 14y ago
Couple 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 causes it to become polymorphic --- which affects the generated code. V8 became much-much better in handling polymorphism of this sort, but if you'll create a test_SMTH_ARRAYTYPE for each combination of test and array type you'll see results not distorted by the polymorphism.
- varunkumar 14y ago
  Thanks for pointing out these things. I will amend the test and try to re-run these cases.
- varunkumar 14y ago
  Any idea as to how other JS engines handle polymorphism?
  - mraleph 14y ago
    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.
    - varunkumar 14y ago
      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.
kombine 14y ago
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.
- mraleph 14y ago
  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 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.
  - kombine 14y ago
    "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.
chris_wot 14y ago
Jdataview 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... 1. http://news.ycombinator.com/item?id=3953368 http://news.ycombinator.com/item?id=3953368
azakai 14y ago
A few things to add to this discussion about typed arrays: 1. The list of support statuses does not seem to reflect that Float64Array was missing from Safari until recently, and I think might still be missing from mobile Safari. 2. Typed array performance of Uint32Arrays can differ from the other integer array types: unsigned int values do not fit in 31-bit signed integers, which is what most JS engines optimize ints for. This is most significant in V8 which does not use NaNboxing, so when it sees a big integer it makes it a boxed double, leading to bad performance, see for example http://code.google.com/p/v8/issues/detail?id=2097 http://code.google.com/p/v8/issues/detail?id=2097 Looks like the benchmarks done here did not check those values, but they happen a lot in practice with things like compiled C code. 3. Aside from points 1 and 2 overall typed array support and performance are predictable and good across browsers (sans IE, but hopefully with IE10). Aside from random access there is also the .set() method which lets you copy large amounts of typed data efficiently as well (which was not benchmarked here, but should basically be a memcpy so likely consistent across browsers).
- mraleph 14y ago
  > This is most significant in V8 which does not use NaNboxing, so when it sees a big integer it makes it a boxed double NaN-tagging has nothing to do with the issue you are linking to e.g. in V8 does not allocate a boxed double for every floating point value it reads from Float64Array. Let me expand my own comments [vegorov@chromium.org] from the issue, so that the problem V8 has becomes more understandable. The reason for the Issue 2097 is somewhat "patchy" support V8 has for uint32 values in the optimized code. uint32 value in JavaScript has somewhat a dual nature: it can be treated bitwise as an signed int32 as long as it participates in truncating operations[1]; but once it escapes into unsafe place where its "unsigned-ness" can be observed it might have to become a full double if it does not fit into positive part of int32 range. V8's optimizing pipeline does not have a proper analysis to determine where uint32 value can efficiently be represented as int32 without affecting semantics. It also does not want to pessimistically represent all values read from Uint32Array as doubles so it just chooses to assume non-truncating int32 representation for them and as a result code deoptimizes when it sees a value that does not fit [another bit that is missing here is type-feedback on keyed load IC that would tell hydrogen that he is too optimistic in its assumption]. V8 actually has the same problem with x >>> 0. [1] - examples of truncating operations are: bitwise ops, stores into integer typed arrays and arithmetic operations when they do not overflow beyond 53bits and their results are used only in truncating operations;
chmike 14y ago
What is the status of the blob data type ?

18 points by varunkumar 14y ago

This test should also add strings where the least significant byte of each character is used a byte (i.e. '\x00' = 0 up through '\xff' = 0xff). For many operations, these end up being faster than arrays of numbers.

varunkumar 14y ago
But, the immutable nature of strings should slow down the whole conversion right? Correct me if I am wrong.

tezza 14y ago

Hmm, 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.

masklinn 14y ago
> I must have a differing understanding of 'support' One which makes no sense apparently. > Yet no version of IE supports it Which is why global user support is 52%: 48% of users have browsers which do not implement typed arrays.
varunkumar 14y ago
Its 52.22% after considering the usage of IE. Otherwise, it would have 90+
Posibyte 14y ago
> I'm no IE lover, but lots of users still have it as their main browser. About as many users have browsers that support typed arrays as those who don't. > Yet no version of IE supports it, that ranks support close to 0% IMO. While the former is true, I don't see how you came to the latter.
chris_wot 14y ago
All the more reason to move away from IE, if your market doesn't really require it :-)

mraleph 14y ago

Couple 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 causes it to become polymorphic --- which affects the generated code. V8 became much-much better in handling polymorphism of this sort, but if you'll create a test_SMTH_ARRAYTYPE for each combination of test and array type you'll see results not distorted by the polymorphism.

varunkumar 14y ago
Thanks for pointing out these things. I will amend the test and try to re-run these cases.
varunkumar 14y ago
Any idea as to how other JS engines handle polymorphism?
- mraleph 14y ago
  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.
  - varunkumar 14y ago
    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.

kombine 14y ago

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.

mraleph 14y ago
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 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.
- kombine 14y ago
  "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.

chris_wot 14y ago

Jdataview 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... 1. http://news.ycombinator.com/item?id=3953368 http://news.ycombinator.com/item?id=3953368

azakai 14y ago

A few things to add to this discussion about typed arrays: 1. The list of support statuses does not seem to reflect that Float64Array was missing from Safari until recently, and I think might still be missing from mobile Safari. 2. Typed array performance of Uint32Arrays can differ from the other integer array types: unsigned int values do not fit in 31-bit signed integers, which is what most JS engines optimize ints for. This is most significant in V8 which does not use NaNboxing, so when it sees a big integer it makes it a boxed double, leading to bad performance, see for example http://code.google.com/p/v8/issues/detail?id=2097 http://code.google.com/p/v8/issues/detail?id=2097 Looks like the benchmarks done here did not check those values, but they happen a lot in practice with things like compiled C code. 3. Aside from points 1 and 2 overall typed array support and performance are predictable and good across browsers (sans IE, but hopefully with IE10). Aside from random access there is also the .set() method which lets you copy large amounts of typed data efficiently as well (which was not benchmarked here, but should basically be a memcpy so likely consistent across browsers).

mraleph 14y ago
> This is most significant in V8 which does not use NaNboxing, so when it sees a big integer it makes it a boxed double NaN-tagging has nothing to do with the issue you are linking to e.g. in V8 does not allocate a boxed double for every floating point value it reads from Float64Array. Let me expand my own comments [vegorov@chromium.org] from the issue, so that the problem V8 has becomes more understandable. The reason for the Issue 2097 is somewhat "patchy" support V8 has for uint32 values in the optimized code. uint32 value in JavaScript has somewhat a dual nature: it can be treated bitwise as an signed int32 as long as it participates in truncating operations[1]; but once it escapes into unsafe place where its "unsigned-ness" can be observed it might have to become a full double if it does not fit into positive part of int32 range. V8's optimizing pipeline does not have a proper analysis to determine where uint32 value can efficiently be represented as int32 without affecting semantics. It also does not want to pessimistically represent all values read from Uint32Array as doubles so it just chooses to assume non-truncating int32 representation for them and as a result code deoptimizes when it sees a value that does not fit [another bit that is missing here is type-feedback on keyed load IC that would tell hydrogen that he is too optimistic in its assumption]. V8 actually has the same problem with x >>> 0. [1] - examples of truncating operations are: bitwise ops, stores into integer typed arrays and arithmetic operations when they do not overflow beyond 53bits and their results are used only in truncating operations;

chmike 14y ago

What is the status of the blob data type ?