emulators running slow after last update

[nippur72]

I checked the Tiny Emulators web site and it seems that C64 and VIC20 now run much much slower than before!

I did the following simple test:

5 TI$="000000"
10 PRINT TI
20 GOTO 10

running in parallel on an instance of C64 "chips" and another of the "VICE" emulator (both PAL).

The VICE overtakes the "chips" even if it is started seconds after. Illustrated in the picture below:

[floooh]

Looks about right here (tested with VICE and your test program).

What does the time value in the top-right-corner say when you start the "ui" version (https://floooh.github.io/tiny8bit/c64-ui.html).

If this is bigger than 16ms 24ms then the emulator might not be able to run in realtime. Also note that when the emulator's browser tab is in the background, the emulator will freeze until the tab is in the foreground again.

[floooh]

PS: the last change in the timing code was this (from last May):

29e987f#diff-629ebb0dfc46596928905df3ef39db58ddcfce3d68c66bc1a281f2cc745ae573

The stm_round_to_common_refresh_rate() isn't strictly necessary, it might throw off the timing by up to 10% or so though if your display has a "weird" refresh rate which is close to common refresh rates (see this list: https://github.com/floooh/sokol/blob/b693b8b5222244bff174d912a0a4192ddbe00d30/sokol_time.h#L273-L283).

Might be worth testing without this correction though. It's intended to eliminate micro-stutter, but for emulators that's probably not all that important.

[nippur72]

the emu time is around 10ms for the C64 and 4ms for the VIC20.

I checked it in Chrome "Performance" tab and frame time is indeed below 24ms, but there is a strange "long task" that lasts 61 ms that is related to "GPU" ... (green band):

I also repeated the test with the VIC20, same result.

My PC is an old AMD with an old GPU but all other emulators so far are ok. I also have a my own version of your "chips" VIC20 that run in a canvas and it's fine. (see it here).

[floooh]

Hmm that looks strange indeed... Are you able to build and run the native versions of the emulator on that machine (e.g. is this specific to the browser version)?

[nippur72]

I checked Firefox and it's ok -- Chrome and Edge show the same issue (both are based on the same engine). All three are the latest x64 version for Windows.

I can't build the emulators natively - my fork of your VIC20 compiles to WASM but renders audio and video with JavaScript calls.

[bitcoinmeetups]

In general, 8-bit emulators run slowly in my mobile browser as well. Sound is often lagging. Android J7. I was hoping that emulators built in webassembly would be faster than those made with javascript. I think they will eventually.

I also wish there was a mobile browser that could be completely configured according to user wishes. For example I want to hide the URL bar.

Everything is like a fork of chrome. But I want unix like tools where I can customize everything.

[floooh]

@bitcoinmeetups this is most likely not a WASM vs JS issue, but caused by different implementation choices in the emulators (in general, the chips emulators are fairly brute force per-cycle emulators that do a lot of work per clock cycle even if this work ends up not being needed for the current emulation state). There are also some places that could be better optimized especially in the C64's VIC-II and CIA emulation.

But apart from that, WASM and (well-written) JS performance are pretty close (not because WASM is slow, but because Javascript is fast since around V8).

[bitcoinmeetups]

Ah, ok. Well, anyway, assembly languages are beautifully written and javascript is ugly. Plus caffeine is an addictive drug. People should not use addictive drugs. So they shouldn't name the programming language after them. Plus he even copied the name from Java. Without having any connection to Java at all. So: 1. JavaScript looks ugly and is kind of a patch. 2. Addictive drugs are bad, thus java is bad. 3. Plus he kind of stole half the name from another project, copycating like that is not so nice either. On the contrary, you have some nicely written code on the website and the emulators are really cool as well. I hope in the future the browsers can be more useful for example for terminal emulators (v86) and other emulators such as this. Feature request: Quick and easy streamlined editing and deployment of states from Linux command line to the websites. -------- Original Message --------

…

On Nov 7, 2022, 17:33, Andre Weissflog wrote: ***@***.***(https://github.com/bitcoinmeetups) this is most likely not a WASM vs JS issue, but caused by different implementation choices in the emulators (in general, the chips emulators are fairly brute force per-cycle emulators that do a lot of work per clock cycle even if this work ends up not being needed for the current emulation state). But apart from that, WASM and (well-written) JS performance are pretty close (not because WASM is slow, but because Javascript is fast since around V8). — Reply to this email directly, [view it on GitHub](#18 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAVUCQQWQABPGJNVLBH7AQDWHDLIDANCNFSM4TS7EGEQ). You are receiving this because you were mentioned.Message ID: ***@***.***>