Emulator Performance: WebAssembly vs. JavaScript (2021)(8bitworkshop.com)
8bitworkshop.com
Emulator Performance: WebAssembly vs. JavaScript (2021)
http://8bitworkshop.com/docs/posts/2021/webassembly-vs-javascript-emulator-performance.html
13 comments
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 :-)
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.
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.
Where can one find the part that translate verilog to javascript? Is it open-source?
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.
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?
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
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...
https://8bitworkshop.com/v3.10.0/?file=tank.v&platform=veril...
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.