Collaboration? HSA Compute

[austinksmith]

Hello there, I'm the creator of Hamsters.js a 100% vanilla parallel execution library using web workers, one of my original goals for the project was to hopefully be able to leverage webGL via compute shaders but never really got around to it.

I see great strides have been made in this regard with GPU.js and I want to do the following.

1. Say great work!, its awesome to see more compute capacity brought to the web

2. Propose a collaboration initiative where we combine the best features of our libraries into a unified HSA compute system, this would essentially mean the following.

3. When executing logic the system can leverage GPU and CPU resources at the exact same time to complete a single problem, this would mean for example utilizing the GPU via webGL compute shaders to complete say 50% of the solution while in parallel utilizing all 8 or 16 CPU threads to complete the other half of the problem, this should result in an extremely massive performance increase for certain problems.

4. My library already incorporates a fully working thread pool system, using a parameter based execution system problems could be dedicated to the GPU or the CPU or both depending on what is the optimal resource allocation for the problem at hand with on the fly dynamic switching between GPU and CPU and even spread pieces of execution to the GPU while the CPU works on other parts

5. Bring true HSA capability into a single unified architecture that allows us developers to extract 100% of the resources available in a system with a single simplified API.

You can read more about HSA and the promises it holds here http://www.hsafoundation.com/ , I think if it was done correctly this could have a major impact on the future of web development (possibly negating the need for things like web assembly).

[austinksmith]

I've gone ahead and created a repository to start this initiative, I would love your assistance with this though I will forge ahead either way.

https://github.com/austinksmith/HSA.js

The work I write is always published under the Artistic 2.0 license so I can maintain control of the direction the software takes into the future, any parts of the app logic that you want released under a different license would need to be sub licensed as a dependency of the HSA.js library logic.

I've based the structure off of webpack (not v4), this is also setup for jasmine testing, uglify, minify etc. It's the same structure I built for Hamsters.js, though uses GPU.js and Hamsters.js as dependencies of the HSA.js library.

The goal here is to create an abstraction layer that marries the abstraction provided by GPU.js and Hamsters.js in a way that allows work splitting between both devices, any advice will definitely be taken into account as my experience with webGL is lacking to say the least.

[robertleeplummerjr]

I look forward to offering a better reply, just been busy with work and brain.js. The next thing I have planned is to finish opencl integration, and then we'll have machine learning in the entire Javascript ecosystem. Will come back for more complete thoughts tomorrow. Ty for not dropping this from the silence.

[robertleeplummerjr]

This is one of those "with great power comes great responsibility" threads. This silence was from thought and seriousnes not ignoring great initiative.

[austinksmith]

No problem at all, I honestly don't think the lift for this is going to be too bad in the end. Ultimately it just comes down to providing some built in abstraction layer or the most common use cases that gpu.js can handle, Hamsters.js is pretty much infinitely flexible in the operations it handles or the amount of threads it's using so we will need to limit the operations to the subset of features that GPU.js provides.

The more I think about this, the more I am thinking this will probably just expose some methods like ie.

hsa.matrix.multiply([maxtrix1, matrix2]);

Where matrix.multiply does something like..

1. Splits the data in half or into chunks at a ratio that is defined at library initialization or as a parameter passed to the library when invoking a function
2. Using a similar implementation to what I made in Hamsters.js, the first half is sent to be executed on the GPU using the same logic that is required to use GPU.js while the other half of the data is sent to Hamsters.js using the same logic that is required to use the library normally. My library will handle parallelization for loops automatically across all threads so the second half will in the end be broken down even further into smaller pieces
3. Returns a single output, regardless of which pieces of the original data finish first

Results from the GPU and CPU will return out of order and asynchronously, this isn't a problem I can handle output coordination so it's all seamless to the end user and also implement a task pool so many tasks can be added to the system at once keeping resources busy