Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WASM as a Platform for Abstraction

adventures.michaelfbryan.com

Post reply on HN
Print view View original

11–20 of 85 posts

Re: WASM as a Platform for Abstraction

#11

Post by jahewson »

dmitriid wrote: post #3
xuejie wrote: post #2

While I do agree WASM makes a lot of sense for the Web, I personally am having doubts regarding treating WASM as a general abstractions for native code as used in the post. For this case, it might suit the job better to have a bytecode that resembles more of underlying machine architecture, rather than a still highly abstracted model like WASM. Please don't get me wrong, I do agree WASM is already one step ahead of,…

Besides, doesn't LLVM already have an IR which servers as one such higher-level abstraction?

Google created pretty much this, called it PNaCl and shipped it in Chrome. It now has been retired in favor of WASM.

Re: WASM as a Platform for Abstraction

#12

Post by xuejie »

cjbprime wrote: post #9
xuejie wrote: post #2

While I do agree WASM makes a lot of sense for the Web, I personally am having doubts regarding treating WASM as a general abstractions for native code as used in the post. For this case, it might suit the job better to have a bytecode that resembles more of underlying machine architecture, rather than a still highly abstracted model like WASM. Please don't get me wrong, I do agree WASM is already one step ahead of,…

It sounds like you're bringing up a register-based vs stack-based VM argument, and claiming that register-based VMs have better performance because their model is closer to the hardware. My understanding is that this intuition is usually untrue, because a JIT benefits from the stack-based code preserving code flow and thus allowing more efficient code generation.

No I'm not talking about register-based vs stack-based VM, that's a totally different topic. I'm just saying WASM is still quite distant from real hardware, making it a non-trivial task to performantly run the code. In fact if you look at the asm.js, which is the original inspiration of WASM, it is a much closer mode to real hardware.

And of course JIT can make WASM fast but if you look around, building a performant WASM JIT still remains terribly hard, some implementation even needs LLVM to perform optimizations. I'd say if this is the case, we must've chosen the wrong model.

Re: WASM as a Platform for Abstraction

#14

Post by kbumsik »

ridiculous_fish wrote: post #7

Lots of wasm questions: In what sense can a wasm program "crash?" What sort of backtraces are available in that event? How's the debugging story? Is there a fast wasm runtime available for non-JIT platforms? Is there big-endian support (still hanging on)?

> In what sense can a wasm program "crash?"

I'm not an expert in wasm but memory allocation may fail depending on the host environment. Also, runtimes of higher languages may define their own crash cases. As it is a stack machine dumping a stacktrace in case of "crash" should be easy.

> Is there big-endian support?

Wasm still assumes little-endian byte ordering. Honestly who really cares about big-endian?

https://github.com/WebAssembly/design/blob/master/Portabilit...

Re: WASM as a Platform for Abstraction

#15

Post by TomMarius »

xuejie wrote: post #12
cjbprime wrote: post #9

Earlier quoted context omitted.

It sounds like you're bringing up a register-based vs stack-based VM argument, and claiming that register-based VMs have better performance because their model is closer to the hardware. My understanding is that this intuition is usually untrue, because a JIT benefits from the stack-based code preserving code flow and thus allowing more efficient code generation.

No I'm not talking about register-based vs stack-based VM, that's a totally different topic. I'm just saying WASM is still quite distant from real hardware, making it a non-trivial task to performantly run the code. In fact if you look at the asm.js, which is the original inspiration of WASM, it is a much closer mode to real hardware. And of course JIT can make WASM fast but if you look around, building a performant…

What major implementations are using LLVM? Firefox is using Cranelift, Chrome is using V8, both of these shouldn't be using LLVM, AFAIK, or am I wrong?

Re: WASM as a Platform for Abstraction

#17

Post by stevedonovan »

Animats wrote: post #13

Strange. Something like node.js for running server side WASM programs, maybe. But hard real time? That's a strange application for this. Why add the additional layer?

The traditional approach is dynamically loaded native libraries, and that certainly worked well when I did it in C++. The dynamic linking situation in Rust is immature, nothing like a stable ABI. Static linking has received much more attention, and the core developers can't prioritize at once. However, it can be done and I hope it can be done safely at some point.

Re: WASM as a Platform for Abstraction

#18

Post by rapsey »

TomMarius wrote: post #15
xuejie wrote: post #12

Earlier quoted context omitted.

No I'm not talking about register-based vs stack-based VM, that's a totally different topic. I'm just saying WASM is still quite distant from real hardware, making it a non-trivial task to performantly run the code. In fact if you look at the asm.js, which is the original inspiration of WASM, it is a much closer mode to real hardware. And of course JIT can make WASM fast but if you look around, building a performant…

What major implementations are using LLVM? Firefox is using Cranelift, Chrome is using V8, both of these shouldn't be using LLVM, AFAIK, or am I wrong?

LLVM more usable for cloud vendors and such who use wasm outside of the browser. So we do have 3 quality implementations already.

Re: WASM as a Platform for Abstraction

#19

Post by pjmlp »

WASM advocates keep rediscovering the benefits from bytecodes as portable execution format, while presenting them as something great made possible only by WASM.

Reading a bit of mainframe history would do some good it seems.

Re: WASM as a Platform for Abstraction

#20

Post by xuejie »

TomMarius wrote: post #15
xuejie wrote: post #12

Earlier quoted context omitted.

No I'm not talking about register-based vs stack-based VM, that's a totally different topic. I'm just saying WASM is still quite distant from real hardware, making it a non-trivial task to performantly run the code. In fact if you look at the asm.js, which is the original inspiration of WASM, it is a much closer mode to real hardware. And of course JIT can make WASM fast but if you look around, building a performant…

What major implementations are using LLVM? Firefox is using Cranelift, Chrome is using V8, both of these shouldn't be using LLVM, AFAIK, or am I wrong?

wasmer [1] has a LLVM backend, WAVM [2] uses LLVM as the bakend, I could be wrong but last time I checked, cranelift is only meant to be the next generation WASM engine used in Firefox, it is not yet in production.

And actually the argument is: all of v8, Firefox/Cranelift and LLVM used in wasmer requires non-trivial work to make WASM fast, which shouldn't be needed given a different model.

[1] https://github.com/wasmerio/wasmer/tree/master/lib/llvm-back... [2] https://github.com/WAVM/WAVM

Post reply on HN