Long time ago wanted to so something good and took a part in W3C webmachinelearning standardization group. Inspired by simplicity of brain.js wanted browser API to offer something similar to it - simple and easy to learn and easy to understand, also wanted a training API to be available. It is possible to keep simplicity of brain.js and flexibility of any other op set. And my oh my - did hit the wall HARD! Paid seats in W3C rules. They do what they want there. Your voice there matters only if it aligns well with their voice. Browsers API is now their own domain and whenever there is a conflict of interest their choice is obvious.
If you don't get buy-in from the actual browser vendors, they can just ignore your W3C standards. Buy a couple drinks for the Chrome engineering and product managers and your problem will be solved.
Webmachinelearning sounds like a problem nobody has. Why would I want a standardized browser API for doing stuff that I can obviously already do without such an API?
I ABSOLUTELY loved this project and used it for all of my "quick and dirty" ML stuff where I was fooling around... the only problem, which I don't think has been fixed is that it still requires *Python 2.7*.
That being said, if you're not building from source (you're running an LTS version of node on a supported platform), you don't need to worry about python or many of the build deps.
As others say, it's headless-gl, and that in turn seems to be due to node-gyp.
However the good news seems this is probably more a case of documentation inertia than actual requirements: it looks like you actually can install a version of node-gyp that works with Python 3.x and then in turn should be able to get headless-gl working too, which then let's brain.js work with a non -EOL version of Python
See also https://github.com/webonnx/wonnx, which runs ONNX models through WebGPU. It is written in Rust and can be used natively on Windows, macOS and Linux (through wgpu which uses either DX12, Vulkan or Metal) or on the web (it has a JS API that uses WASM under the hood, which calls into the browser’s WebGPU API). There is a Python module as well.
I've ran across this before, but haven't figured out if a GPU is required to use it. That would be a deal-breaker for any consumer facing web app right?
It will work with software implementations (e.g. llvmpipe/lavapipe is used in CI). That will be slower though. However you’d be surprised at how many devices have a usable GPU. Not all have NVIDIA RTX’es of course, but a simple iGPU will do. I tested it on a fairly low specced Dell office PC with an Intel Iris iGPU and that works just fine. Also most mobile devices will have a GPU these days.
Thanks! it looks like the wonnx CLI itself falls back to tract to do inference on CPU if a GPU is not available[0], and it also sounds like setting up llvmpipe/lavapipe on WASM is much harder (if not impossible?) than just shipping tract, so the approach I'll take is probably a wonnx+tract approach.
I'm curious if there are many scenarios where a CPU fallback, especially javascript based, would have acceptable performance when a GPU is not present. Is that even really a solution?
I'm not far enough into my project to know for sure, but I think that, for example, using tract to do speech recognition can be done in sub-realtime (ie, the inference takes shorter than the audio duration) on a Macbook M1 Pro. Hopefully on less powerful devices too, but I haven't tested that yet.
There's also tract, from Sonos[0]. 100% Rust[1].
I'm currently using it to do speech recognition with a variant of the Conformer architecture (exported to ONNX).
[1] To be clear, I'm not saying that writing in Rust is some inherent advantage for an NN inference engine. But I personally gravitate to using libraries written in languages I know/want to learn, and Rust might be that for some people.
For inference, models should be compiled down directly to WASM or WebGPU or whatever, right? The driving language really shouldn't matter at the end of the day.
Unless you've got massive compute bound transformers or old-school full convolutions, if you're interpreting a list of operations you're going to lose perf.
> For inference, models should be compiled down directly to WASM or WebGPU
I mean, yes? Whether for inference or for training, ML operators are usually implemented in compiled low level languages. That implementation might also take advantage of GPUs.
> ... if you're going interpreting a list of operations ...
I'm not sure what "interpreting a list of operators" means here.
To clarify why I mentioned the implementation language, I recently had to modify the source code of Tract to get my model running (I will push that change upstream at some point). I would not have (been able to do that), had tract been written in C++, for example.
So being semi-retired (unable to find work due to 10yr+ past background issues)
and living in Vegas, I've really given serious thought to building some sort of NN to help with gambling in general and specifically the picking of horses (or perhaps even baseball outcomes).
I can't help but think that buried in all the race data their are correlations that are impossible to figure with standard statistical methods but can be sussed out using NNs. Of course I am vaguely aware that many people are already using NNs to predict race outcomes, but I am purposely trying to keep that info at arms length as I don't really want to be negatively influenced existing attitudes.
However, if someone does happen to know of a good NN/horseracing blog that has a positive outlook and is making money, I would be interested in such a site.
Anyway, this type of easy-to-use NN could be exactly what I'm looking for with getting started on this project, and once again, I would be interested in hearing about the pros and cons of using such a lightweight easy-to-use NN for my explorations.
There might not be enough data to train a NN, and it's probably prone to overfitting the model. It's a similar problem to using NN to predict the stock market. You might have better luck with shallow learning statistical techniques that require less data to train a model.
Tangentially, I'm just curious, is it something that appears in your criminal background check that causes you to not receive offers? Or is it a lack of interviews due to gaps on a resume?
I am a firm believer that if someone demonstrates they have motivation and skill in a writing sample, they deserve an interview. If that person then passes a technical interview, they deserve a job. And if that person is friendly and does not commit any crimes while working, they deserve to keep that job.
what do you think the bookmakers are using to set the odds?
If you don't have a PHD level and a large amount of money to start with, don't even try to think about it.
I've spent a few months tinkering with this kind of stuff, with a huuuge dataset, my simulations never went past the annual return of an average ETF, and by eliminating 99/99.5% of bets possible, so you'd only have a few bets that are worth it per month, a bad streak would ruin your return for the year, and you'd have to have access to a lot of bookmakers to get the best odds.
I had that url active for over 5 years here and never once was contacted by anyone interested in talking to me about a project, so forgive my cynicism with not being very concerned about keeping it alive.
Fpr the sake of not being a total jerk about it, however, I will take it down soon....thanks for reminding me btw!
I’m still learning about a lot of this stuff so apologies if this is wrong.
Isn’t part of the motivation for using deep learning that it can actually generalize over that many parameters? My understanding is that classical statistical models are prone to overfitting on data as you add more parameters to the model. Deep learning tries to learn the underlying distribution of data, enabling predictions not found in the dataset that still match the underlying positional statistics of the dataset.
In that context I’d say the comparison is apt. It’s not just throwing more compute at the problem - it’s doing so in a way that actually achieves scalable accuracy gains. With pre training and self-supervised learning, you can (feasibly) train such a model without even needing to understand statistics.
"The library provides access to machine learning algorithms and models in the browser, building on top of TensorFlow.js with no other external dependencies."
The mobile site needs some work. Why is the hero present on every page, not just the lander? On mobile firefox the flex box in the hero is not wrapping like it should. In terms of marketing and communication, you need to specify up front what lib is being used for the gpu accelerated parts. Can I do everything with this as I could with, say, pytorch, except in js?
> It’s pretty much a certainty that a web standard for eager-mode machine learning will spring up when WebGPU comes online
I can agree on this point. The fusion of the browser and the GPU will likely open up some new pathways to ML concepts that were previously impeded.
At the same time, is there a possibility that websites begin implementing heavy GPU operations at scale, in the same way that SPA webapps are heavy on memory today?
I think a js framework doesn’t make sense because all people I know dealing with dnns using python as base language. I’m also working on something very similar and I think my stack is a lot better because I used pyodide + webassembly + webgpu . So far, I managed to implement a very small grad based dnn framework with couple of ops. (like matmul, etc.)
One of the limitations is that webassembly vm has 4gb address space. This could be a problem during loading/unloading from/to gpu.
