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

WebAssembly from Scratch: From FizzBuzz to DooM

github.com

Post reply on HN
Print view View original

61–70 of 95 posts

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#61

Post by plopz »

asiachick wrote: post #40
djhworld wrote: post #31

Earlier quoted context omitted.

There's also the problem of getting keyboard input in and out of the web worker in a performant manner. I tried this a few years ago with a Gameboy emulator I had ported from Go to webassembly and used web workers to run the emulator in. Getting the keyboard input in, in a performant way was a real struggle using postMessage, although I'll admit I'm not the best at web programming so someone more skilled might have b…

You could pass it via a SharedArrayBuffer

From what I found on MDN "a side effect to the block in one agent will eventually become visible in the other agent", what does the word eventually mean there, what's going on under the hood?

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#63

Post by lisper »

sigg3 wrote: post #48
jjice wrote: post #28

Earlier quoted context omitted.

It's incredible how far the web has come. I remember the first time I saw a browser GameBoy emulator and I was amazed. Maybe I should port my GB emulator to WASM...

> It's incredible how far the web has come. I agree and disagree. It seems like no one is questioning why we need to use legacy web browsers in between all the code we're executing locally. It's like a new iteration of old tech like lisp machines, which started out as specific purpose only to grow into complete environments (afaik). In this regard, we haven't come far, it's just the syntax that has changed.

In the case of WASM, even the syntax hasn't changed, it has just come full-circle back to S-expressions.

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#64

Post by paulgb »

sigg3 wrote: post #48
jjice wrote: post #28

Earlier quoted context omitted.

It's incredible how far the web has come. I remember the first time I saw a browser GameBoy emulator and I was amazed. Maybe I should port my GB emulator to WASM...

> It's incredible how far the web has come. I agree and disagree. It seems like no one is questioning why we need to use legacy web browsers in between all the code we're executing locally. It's like a new iteration of old tech like lisp machines, which started out as specific purpose only to grow into complete environments (afaik). In this regard, we haven't come far, it's just the syntax that has changed.

For one thing, I’m unlikely to download a native copy of Doom to run on my own machine from a strange website. The ability to run cross-platform code that uses my GPU in a secure sandbox is pretty neat to me.

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#65

Post by Quekid5 »

milliams wrote: post #5

I found this video https://www.youtube.com/watch?v=r-A78RgMhZU "A Talk Near the Future of Python (a.k.a., Dave live-codes a WebAssembly Interpreter)" to be a brilliant introduction to WASM as well as writing interpreters in general. I'm a relative novice in the subject and it was pitched right at my level.

Dave Beazley is a truly amazing presenter. Another favorite of his of mine is his epic tale of how he ended up demolishing an opposing side's case in a civil lawsuit... by sheer luck of having a Python interpreter avaialable. For for you viewing pleasure:

   https://www.youtube.com/watch?v=RZ4Sn-Y7AP8

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#67

Post by sitkack »

djhworld wrote: post #31
devwastaken wrote: post #25

Very nice. I like these tutorials showing the nuts and bolts of wasm and C without just throwing it at emscripten toolchain. I'm curious if there's perf differences between canvas and webgl canvas. This project uses just canvas, but iirc passing frames to be rendered by webgl is faster. Perhaps I'm wrong in this context. I also don't see threading in here. Makes sense for a demo, but if this were to be used performan…

There's also the problem of getting keyboard input in and out of the web worker in a performant manner. I tried this a few years ago with a Gameboy emulator I had ported from Go to webassembly and used web workers to run the emulator in. Getting the keyboard input in, in a performant way was a real struggle using postMessage, although I'll admit I'm not the best at web programming so someone more skilled might have b…

Why this arch over having the UI run in the main thread and sending events into the wasm worker?

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#68

Post by titzer »

pjmlp wrote: post #37
steveklabnik wrote: post #30

Earlier quoted context omitted.

Think of it more of "integration with a host environment's runtime" than a "adding a runtime to wasm directly." (At least, that's what it used to be; I haven't been involved in WebAssembly for a long time.)

The problem is that each runtime has different GC requirements, so at best it will mean WASM GC semantics will be the underlying JS GC semantics, probably not what you want for a D or .NET GC, for example.

No one has ever articulated the details of what they mean by these runtimes having different GC requirements. JavaScript garbage collection has no "semantics"--it is entirely invisible to applications. Even WeakMap and WeakSet do not expose garbage collection details because they are not iterable.

The memory profile of JavaScript applications tends to look a lot like the memory profile of typical Java applications. It tends to be a law of large numbers.

Now if you want to talk about details of how we implement runtimes that do have observable GC details, like weak callbacks, Java's zoo of reference types, etc, then let's do that, because Wasm GC will eventually need to have low-level mechanisms to support those.

But if we're talking about a Wasm engine GC's ability to allocate, trace, move (or not!) little blocks of memory around, then I don't see any fundamental stumbling blocks to making that mechanism efficient and universal.

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#69

Post by titzer »

pjmlp wrote: post #53
steveklabnik wrote: post #39

Earlier quoted context omitted.

I would assume that there’s Microsoft folks involved to make sure it works out satisfactory given their investment in Blazor, but yes, it’s always a possibility that an API is bad. I don’t know what their level of interest is in embedding wasm inside C# is.

That was just an example, there are a plethora from GC algorithms to chose from, which of them needs to be fine tuned for the specific runtime it is to be applied, if performance is of any concern to the language implementers.

I have worked on a number of runtimes and it is not generally the case that a GC needs to be "tuned" for a runtime, rather that a GC co-evolves with a runtime and features or misfeatures of the runtime determine the path of least resistance for developing more advanced GC algorithms. The interplay tends to involve a lot of technical debt if the separation is poor from the outset. But regardless, it's rare that a runtime develops more than a couple GC algorithms unless it has a very long lifetime or is explicitly designed to allow swappable GCs, like Jikes RVM with Mmtk.

GC performance depends more on the program than the language.

But regardless, the hardest parts of getting to advanced GCs, such as concurrent and parallel algorithms are usually very deep assumptions of single-threadedness and uninterruptibility that are debt in the runtime. It usually doesn't help that most runtimes are written in C/C++ and suffer that environment's complete uncooperativeness[1] in finding and manipulating roots.

[1] To the point of seeming hostility. It's been how many years and LLVM still fights against supporting stack maps?

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#70

Post by musicale »

djhworld wrote: post #31
devwastaken wrote: post #25

Very nice. I like these tutorials showing the nuts and bolts of wasm and C without just throwing it at emscripten toolchain. I'm curious if there's perf differences between canvas and webgl canvas. This project uses just canvas, but iirc passing frames to be rendered by webgl is faster. Perhaps I'm wrong in this context. I also don't see threading in here. Makes sense for a demo, but if this were to be used performan…

There's also the problem of getting keyboard input in and out of the web worker in a performant manner. I tried this a few years ago with a Gameboy emulator I had ported from Go to webassembly and used web workers to run the emulator in. Getting the keyboard input in, in a performant way was a real struggle using postMessage, although I'll admit I'm not the best at web programming so someone more skilled might have b…

Do you mean that keyboard input into a web worker is too slow, or it uses too much memory or cpu or power or ???

How is keyboard input different from any other sort of data round trip to/from a web worker?

Post reply on HN