Live data from Hacker News

WebAssembly Troubles Part 1: WebAssembly Is Not a Stack Machine

troubles.md

11–20 of 63 posts

Re: WebAssembly Troubles Part 1: WebAssembly Is Not a Stack Machine

#11
post #8

[one of the original Wasm designers here] Responding to the OP, since there is no comment section on the site. First off, this rant gets the history of Wasm wrong and the facts of Wasm wrong. I wouldn't unload on a random person on the internet generally, but I would like to point a sentence like: > Not only that, but for the most part the WebAssembly specification team were flying blind. It's an ad hominem. This rea…

> Wasm blocks and loops absolutely can take parameters; it's part of the multi-value extension which V8 implemented already a year ago.

If that's an extension, and it's only implemented in V8 but not in some of the other main WebAssembly platforms, then I guess it's fair to call it out as not being part of WebAssembly.

Re: WebAssembly Troubles Part 1: WebAssembly Is Not a Stack Machine

#12

Recomputing liveness is not really a big deal. Can be quite cheap, especially over a register based IR. I think that this article overstates the impact of all of this.

Yes. The article is obsessed with the code quality generated by streaming compilers, which is probably the wrong thing to focus on. A real high-performance backend has no trouble reconstructing SSA form and using it for optimizations. But forcing frontends to emit SSA would be a burden on them. (LLVM bitcode formally requires SSA form as well, but this can be worked around by using allocas.)

It might, however, make sense to have another standard "SSA WebAssembly" program representation. There could then be standard tooling to compile vanilla WebAssembly to the SSA form, frontends could choose which variant they want to emit, and backends preferring SSA as input could still be made happy.

Re: WebAssembly Troubles Part 1: WebAssembly Is Not a Stack Machine

#13
post #9
post #8

[one of the original Wasm designers here] Responding to the OP, since there is no comment section on the site. First off, this rant gets the history of Wasm wrong and the facts of Wasm wrong. I wouldn't unload on a random person on the internet generally, but I would like to point a sentence like: > Not only that, but for the most part the WebAssembly specification team were flying blind. It's an ad hominem. This rea…

>>Not only that, but for the most part the WebAssembly specification team were flying blind. >It's an ad hominem. I didn't read that as a criticism at all. He was just saying that the Wasm team didn't have all the information that they would ideally have wanted to have. No idea if that's true or not, but I think you're misreading it if you take it as some kind of ad hominem attack.

I agree that line should be read as "they were doing something novel" as opposed to "they were ignorant".

Re: WebAssembly Troubles Part 1: WebAssembly Is Not a Stack Machine

#14
post #8

[one of the original Wasm designers here] Responding to the OP, since there is no comment section on the site. First off, this rant gets the history of Wasm wrong and the facts of Wasm wrong. I wouldn't unload on a random person on the internet generally, but I would like to point a sentence like: > Not only that, but for the most part the WebAssembly specification team were flying blind. It's an ad hominem. This rea…

> Wasm blocks and loops absolutely can take parameters; it's part of the multi-value extension which V8 implemented already a year ago. If that's an extension, and it's only implemented in V8 but not in some of the other main WebAssembly platforms, then I guess it's fair to call it out as not being part of WebAssembly.

It's at phase 3: https://github.com/WebAssembly/proposals

Phase 4 requires a second implementation, and then we will ship it.

Re: WebAssembly Troubles Part 1: WebAssembly Is Not a Stack Machine

#15

Recomputing liveness is not really a big deal. Can be quite cheap, especially over a register based IR. I think that this article overstates the impact of all of this.

Yes. The article is obsessed with the code quality generated by streaming compilers, which is probably the wrong thing to focus on. A real high-performance backend has no trouble reconstructing SSA form and using it for optimizations. But forcing frontends to emit SSA would be a burden on them. (LLVM bitcode formally requires SSA form as well, but this can be worked around by using allocas.) It might, however, make s…

SSA is a really strange form to send over a wire. It’s got poor space efficiency. It’s also annoying to interpret and not super cheap to turn into machine code.

So, I don’t see the point of sending SSA over the wire.

Re: WebAssembly Troubles Part 1: WebAssembly Is Not a Stack Machine

#16
Huh? Web assembly is a stack machine and locals do not pose a problem whatsoever.

Yes, the author just needs more work to be done. But it's perfectly doable, although it has a complexity. Like everything in the world of compilers. There are no free lunches.

Re: WebAssembly Troubles Part 1: WebAssembly Is Not a Stack Machine

#17
post #8

[one of the original Wasm designers here] Responding to the OP, since there is no comment section on the site. First off, this rant gets the history of Wasm wrong and the facts of Wasm wrong. I wouldn't unload on a random person on the internet generally, but I would like to point a sentence like: > Not only that, but for the most part the WebAssembly specification team were flying blind. It's an ad hominem. This rea…

What you’ve pointed out is not an ad hominem. Reading this may be helpful: https://laurencetennant.com/bonds/adhominem.html

Re: WebAssembly Troubles Part 1: WebAssembly Is Not a Stack Machine

#18

Earlier quoted context omitted.

Yes. The article is obsessed with the code quality generated by streaming compilers, which is probably the wrong thing to focus on. A real high-performance backend has no trouble reconstructing SSA form and using it for optimizations. But forcing frontends to emit SSA would be a burden on them. (LLVM bitcode formally requires SSA form as well, but this can be worked around by using allocas.) It might, however, make s…

SSA is a really strange form to send over a wire. It’s got poor space efficiency. It’s also annoying to interpret and not super cheap to turn into machine code. So, I don’t see the point of sending SSA over the wire.

Agree. SSA requires deconstruction, which would slow down a streaming compiler.

Re: WebAssembly Troubles Part 1: WebAssembly Is Not a Stack Machine

#19
post #8

[one of the original Wasm designers here] Responding to the OP, since there is no comment section on the site. First off, this rant gets the history of Wasm wrong and the facts of Wasm wrong. I wouldn't unload on a random person on the internet generally, but I would like to point a sentence like: > Not only that, but for the most part the WebAssembly specification team were flying blind. It's an ad hominem. This rea…

> It's an ad hominem. This really just impugns people and invites an argument. It might be cathartic, but generally it doesn't advance the conversation to cast aspersion like this.

Ignoring any factual incorrectness, I can not see how the author could have made his point in a more respectful way. He clearly has great enthusiasm for WASM and respect for it's authors, I am struggling to see how anyone could have interpreted it as cathartic...

The paragraph in which your excerpt originated makes this pretty clear:

> The developers of the WebAssembly spec aren’t dumb. For the most part it’s an extremely well-designed specification [...] I considered WebAssembly’s design to be utterly rock-solid, and in fact I still strongly believe that most of the decisions made were the right ones. Although it has problems, it’s incredible how much the WebAssembly working group got right considering it was such relatively unknown territory at the time of the specification’s writing.

Re: WebAssembly Troubles Part 1: WebAssembly Is Not a Stack Machine

#20
post #8

[one of the original Wasm designers here] Responding to the OP, since there is no comment section on the site. First off, this rant gets the history of Wasm wrong and the facts of Wasm wrong. I wouldn't unload on a random person on the internet generally, but I would like to point a sentence like: > Not only that, but for the most part the WebAssembly specification team were flying blind. It's an ad hominem. This rea…

> As for the present. Wasm blocks and loops absolutely can take parameters; it's part of the multi-value extension which V8 implemented already a year ago

Agree with all you wrote. With my own implementation, I'm hesitant to include these extensions until they are "standardized" (I have a one-man toy project, bleeding edge is unreasonable). I understand and have watched as going through the phases seems like quite a slow process (not that it's a bad thing). I think, to avoid fragmentation, it is reasonable for someone targeting WASM at this point to assume the multi value extension is not available. I know there are proposals about runtime capabilities and the like, but with so few of these extensions reaching full spec adoption yet, I don't think they're viable features to leverage even if implemented in the most popular runtimes.

Post reply on HN