Re:MindSpore WebAssembly Backend
by _bxg1 on Tuesday June 02, 2020 @12:28AM
(#23387458)
It's unfortunate that the terms "front-end" and "back-end" are so overloaded. In this case I thought they meant a compiler backend, but that doesn't make much sense in context because the "backend" would be that which targets WASM itself, which is not new. And then some might think they meant it in the web sense; i.e. something running on a server. But it sounds like there is actually yet another sense of the term, in the context of ML.
Re:MindSpore WebAssembly Backend
by leonwanghui on Tuesday June 02, 2020 @03:17AM
(#23388512)
Sorry for making the terms "front-end" and "back-end" ambiguous here, maybe I should have added some terminology context at beginning. In my initial thought, these two terms are named based on the machine learning framework. Front-ends normally indicate the user-oriented high level API (such like keras, PyTorch, MindSpore), and on the other hand the backend means the execution environment (CPU, GPU, Ascend, etc.) of operators.
In this context, what we want to build is a hardware-agnostic backend by leveraging WASM backend, not just the compiler backend, we want to deploy the generated *.wasm operator library across hardware platforms (Cloud, Edge, Mobile, IoT, etc). Does that make sense to you?
Re:MindSpore WebAssembly Backend
by _bxg1 on Tuesday June 02, 2020 @09:37AM
(#23390842)
It's not your fault! I'm sure if I were more familiar with ML it would've been clear. I just think it's amusing/unideal the way we've come to use those terms for so many different things.
This statement is a bit of a stretch. I don’t see where WASM is being used in mobile development, nor see it in wide use across the industry.
Will it be better than Model runtime with HTTP support?
As for non-web scenarios, WASI is still at early stage and can't beat any of mature compiler and runtime toolchains.