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

81–90 of 95 posts

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#81

Post by pjmlp »

throw_m239339 wrote: post #35
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…

Seems to me the original rendering pipeline wasn't GPU based. The author is just dumping whatever the game renders in a canvas element, there is no need for webgl for that. Also Canvas is getting some GPU acceleration in some browsers: https://developers.google.com/web/updates/2012/07/Taking-adv...

Usually canvas hardware acceleration is not taken advantage of unless you do CSS tricks like setting an element with another depth order.

https://www.programmersought.com/article/58016098343/

In any case, given how browsers black list drivers and GPU models, even WebGL isn't guaranteed to be accelerated.

With these constrains the Web will never be as fast as native for graphics programming.

They took us Flash away, but forgot to ensure the same capabilities were kept.

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#82

Post by brabel »

mamcx wrote: post #58
flohofwoe wrote: post #46

Earlier quoted context omitted.

This would still require conversion from and to Javascript strings, and doesn't help with any language compiled to WASM that isn't Rust. And it probably wouldn't even help Rust because such a native WASM string type would presumably live outside the WASM heap (because if the string data would be on the WASM heap, there's no need for a native string type).

Any complex structure past int/floats requiere conversion. Heck, even floats and ints (for example: oCalm and anybody with more/less bits than JS). So, given this is a fact, the best course of action is chosen the most safe alternative. And for everyone else? Well an array of bits ant let the host/callers that are the only that know their own stuff deal with it. INCLUDING Js.

I don't know what you're arguing about. The interface types proposal defines a string like this:

    string ≡ (list char)
char is defined to be a Unicode scalar value (i.e., a non-surrogate code point).

Basically, this is "the most safe alternative"??!

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#83

Post by pests »

"Then, I threw out everything which is either not needed or looks complicated. We only need the string formatting functions anyway, let's remove everything else. Th result is a crossover of musl 1.2.2 and arch from emscripten for musl 1.1.15. YOLO!"

Lmao

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#84

Post by [deleted] »

pjmlp wrote: post #81
throw_m239339 wrote: post #35

Earlier quoted context omitted.

Seems to me the original rendering pipeline wasn't GPU based. The author is just dumping whatever the game renders in a canvas element, there is no need for webgl for that. Also Canvas is getting some GPU acceleration in some browsers: https://developers.google.com/web/updates/2012/07/Taking-adv...

Usually canvas hardware acceleration is not taken advantage of unless you do CSS tricks like setting an element with another depth order. https://www.programmersought.com/article/58016098343/ In any case, given how browsers black list drivers and GPU models, even WebGL isn't guaranteed to be accelerated. With these constrains the Web will never be as fast as native for graphics programming. They took us Flash away, b…

[deleted]

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#85

Post by [deleted] »

HideousKojima wrote: post #17
recursivedoubts wrote: post #2

I can't tell if the lack of strings and DOM API interop in web assembly is on purpose or not. If it is on purpose, what an absolutely diabolical way to ensure javascript language dominance in the browser: give people a way to port their language to the browser, but make it incredibly difficult to do anything.

It's also still missing proper garbage collection, meaning languages like C# have to include basically the entire runtime if you compile to WebAssembly. This is a major part of why Blazor apps in .NET 5 are ~2MB for a simple "Hello World" (closer to 8MB if you use the AOT compilation options in the .NET 6 preview).

[deleted]

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#86

Post by flohofwoe »

miohtama wrote: post #79
flohofwoe wrote: post #10

Earlier quoted context omitted.

What type of strings though? Exposing Javascript string objects in WASM doesn't make much sense if the code is expecting C strings for instance. Same for other languages, those all have their own incompatible internal representations for strings. The only somewhat interop-friendly string type is a zero-terminated bag of bytes, usually UTF-8 encoded (aka C strings), but that's a different string representation than Ja…

DOM manipulation is slow is pretty much busted misconception today: https://svelte.dev/blog/virtual-dom-is-pure-overhead

It is "slow" relative to the overhead of calling from WASM into JS to manipulate the DOM from JS.

To be fair, I don't know how many clock cycles creating, destroying or modifying a DOM node costs on average, but most likely "a lot" compared to the overhead of a WASM to JS call because a lot more machinery is involved.

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#87

Post by titzer »

pjmlp wrote: post #80
titzer wrote: post #68

Earlier quoted context omitted.

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. I…

For example, the existing JS GC doesn't need to expose ability to stop the GC, execute on demand, support value types, pinning memory, interior pointers, control GC regions, marshaling to native code to the developer, whereas a .NET or D GC does. So if a future WASM GC doesn't offer APIs for such capabilities, it is useless from those runtimes point of view.

Thanks for getting down to brass tacks. Of the things that you mentioned, I think that interior pointers are the only thing that is relevant.

Java has an API for executing the GC on demand, and VM engineers I have talked to over the years think it's a knob that apps shouldn't have.

Wasm already supports multiple return values, so you don't need to box value types on any boundary--they can be flattened whereever they occur.

Pinning memory has to do with interfacing native code that could potentially do unsafe things. That doesn't fit into wasm's model, and would only be necessary for interacting with platform APIs, which are being designed not to need that. Same for "marshalling to native code".

I don't understand what you mean by GC regions. Realtime Java had GC regions and a complex system for trying to allow threads to run without touching the heap. It really didn't go well. I think if regions are useful for a GC, the engine should do inference of them, because adding regions to the type system infects everything.

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#88

Post by mamcx »

brabel wrote: post #82
mamcx wrote: post #58

Earlier quoted context omitted.

Any complex structure past int/floats requiere conversion. Heck, even floats and ints (for example: oCalm and anybody with more/less bits than JS). So, given this is a fact, the best course of action is chosen the most safe alternative. And for everyone else? Well an array of bits ant let the host/callers that are the only that know their own stuff deal with it. INCLUDING Js.

I don't know what you're arguing about. The interface types proposal defines a string like this: string ≡ (list char) char is defined to be a Unicode scalar value (i.e., a non-surrogate code point). Basically, this is "the most safe alternative"??!

I was arguing against the idea of "string are implemented differently by different languages, so WHICH one choose?".

A safe one. Your sample is that - except I think is better if is a utf-8 string, but this one works for me too-. What will be worrisome is if is made to be like in C.

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#89

Post by devwastaken »

sitkack wrote: post #67
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…

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

The web worker where wasm is running in would be the one that handles the whole game, and the game has to be told the inputs. Inputs are only grab able on the main thread, and rendering is only done on the main thread. If you run the game in the main thread too you can end up with your browser tab becoming unresponsive, or have delays in the input and rendering that affect the games performance.

It's the same as when you make a python UI all in one thread, you can't receive user input and also do some long task at the same time.

Re: WebAssembly from Scratch: From FizzBuzz to DooM

#90

Post by miohtama »

flohofwoe wrote: post #86
miohtama wrote: post #79

Earlier quoted context omitted.

DOM manipulation is slow is pretty much busted misconception today: https://svelte.dev/blog/virtual-dom-is-pure-overhead

It is "slow" relative to the overhead of calling from WASM into JS to manipulate the DOM from JS. To be fair, I don't know how many clock cycles creating, destroying or modifying a DOM node costs on average, but most likely "a lot" compared to the overhead of a WASM to JS call because a lot more machinery is involved.

You are correct, today. But the overhead from WASM to JS is disappering with host binding, also known as WebAssembly Interface Types proposal.

https://www.chromestatus.com/feature/6219189974990848

Post reply on HN