Should cpu fallback be run in parallel?

[jefffriesen]

When the gpu.js cannot run on a gpu and it falls back to cpu, I think it is single-threaded (if parallel, that would be awesome).

Have you considered using a cpu parallelization library like https://github.com/MichaReiser/parallel.es when the cpu is used? In theory, it would decrease the cpu time and make the performance gap between cpu and gpu closer. That's helpful for users of this library so they can creates a more reliable user experience. It makes using this library even more compelling.

For small arrays and simple computations, there may be a high overhead with with parallelizing the cpu. But I'm not sure why people would go through the trouble to write small, simple functions with gpu.js other than testing and experimenting. So large, complex functions that do well with parallelization seems to me like a reasonable target for this library.

There are several parallelization libraries, but Parallel.es is modern and very well thought out.

Do you think this is a good idea, bad idea or even practical to implement?

[PicoCreator]

Actually this is a work in progress regarding web-worker support.

Longer term wise also considering : #137 which is Web Assembly SIMD

[fuzzie360]

Nah, webworker support is #5

Currently on very low priority at the moment due to massive overhead caused by the lack of shared arrays (It's coming! https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer)

[PicoCreator]

Oops, ur right, brain misfired. 137 is SIMD haha

[robertleeplummerjr]

It is a fantastic concept, and if you would like to help, by all means jump in and join the fun!

[jefffriesen]

Ok, great. I'll close this issue since it's captured in other ones. I'll keep an eye on this repo and jump in if I can.

If we are waiting on SharedArrayBuffers, it's looking pretty good:

Chromium: In development
Firefox: In development
Edge: In development
Safari: Shipped

https://www.chromestatus.com/feature/4570991992766464

[robertleeplummerjr]

I heard @PicoCreator talking about possibly getting WebWorkers running before v1, which is very VERY soon going to land.

[SMotaal]

I just have to mention that I've been working with SharedArrayBuffer in both Safari and Chrome, it has been a major performance booster for parallelization, but the only drawback is that if you are aiming to use an application wrapper (I use Electron) then u are in trouble if u are using web workers even with SharedArrayBuffers because the flags applied to the rather outdated chromium is not as effective. (In Chrome 59 public with the experimental SharedArrayBuffer flag set to default - as is - SharedArrayBuffer exists in Window, so it defaults to true like it does in 60+ canary - I guess the delay was not V8 related but simply the integration with blink)

I did workout a design pattern that would gracefully fallback to ArrayBuffer and deal with Transferrables without conditional statements in every postMessage.

So a suggestion is to develop for it, even if some targets need a flag, let it be known that this is a potential extra step for developers, but ultimately, SharedArrayBuffers are as good as ready and worth it!

[jefffriesen]

Good to know, both that it's boosts performance and the issues around Electron. I also use Electron often. Thank you.