fast.js
fast.js copied to clipboard
codemix
Typed Arrays
Typed arrays have huge memory and cpu advantages over JavaScript Arrays.
Have you considered typed array usage? A project I'm working favors typed arrays over JavaScript arrays. Both for cpu speed and for memory efficiency.
And an extreme case, rather than using an Array of Objects, we use a single Object of Typed Arrays, where each variable in the object corresponds to a Typed Array. So foo[i].var === foo.var[i]. In a sense, it is struct-like.
@backspaces I'm interested in adding support for this but need to see some real usecases first, can you expand a bit more on your description?
I built a simple REST interface webpage here, open the console to see the output: http://backspaces.net/temp/memory.html The html page prints out how it all works.
Background: our project (http://agentscript.org) is doing large scale simulations. For example, a current seismogram analysis takes in 100M pixel grayscale data and converts it to a 100M entry array. I realize that's extreme, but its a job!
We first tried using our standard approach, an Array of Objects. Memory fails badly even at much smaller sizes. Then we thought: what if we convert from an AofO to a single Object of Arrays (OofA) where each variable is a typed array.
The results were spectacular! It sounds odd as hell, I realize that, but one you use it a bit, it becomes natural. And we can even sugar it so that it appears to be the older style. The huge surprise for us was not only the memory efficiency, but the actual speed.
For example, this works fine (make sure console open):
http://backspaces.net/temp/memory.html?type=Int8Array&length=1e6&count=1000 But the Array version breaks (AwSnap error) after a couple of hundred JS arrays (w/ JS numbers .. the array contains its index) http://backspaces.net/temp/memory.html?type=Array&length=1e6&count=1000 All our work is on Chrome or Canary latest.
But you can see the speed difference too. I know es7 plans to address structs and more use of typed arrays, but building simple utils are available in es5 and work fine.
.. and I just want to thank you for your work, its changed a LOT of our approach to Massive JavaScript!
-- Owen
On Wed, Oct 29, 2014 at 4:31 AM, Charles Pick [email protected] wrote:
@backspaces https://github.com/backspaces I'm interested in adding support for this but need to see some real usecases first, can you expand a bit more on your description?
— Reply to this email directly or view it on GitHub https://github.com/codemix/fast.js/issues/64#issuecomment-60901525.
One more note: after testing this a few times, the team got nuts with jsPerf, all good news. TL;DR: Typed arrays work well and are fast as well as memory efficient. And sugar is better than we thought too (getter/setter)
-- Owen
Simple filling of arrays, one typed, the other not http://jsperf.com/filling-typed-array-vs-array Another version but now more like our OofA approach http://jsperf.com/filling-typed-array-vs-array/2 Manipulating Arrays: remove one element and push another http://jsperf.com/typed-array-block-move Sugar to make OofA look like AofO http://jsperf.com/aofo-interface-for-oofa http://jsperf.com/aofo-interface-for-oofa/2 Finally lots of getter/setter tests done by others but good for AofO sugar http://jsperf.com/getter-setter/77
On Wed, Oct 29, 2014 at 12:00 PM, Owen Densmore [email protected] wrote:
I built a simple REST interface webpage here, open the console to see the output: http://backspaces.net/temp/memory.html The html page prints out how it all works.
Background: our project (http://agentscript.org) is doing large scale simulations. For example, a current seismogram analysis takes in 100M pixel grayscale data and converts it to a 100M entry array. I realize that's extreme, but its a job!
We first tried using our standard approach, an Array of Objects. Memory fails badly even at much smaller sizes. Then we thought: what if we convert from an AofO to a single Object of Arrays (OofA) where each variable is a typed array.
The results were spectacular! It sounds odd as hell, I realize that, but one you use it a bit, it becomes natural. And we can even sugar it so that it appears to be the older style. The huge surprise for us was not only the memory efficiency, but the actual speed.
For example, this works fine (make sure console open):
http://backspaces.net/temp/memory.html?type=Int8Array&length=1e6&count=1000 But the Array version breaks (AwSnap error) after a couple of hundred JS arrays (w/ JS numbers .. the array contains its index) http://backspaces.net/temp/memory.html?type=Array&length=1e6&count=1000 All our work is on Chrome or Canary latest.
But you can see the speed difference too. I know es7 plans to address structs and more use of typed arrays, but building simple utils are available in es5 and work fine.
.. and I just want to thank you for your work, its changed a LOT of our approach to Massive JavaScript!
-- Owen
On Wed, Oct 29, 2014 at 4:31 AM, Charles Pick [email protected] wrote:
@backspaces https://github.com/backspaces I'm interested in adding support for this but need to see some real usecases first, can you expand a bit more on your description?
— Reply to this email directly or view it on GitHub https://github.com/codemix/fast.js/issues/64#issuecomment-60901525.
typed arrays are not always faster than native arrays
Here's some benchmarks.
firefox
chrome
safari
The tests for glMatrix and for twgl. It's possible the tests or the libraries have some other optimizations needed to get typed arrays to beat native but if you check the tests, they generally try to avoid allocation the the libraries themseves, at least twgl and glMatrix are a single line change to allocate native arrays or typed arrays
Nice, interesting! Space is considerably better with TAs, but nice to see that performance is more subtle.