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

21–30 of 85 posts

Re: WASM as a Platform for Abstraction

#21

Post by pjmlp »

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,…

That is not an issue regarding bytecode formats in general, given that in some platforms only the kernel does the final compilation to machine code, and they are a common executable format since early 60's.

However I do agree with WASM everywhere fashion complaint.

Re: WASM as a Platform for Abstraction

#22

Post by pjmlp »

jahewson wrote: post #11
dmitriid wrote: post #3

Earlier quoted context omitted.

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.

Because Mozilla went political and came up with asm.js as counter technology.

Re: WASM as a Platform for Abstraction

#23

Post by pjmlp »

jcelerier wrote: post #6
dmitriid wrote: post #3

Earlier quoted context omitted.

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

No, LLVM IR is machine specific. Any "native" language is since the ABI of a struct will depend e.g. on the size of pointers for that platform. E.g. Consider in C int foo[sizeof(void*)];

Open source LLVM IR is machine specific, it doesn't have to be, as proven by watchOS bitcode, or PNaCL.

Re: WASM as a Platform for Abstraction

#24

Post by pjmlp »

rapsey wrote: post #4
dmitriid wrote: post #3

Earlier quoted context omitted.

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

I'm pretty sure it is not stable and not designed for such a use case.

Apple kind of disagrees with watchOS bitcode.

Re: WASM as a Platform for Abstraction

#25

Post by moring »

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…

> some implementation even needs LLVM to perform optimizations. I'd say if this is the case, we must've chosen the wrong model.

Why? Optimizing machine-independent code for a particular machine is part of the "core business" of LLVM, up to the point where a sufficiently capable bytecode/optimizer becomes comparable to LLVM.

OTOH, if the main argument here is the size/speed/other weight of LLVM, then of course the host machine that wants to run WASM only needs a tiny subet of LLVM: no frontend, single backend, only a subset of optimization passes... There is also a tradeoff to make to leave optimization passes out that actually improve the code a bit but are too heavy for the host machine.

Re: WASM as a Platform for Abstraction

#26

Post by TomMarius »

pjmlp wrote: post #19

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.

So we're getting mainframe-like tech into the mainstream? Isn't it good?

Re: WASM as a Platform for Abstraction

#27

Post by tom_mellior »

pjmlp wrote: post #24
rapsey wrote: post #4

Earlier quoted context omitted.

I'm pretty sure it is not stable and not designed for such a use case.

Apple kind of disagrees with watchOS bitcode.

"not designed for that use case" != "isn't used for that use case in practice"

Apple has tight control over the bitcode version and the target platforms supported by Xcode. That's not the same thing as accepting arbitrary LLVM bitcode files.

Re: WASM as a Platform for Abstraction

#28

Post by kimundi »

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)?

Wasm programs can only crash by triggering a "trap", which has the well defined semantic of aborting the entire (wasm) function stack at that point. It depends on the embedding host how much backtrace or debugging support you get for this.

I'm not sure exactly what you mean with non-JIT platforms, As far as I know, most wasm hosts that generate native code just compile the entire wasm module at once, so its less like a JIT runtime and more like a regular compiler.

If you mean not compiling to native code at all, then you just have the performance of a plain old stack machine bytecode interpreter. Not sure how many there are currently and how well optimized they are though.

About big-endian - afaik little-endian is just the spec for storing to wasm's linear memory - the actual representation of stack values can be arbitrary (since you can not inspect their bytes directly).

Re: WASM as a Platform for Abstraction

#29

Post by Shish2k »

pjmlp wrote: post #19

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.

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

I wonder if anyone has a list of awesome mainframe features so that we know what modern computing is going to "invent" next? :P

(See also: hot-swappable parts, virtualisation, containers, etc... I never got to work with mainframes myself, just each time I dig into some new "industry game-changer" tech, I learn that mainframes had it in the 60's)

Re: WASM as a Platform for Abstraction

#30

Post by 7373737373 »

Shish2k wrote: post #29
pjmlp wrote: post #19

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.

> Reading a bit of mainframe history would do some good it seems. I wonder if anyone has a list of awesome mainframe features so that we know what modern computing is going to "invent" next? :P (See also: hot-swappable parts, virtualisation, containers, etc... I never got to work with mainframes myself, just each time I dig into some new "industry game-changer" tech, I learn that mainframes had it in the 60's)

GNOSIS/KeyKOS: Capability security, Resource metering, Persistence mechanisms

http://www.cap-lore.com/Agorics/Library/KeyKos/

Post reply on HN