Live data from Hacker News

Why Object of Arrays beat interleaved arrays: a JavaScript performance issue

royalbhati.com

21–23 of 23 posts

Re: Why Object of Arrays beat interleaved arrays: a JavaScript performance issue

#21
post #19

Earlier quoted context omitted.

I suspect it's just circumstantial - two different design approaches. Both of the approaches have their advantages and disadvantages. IMHO the bigger issue with NaN-boxing is that on 64-bit systems it relies on the address space only needing On the other hand, I love the fact that NaN-boxing basically lets you eliminate all heap allocations for doubles. I actually wrote a small article a while back on a hybrid approa…

> IMHO the bigger issue with NaN-boxing is that on 64-bit systems it relies on the address space only needing Is this right? You get 51 tag bits, of which you must use one to distinguish pointer-to-object from other uses of the tag bits (assuming Huffman-ish coding of tags). But objects are presumedly a minimum of 8-byte sized and aligned, and on most platforms I assume they'd be 16-byte sized and aligned, which mean…

There's a bit of time yes, but for an engine that relies on this format (e.g. spidermonkey), the assumptions associated with the value boxing format would have leaked into the codebase all over the place. It's the kind of thing that's far less painful to take care of when you don't need to do it than when you need to do it.

But fair point on the aligned pointers - that would give you some free bits to keep using, but it gets ugly.

You're right about the 51 bits - I always get mixed up about whether it's 12 bits of exponent, or the 12 includes the sign. Point is it puts some hard constraints on a pretty large number of high bits of a pointer being free, as opposed to an alignment requirement for low-bit tagging which will never run out of bits.

Re: Why Object of Arrays beat interleaved arrays: a JavaScript performance issue

#22
post #13
post #12

I had a similar problem when I was making a tool processing a lot of data in the browser. I'd naively made a large array of identical objects each holding a bunch of fields with numbers. Turns out, this works completely fine in Firefox. However, in Chrome, it produces millions of individual HeapNumber allocations (why is that a thing??) in addition to the objects and uses GBs of RAM, and is slow to access, making the…

Yeah, this is a historical design difference between Firefox's Spidermonkey JS engine and Chrome's V8. Spidermonkey uses (I'm simplifying here, there are cases where this isn't true) a trick where all values are 64-bits, and for anything that isn't a double-precision float they smuggle it inside of the bits of a NaN. This means that you can store a double, a float32, an int, or an object pointer all in a field of the…

48/56 bits numbers would be useful in many circumstances

Re: Why Object of Arrays beat interleaved arrays: a JavaScript performance issue

#23
That Structure of Arrays performs much better than an Array of Structures is a very well known tidbit since long ago; what I'd love to read more is about how people design code around this fact.

For bigger codebases where you might not even be the person (or team) who designed the data types, and are just given a class or struct that needs to be collected into a large array, it's not simple to just decompose structures into an array per property.

In fact, this is a basic thing to want to do, but I've seen no language support for it ever. (in popular / industry frequently used langs). The `FancyList` idea from another comment is indeed interesting, but it would require reflection I guess.

Post reply on HN