>UPDATE
> An earlier post described performance problems on Firefox and Safari, which were related to the Proxy object. This feature is used to read values from WebAssembly into JavaScript.
> After changing to Object.defineProperty() all browsers are equally fast on WebAssembly, beating JavaScript in all cases.
The update at the bottom is kind of interesting. All browsers are equally fast, which makes sense because wasm should speak directly to the hardware more easily than javascript.
This is also just because APIs like Object.defineProperty are old and well-optimized, while Proxy (in comparison - it's not THAT new) is relatively new and not optimized because it is rarely used. Part of the reason it's rarely used is that it's very slow :-)
That is generally how web platform optimization goes, yes. Browser vendors optimize the stuff that gets used most, which means new APIs tend not to get used much unless they fill a gaping hole.
A word about my C64 emulator: this is very CPU hungry, partly because the 6502 emulation uses a cycle-stepped model (https://floooh.github.io/2019/12/13/cycle-stepped-6502.html), this causes the 6502 emulation to store and load context in each cycle which pretty much eliminates the opportunity that emulator state can be kept in registers across cycles, it also does an indirect jump for each cycle instead of just once per instruction. More importantly though, the VIC-II emulation isn't very optimised, every cycle updates the entire chip state, sprite units and all (the VIC-II emulation dominates the per-frame budget much more than the CPU) - in general the implementation of the entire emulator is fairly straightforward, but also fairly brute-force.
When looking at emulator benchmarks it's always important to also look at how the emulator has been implemented, and what compromises an emulator might make to balance between performance, accuracy and "design purity" (e.g. the cycle-stepping CPU model isn't all that useful in practice, except that it is 'more pure' and interesting from an emulator-design point-of-view). In comparison to those implementation differences, the performance difference between WASM and JS should be mostly negligible.
>UPDATE > An earlier post described performance problems on Firefox and Safari, which were related to the Proxy object. This feature is used to read values from WebAssembly into JavaScript. > After changing to Object.defineProperty() all browsers are equally fast on WebAssembly, beating JavaScript in all cases.
The update at the bottom is kind of interesting. All browsers are equally fast, which makes sense because wasm should speak directly to the hardware more easily than javascript.
This is also just because APIs like Object.defineProperty are old and well-optimized, while Proxy (in comparison - it's not THAT new) is relatively new and not optimized because it is rarely used. Part of the reason it's rarely used is that it's very slow :-)
That seems like a loop.
It is slow it is rarely used it doesn't get optimized it is slow
That is generally how web platform optimization goes, yes. Browser vendors optimize the stuff that gets used most, which means new APIs tend not to get used much unless they fill a gaping hole.
A word about my C64 emulator: this is very CPU hungry, partly because the 6502 emulation uses a cycle-stepped model (https://floooh.github.io/2019/12/13/cycle-stepped-6502.html), this causes the 6502 emulation to store and load context in each cycle which pretty much eliminates the opportunity that emulator state can be kept in registers across cycles, it also does an indirect jump for each cycle instead of just once per instruction. More importantly though, the VIC-II emulation isn't very optimised, every cycle updates the entire chip state, sprite units and all (the VIC-II emulation dominates the per-frame budget much more than the CPU) - in general the implementation of the entire emulator is fairly straightforward, but also fairly brute-force.
When looking at emulator benchmarks it's always important to also look at how the emulator has been implemented, and what compromises an emulator might make to balance between performance, accuracy and "design purity" (e.g. the cycle-stepping CPU model isn't all that useful in practice, except that it is 'more pure' and interesting from an emulator-design point-of-view). In comparison to those implementation differences, the performance difference between WASM and JS should be mostly negligible.
Was the header image for this article generated via Stable Diffusion (or similar)?
http://8bitworkshop.com/docs/_images/js-vs-wasm-1.jpg
Inhumanly abstract, yet intriguing.
Img2Img is pretty cool. Here's what my mind saw in that image: https://i.imgur.com/8Rndjh3.png
Article is from 2021 so yeah definitely an earlier AI generated model. There's been a lot of advancement in 2022.
It looks like dalle-mini.
> I’ve been working on an experimental Verilog runtime that emits WebAssembly, generated from the AST nodes of the Verilog compiler.
No link in the article, and I wasn't able to find a public project that tries to do this. Is there?
It’s linked at the bottom, the next release:
http://8bitworkshop.com/docs/posts/2021/8bitworkshop-release...
IDE: https://8bitworkshop.com/v3.10.0/?file=clock_divider.v&platf...
:D
Hrm, I really goofed by linking the `clock_divider` Verilog file and not the Atari Tank clone, which is way more fun (for some of us!):
https://8bitworkshop.com/v3.10.0/?file=tank.v&platform=veril...
Where can one find the part that translate verilog to javascript? Is it open-source?