I find nested function calls like these very hard to comprehend.
I would like intermediate variables and comments explaining what is happening and why. Make it flat.
let shape = [1,-1,1,1];
# line up shapes.
mean = nn.reshape(mean, shape)
variance = nn.reshape(variance, shape)
scale = nn.reshape(scale, shape)
bias = nn.reshape(bias, shape)
# calculate 1/sqrt(variance); add an epsilon to prevent dividing by 0
epsilon = nn.constant(epsilon)
inv_var = nn.rsqrt(nn.add(variance, epsilon))
# batchnorm, I think?
x = nn.sub(input, mean),
x = nn.mul(x, inv_var)
x = nn.mul(x, scale)
x = nn.add(x, bias);
return x
It's a common pattern. E.g. IETF has "informational" and "experimental" RFCs, which also are not standards, and I'm not aware of major problems with that.
iOS is still missing basic web app functionality. Can W3C focus on actually getting their proposals adopted instead of just churning out more crap that only has a future in Chrome?
I know this is mostly an Apple problem but I’m proposing the working group do more to apply pressure if it all possible.
Doubly so, now that schools run on it. That base familiarity carries further than people realize. You start pushing that OS in when kids are 5-10 and they'll just think that's what a computer should be. My kid would if I didn't "force" him to look at his library app on my linux box.
The sad part is it will be used for more focused targeting, rather than for benefit, we have people abusing Canvas and audio context.
I dont want companies to timestamp me by my face, to prove I like their content, or a dumb captcha API that decided im not a human because I'm darker. No please.
This API does not implicitly give access to the camera or photos. The things that you are concerned about are already possible by doing the NN part server-side, or less efficently in software. If anything, keeping the NN part on the client allows for more privacy, not less.
Why making this a Web API, rather than a library? We have WebAssembly threads which allows high-performance multi-threaded CPU code and WebGPU for general purpose GPU code.
Please correct me if I'm mistaken (not a ML expert): On top of these existing APIs, we can build efficient neural networks. Of course, we wouldn't be able to use specialized hardware such as Google's TPU or Graphcore's IPU, but I doubt there's a use-case for those in web.
Is there any non-GPU/CPU based consumer hardware aimed at fast neural networks that I'm missing?
EDIT: Seems "NPU"s have been slowly arriving for the past 2 years to iOS/Android-based devices... Maybe there's a raison d'être for the WebNN API after all.
Thank you, I didn't know that! It feels scary to see that all these NN APIs are appearing around the fact that we cannot talk to DSPs, NPUs, GPUs, CPUs under a same language. By creating such highly-specialized APIs it feels like "giving up" on ever accomplishing that.
Decades ago, compiler developers solved dealing with multiple CPU architectures, by creating languages that succinctly expresses their common traits: Doing arithmetical-logical operations and accessing memory. Languages like C abstracted us from CPU registers, stacks. Optimization passes like vectorization abstracted us from different ISA extensions.
Now it feels it's the same issue all over again.
Is it really hard to simply express: `x' = W*x + b` and let the compiler target the CPU/GPU/NPU as needed?
That is what stuff like SYSCL, CUDA and Halide allow for, but I guess the Web can have only one and WebAssembly won't be exposing what they need to work with anyway.
I kind of like the idea of having a common API for the common neural network ops, if only as an intermediate layer between pytorch and tensorflow.
But that's more an expression of API design than any particular reason.
Once TPUs can run JS (which may be coming sooner than it seems), it might also be reasonable to write a "webpage" which TPUs then "execute".
I think neural networks in general need to learn to be more flexible. Right now it feels like you're carving a network out of marble. It should be more like clay.
More practically, tensorflow.js does run in the browser; you could port this API to a tf.js backend.
I don't think the WebNN API is trying to solve this problem, are they? Skimming through the specification, WebNN provides a way of describing the topology of a neural network, and compile+run it on different hardware (DSP, NPU, GPU, etc). However, the parameters of the network (which are by far the largest part) have still to be provided.
In today’s “new and unnecessary things nobody asked for” news segment.
Controversial, but stapling in unnecessary machine learning as a web api when we already have enough performance issues with web apps as it is. Anyways, why go to the effort of this, when if you really wanted to run ML models on the front-end you could use ONNX (a format designed already for portable network serialisation) and WASM.
I skimmed through the document but I didn't understand if the model is local. That would be nice. If that's the case I guess it will also define a format for models.
31 comments
[ 0.20 ms ] story [ 90.6 ms ] threadI'm skeptical the reshaping is even necessary. Any reasonable framework should broadcast those shapes automatically.
Microsoft should've not been allowed to join the W3C.
It's a community group document, so not a standard and not on the way to become one.
Second, W3C function as a standard promoter is compromised when it allows its members to make use of draft/private proposals as ersatz standards.
I know this is mostly an Apple problem but I’m proposing the working group do more to apply pressure if it all possible.
> The application is watching whether she is in front of her PC by using object detection
Please correct me if I'm mistaken (not a ML expert): On top of these existing APIs, we can build efficient neural networks. Of course, we wouldn't be able to use specialized hardware such as Google's TPU or Graphcore's IPU, but I doubt there's a use-case for those in web.
Is there any non-GPU/CPU based consumer hardware aimed at fast neural networks that I'm missing?
EDIT: Seems "NPU"s have been slowly arriving for the past 2 years to iOS/Android-based devices... Maybe there's a raison d'être for the WebNN API after all.
Decades ago, compiler developers solved dealing with multiple CPU architectures, by creating languages that succinctly expresses their common traits: Doing arithmetical-logical operations and accessing memory. Languages like C abstracted us from CPU registers, stacks. Optimization passes like vectorization abstracted us from different ISA extensions.
Now it feels it's the same issue all over again. Is it really hard to simply express: `x' = W*x + b` and let the compiler target the CPU/GPU/NPU as needed?
But that's more an expression of API design than any particular reason.
Once TPUs can run JS (which may be coming sooner than it seems), it might also be reasonable to write a "webpage" which TPUs then "execute".
I think neural networks in general need to learn to be more flexible. Right now it feels like you're carving a network out of marble. It should be more like clay.
More practically, tensorflow.js does run in the browser; you could port this API to a tf.js backend.
Controversial, but stapling in unnecessary machine learning as a web api when we already have enough performance issues with web apps as it is. Anyways, why go to the effort of this, when if you really wanted to run ML models on the front-end you could use ONNX (a format designed already for portable network serialisation) and WASM.
This example uses the current polyfill and it's local.