-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Web machine learning @ W3 #337
Comments
Hi @DanielMazurkiewicz! This does sound awesome. Have you looked at https://github.com/BrainJS/brain.js/wiki/Roadmap as well? This is our 2.0 roadmap. We're currently implementing it, and we're starting planning on v3, here: #317. I'm interested in this, but it will take more energy than just me. If we are going to do this, we need to form a team of willing volunteers, that can help respect the ideas of both simplicity and the needs that such a standard would require. Just curious, and wanted to start the discussion. |
Hi @robertleeplummerjr !
Yes, I've seen it. I don't know how about you, but I would like NN to be easily exchangeable not only within JavaScript runtimes, but also with other programming languages, and for that JSON format of storing NN architecture (also for recurrent NN) is much better in my opinion. So as for the new versions of Brain.js I would prefer more JSON descriptive formats instead of any sort of callback functions or somewhat "layer objects". That is why I proposed to feed NN constructor with property "layers" that looks like that: DanielMazurkiewicz/WebAI@a5578b1 As for using OpenCL plans, that sounds great!
Totally agree! For me it is not a question "if" - I've already started supporting and promoting brain.js like api for W3 NN standard. I think the more people supporting brain.js will sign to W3 to that project, the more chances to get the standard falling into Simplicity and Performance First phrase. It doesn't require much to sign and sometimes a share opinion. Is it ok for you to place sort of appeal to participate in standard preparations in read.me of Brain.js? So users of brain.js could also share their opinion? |
You share my desire, and I feel a large part of the community's as well. I've always wanted to do a quick port to c++, c#, java, and php, just for the sake of offering an easy api to everyone.
Short answer: I love this strategy! This actually is already mostly adopted in the Further reading: Something I want to be clear about with the roadmap for v2 and why v2 is important: It describes one of the simplest means of instantiating the net directly, as I'm sure you know. This allows one to even build their own layers. The layers, in other words, aren't dependent on the net, and the net on the layers. You can shim in your own, or use what is there.
Why not become familiar with gpu.js, the underlying engine with brain.js, and provide an architecture layer that does this, then offer it to the world? That would be awesome! There are already 3 backends, with one coming (Headless WebGL) here: https://github.com/gpujs/gpu.js/tree/develop/src/backend Simple js in, GPU computation out. Wicked fast, wicked easy.
OpenCL in GPU.js was seen as simply another backend, or driver. That isn't to say you that if we had an OpenCL module, everything node side would have to go through OpenCL. It is simply a driver. If another backend was provided, we'd simply use that, like Vulken. All the hard stuff is worked out, like type detection, javascript transpilation to whatever language you like, etc.
GPU.js already does this.
Very encouraging to hear!
I agree! One of the biggest needs is being open to new ideas from the community. They have some pretty fantastic ones. Also, not to be afraid of sticking up for an idea with logic backing it. Although simple, it has been one of the neatest things to see in practice for brain.js and open source.
I welcome it. |
We are on same page here. But if it comes to standardization that additionally should work among variety of different hardware (cpu, gpu, dsp, fpga...) I think it is easier to stick to JSON that can be quite easily "compiled" to work on selected hardware, than having a custom JS code that will have to run somewhere in between hardware and JS runtime. I think better to focus on JSON descriptive format to be as flexible as possible (if it comes to standardization of course). In some later phases of upgrading standard it could add some more sophisticated techniques that could use custom JS inside standardized ML. Vulkan and deep down performance is entire big another topic :-) , so maybe lets split here and summarize what I/we expect from W3C standardized API:
|
Just a small reminder to anyone who want to share his knowledge/opinion/give likes/dislikes ;-): |
Ty @DanielMazurkiewicz for the update! |
Guys (and Girls? :-) ),
There is W3 community that tries to work out a standard for machine learning for web. It is great idea, but I'm strongly afraid that they will make another crappy standard that we all will have to live on later. I find Brain.js API very close to something I would expect from standards for web scripting - simple to use, simple to learn, doing its work. I'm worried also that W3 group will overcomplicate standard so we will have to wait for it couple of years to see in browsers. I think it would be much better to make firstly quick basic ML standard and then second version that extends it with all kind of "low level" and "super scientific" ML capabilities.
I want you all to get involved to avoid mentioned problems. You're doing great work with Brain.js! With your experience and expertise (or just voting power) we could push it forward so standard could be quickly adopted as something that is close to Brain.js. Something that developers could quickly adopt without tons of code and studying.
If you decide to get involved go to:
https://www.w3.org/community/webmachinelearning/
https://github.com/webmachinelearning/webnn/issues
I personally see ML api for www as something like that: https://github.com/DanielMazurkiewicz/WebAI, but anything close to Brain.js should be simply good.
Don't wait for the standard, make it! :-)
Cheers!
The text was updated successfully, but these errors were encountered: