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

41–50 of 85 posts

Re: WASM as a Platform for Abstraction

#41

Post by pjc50 »

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)

Someone was circulating the IBM 360 "principles of operation" recently, which sounds like a good way to start.

The trick is identifying which parts were abandoned by mistake, and which parts were abandoned because they were genuinely bad. Nobody wants 21st century JCL. https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/...

Re: WASM as a Platform for Abstraction

#42

Post by pjc50 »

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

> bytecode that resembles more of underlying machine architecture

In what way? This discussion lacks specifics. Doesn't this also risk tying you to a specific machine, which is the opposite of the intent?

Re: WASM as a Platform for Abstraction

#44

Post by ksec »

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.

Not sure why there are so many replies about this being dismissive.

It is just pointing out people likes to reinvent technology every once in a while with 95% of the same thing. And it is not apparent whether those doing the "reinvention" knew what the constrain or trade offs or limitation the previous technology had.

Sometimes these sort of Full Circle makes me wonder if software has really moved forward at all.

Re: WASM as a Platform for Abstraction

#45

Post by xuejie »

TazeTSchnitzel wrote: post #36
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…

Why is it hard? Isn't wasm designed so you can statically and quickly compile pieces of it or the whole thing to native code, rather than needing to do all the tricks dynamic language runtimes do?

That is their very nice slogan, while in reality WASM still has quite a way to go to compete with native code.

Some shits I see these days are that when code speed is measured, people compare that with JS but not native code, when portability is talked about, the comparison is then made against native code, not JS.

Re: WASM as a Platform for Abstraction

#46

Post by xuejie »

moring wrote: post #25
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…

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

There's nothing wrong with LLVM itself, my point is we could've picked a lower level model which don't need a complicated setup like LLVM. Or one that you can direct shipped optimized compiled result of LLVM, that will be a much better world

Re: WASM as a Platform for Abstraction

#47

Post by mr__y »

ksec wrote: post #44
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.

Not sure why there are so many replies about this being dismissive. It is just pointing out people likes to reinvent technology every once in a while with 95% of the same thing. And it is not apparent whether those doing the "reinvention" knew what the constrain or trade offs or limitation the previous technology had. Sometimes these sort of Full Circle makes me wonder if software has really moved forward at all.

> And it is not apparent whether those doing the "reinvention" knew what the constrain or trade offs or limitation the previous technology had.

I'm quite sure that very often the "reinvention" is literally a reinvention - that is not based on previous invention, but an independent solution that just happens to be similiar to something created earlier (without the reinventors knowledge of the existing previous invention). With an abstraction level high enough, many concrete problems become one abstract problem with a few abstract solutions, and sometimes only very few "obvious"[0] solutions. This leads to a situation when many independent persons/teams come up with a concrete solution to their concrete problem that coincidentally happens to be very similiar to other solutions. If one of those solutions where created in the past, and others where rediscovered later, we then retrospectively call those later solutions as "reinventions" regardless of them being literal or just figurative reinventions.[1]

[0] in this context "obvious" defined as "most likely to be independently found/created by any sane person"

[1] "literal reinvention" being a solution that was consciously based on some previously existing invention and a "figurative" when it just happens to be similiar to something created in the past but the inventor did not (consciously) base their work on something already existing

Re: WASM as a Platform for Abstraction

#48

Post by sanxiyn »

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

> Is there a fast wasm runtime available for non-JIT platforms?

Yes, Wasmtime can do AOT. Many other runtimes can do AOT as well.

Re: WASM as a Platform for Abstraction

#50

Post by magoghm »

pjc50 wrote: post #41
Shish2k wrote: post #29

Earlier quoted context omitted.

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

Someone was circulating the IBM 360 "principles of operation" recently, which sounds like a good way to start. The trick is identifying which parts were abandoned by mistake, and which parts were abandoned because they were genuinely bad. Nobody wants 21st century JCL. https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/...

We already have a 21st century JCL: Kubernetes.
Post reply on HN