Hi @jfbastien ,

it would be good to get more details on your precise ideas. What's the use case, how do you work around it in C++, and how would wasm implementations do it?

Generally my use case is on building simulation software, on the computational part the limit being only the machine, thanks to C++, C/OpenCL and GPUs technologies.

On the front-end the stack HTML5+CSS+Javascript+Typescript has proven to be a valid,proven,portable way of developing mid-large complex applications.

The JS Web Stack (with the addition of a structured language like Typescript) is so good these days that I don't feel the need to resort to emscripten or try wasm for most applications.

I almost completely agree on the High Level Goals and the Webassembly Use Cases and even more on the Non-Web Embeddings Document.

WebAssembly will be a relevant technology (at least to me) if it will allow to be faster (to the bone of a native C app plus, say 5% overhead) use more memory and more freely, have ports/sockets fully implemented and allow to run threads like any normal OS does.

Wasm machine should be very slick in size, fast and predictive, so please don't stick into it a GC: GCs are the Ponzi Scheme of IT: you make debts and do not care about allocation up until it's too late and you loose cycles. Besides, if we have a superperforming wasm core machine then a GC can be built on top of it.

For the sake of slickness, I would progressively detach it from Javascript. If I have native compilers in any language then I don't need scripting and, anyway I could embed a Duktape/Lua/whatever simply by compiling in the C sources.

Somewhere on the Mozilla site I saw documents on inplementing wasm native DOM manipulation: I don't think it will be very useful since DOM manipulation is inherently sequential and it's one of the most time consuming aspects of the HTML5/CSS/JS stack: if I write superfast multithreaded wasm only to have my DOM changes serialized waiting in queue then all the performance is gone and it's better transpile some Typescript than using C/C++. In this case I'd favor direct OpenGL access (at first with some WebGL implementation then OpenGL native). Accessing the Graphic Card will prove useful to offer GPU/CUDA capabilities with small or no overhead.
(Just went to check on this and got issue #273 tackling on this)

Having a tiny wasm machine shared by every vendor and independants as well could solve the nightmare of mobile development, where you have at least 4 toolchains for different OSes and versions and architectures.
Graphic and input facilities could vary but we would be able to develop to one wasm and then query the facilities APIs , or even deploy the same application on different app stores.
On the long term: the same with server applications, reaching some kind of consensus on facilities (DB Connection Protocols and Pools, Yellow Pages Systems, Messaging Protocols and Systems etc) and packing them into some standard specification like JEE platform did. (A lot of the conceptual work has already been laid out in the last 20 yrs).

I don't expect you to come up with all the answers! Just what comes to mind now. Fwiw C++ has some proposal for stack limits. Check out the SG14 subgroup.

Sure I'll do.

Thanks for your patience and time.

Rob

Uh oh!

pThreads any ETA ? #992

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions