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

WebAssembly architecture for Go

docs.google.com

Post reply on HN
Print view View original

61–70 of 71 posts

Re: WebAssembly architecture for Go

#61

Post by pjmlp »

k__ wrote: post #52
steveklabnik wrote: post #15

Earlier quoted context omitted.

Wasm doesn't have one yet , but it's a future extension to to spec. You can, of course, compile your GC in today, and it will work. Wasm's integrated support will mean re-using the existing GC, which means smaller code size. Side note: most people thought this would be a precursor to DOM support, but the new "host bindings" proposal opens up DOM support without needing GC support, and many people believe that now the…

Are GC implementations transparent for the languages? Can Go simply run with the WASM GC or does it need some specific type of GC?

No if you care about performance.

To go the extra mile in GC performance, the compiler and GC implementation have to collaborate, taking advantage of language specific features.

Re: WebAssembly architecture for Go

#62

Post by pjmlp »

goalieca wrote: post #7
johnhenry wrote: post #2

I'm trying to learn more about this topic and I'm curious if anyone could clarify for me -- The reason Go would need a specific architecture for WebAssembly is because Go supports features, like garbage collection, that WebAssembly does not. Is that right? Close? An oversimplification. Way off?

Follow-up question, why can't LLVM -> Web Assembly solve the problem?

Besides the issue of Go main compilers not using LLVM, that would only be about the instructions.

There is no way around porting the runtime as well.

Re: WebAssembly architecture for Go

#64

Post by zenhack »

api wrote: post #63

Why is WASM so weird? Why not just thinly model modern CPUs so it can be almost transliterated?

One big advantage of stack machines is that they tend to be better on code size, which very much matters when you're transferring code over the network. I expect other parts of the design make it easier to JIT; the lack of arbitrary gotos probably makes analyzing control flow easier, for example.

Re: WebAssembly architecture for Go

#65

Post by skybrian »

dualogy wrote: post #49
kodablah wrote: post #36

Earlier quoted context omitted.

So I am curious how the presence of them in WASM would help

Jump-to-arbitrary-address / labels-as-values isn't made available to Go devs by Go-the-language, but seems required by Go-the-runtime+compiler, such as for compiling Goroutines.

It sort of does via channels, though. Sending a value to a bufferless channel causes the next goroutine to run (eventually). This looks a bit like a goto if you squint.

Go needs multiple stacks and a way to switch to executing a different stack. Web assembly could provide this in a high-level way.

Re: WebAssembly architecture for Go

#66

Post by hajile »

pjmlp wrote: post #43
slimsag wrote: post #30

Earlier quoted context omitted.

It's also worth mentioning WASM has no GC today.

My amd64 and ARM CPUs also don't have it. On languages where the algorithm is an implementation detail, one can make use of reference counting with a cycle collector, which are just a few hundred lines. Implementing one is pretty simple, making it perform well is another matter.

Unlike your real processor though, you can't directly access memory or ensure its absolute location. You can make an advanced GC that is slow or a basic one that is not.

Re: WebAssembly architecture for Go

#67

Post by hajile »

amelius wrote: post #53

Strange that wasm doesn't support go-to instructions. Didn't they see the need for it coming? Most compiler backends need it, I suppose.

It's easier to add instructions than to remove our restrict them. Hardware or software exploits to break out of the sandbox are huge concerns. I'm all for introducing new features slowly.

Re: WebAssembly architecture for Go

#68

Post by k__ »

steveklabnik wrote: post #57
k__ wrote: post #52

Earlier quoted context omitted.

Are GC implementations transparent for the languages? Can Go simply run with the WASM GC or does it need some specific type of GC?

"the WASM GC" only exists as a proposal, and proposals can change before they land. I don't know enough about it to say, and even if I did, it might be invalid by the time things are actually accepted. See https://github.com/WebAssembly/gc for the current proposal.

Sure.

But one day, when there are implementations, can every language run with the WASM GC?

Re: WebAssembly architecture for Go

#69

Post by rictic »

EugeneOZ wrote: post #33
slimsag wrote: post #31

Earlier quoted context omitted.

Yes. Not a ton of people (yet), but yes, some are.

but why, if you have plenty of good languages to do this? Wasm is good for browsers because only choice we have is js.

I'm ignorant of the details, but WASM is an assembly language that's designed from the ground up for running untrusted code. It will also have multiple independent open source implementations, which has some nice properties.

Re: WebAssembly architecture for Go

#70

Post by FullyFunctional »

Interestingly the issues sounds a lot like what a high performance Haskell implementation would run into. One additional note though on GC: highly tuned PL implementation requires completely control over object layout, pointer representation, and GC. (!)

No off-the-shelf GC will ever be perfect for all languages, thus I think WASM would be far better off doing whatever it could to facilitate runtimes implementing their own.

(!) Example from the lazy world: lazy closures when evaluated and updated often results in an indirection. We rely on GC to shortcut these. Sometimes we even have GC perform trivial constant-time evaluations when we know the result is smaller than the suspended evaluation.

Example from the Lisp world: cdr-coded cons cells can cut size in half, but no generic GC would be able to do this.

Post reply on HN