509986 - Minefield runs JSNES JavaScript NES emulator about 1.5x slower than Chrome

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect)

Description

[Ben Galbraith]

http://benfirshman.com/projects/jsnes/

Running Super Mario Bros., runs full-speed on latest Mac build of Chrome (~62 FPS) but slow as molasses on FF3.5 and latest Minefield (~10-15 fps).

Not exactly a traditional web load to be sure, but perhaps an interesting optimization target?

Comment 1

[Boris Zbarsky [:bzbarsky]]

From some quick looking at this:

30% in js_Interpret; lots of trace aborts and blacklisting, lots of jumping on and off trace:

recorder: started(368), aborted(247), completed(567), different header(4), trees trashed(0), slot promoted(0), unstable loop variable(127), breaks(2), returns(3), unstableInnerCalls(51), blacklisted(151)
monitor: triggered(734709), exits(734705), type mismatch(0), global mismatch(9)

That's for maybe 10 seconds worth of the game.

Ignoring jquery and google-analytics, the aborts are mostly inner trees trying to grow and not having compatible inner trees, and of those mostly the former.  Those for the most part come on a

        // Decode & execute instruction:
...
        // This should be compiled to a jump table.
        switch(opinf&0xFF){

and a

            // PPU Registers
            switch(address&0x7){ 

Just bumping MAX_BRANCHES (to 16384) doesn't seem to help.  I didn't look at the resulting aborts, though.

Comment 2

[Mathieu Pellerin]

Attachment: namoroka vs chrome on linux screenshot

On my linux machine (Intel Core2 Duo 2.20ghz, 2gig ram), JSNES will run at about 6-10fps on Namoroka while Chrome will run it at 50fps and often reaches 60fps.

It'd be a real shame to have to use Chrome when I want to play Contra at work ;o)

Comment 3

[Doug Turner (:dougt)]

fwiw, i disabled jit in content and the perf is still pretty bad.

Comment 4

[Ben Turner (not reading bugmail, use the needinfo flag!)]

irc conversations suggest that the work in bug 509986 may help here.

Comment 5

[Ben Turner (not reading bugmail, use the needinfo flag!)]

er, bug 516264!

Comment 6

[RNicoletto]

I've changed the Platform tag to "All" since I can reproduce on Windows XP
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3

Comment 7

[Mathieu Pellerin]

JSNES got a nice boost from Jaegermonkey, cudos to the developers.

However, the latest trunk build still fails to be at par with Chromium. On my machine (both win7 & ubuntu10.10; intel core 2 CPU 3GHz & 2gig ram), JSNES oscillates between 42FPS and 58FPS. It's a pretty regular cycle (every 1sec, FPS will go down to 42 and then back up to 58).

It might be worth for developers to disect what's happening there. The remaining issue(s) might not be JS engine related.

In anyway, keep up the good work :)

Comment 8

[Mathieu Pellerin]

Disabling tracejit helps a bit.

Comment 9

[Brendan Eich [:brendan]]

How is this doing in tracemonkey tip? How about with TI?

/be

Comment 10

[(not currently active) Ted Mielczarek]

Runs smooth like butter on a mozilla-central nightly for me, constant 58FPS even with sound enabled.

Comment 11

[Brendan Eich [:brendan]]

So WFM? How does the competition's tip do? New bug if not ~1x.

/be

Comment 12

[RNicoletto]

(In reply to comment #11)
> So WFM? How does the competition's tip do? New bug if not ~1x.
> 
> /be

Performance have been greatly improved with the latest nightly. However:
1. On my PC (spec here ==> http://pastebin.com/UWKYgctH) Chrome 12 is faster and smoother.
2. Clicking on "Zoom in" button drastically reduce Firefox performance while it seems have no impact on Chrome.

Comment 13

[nemo]

Well, since comment #9 asked...

Selected Bubble Bobble ROM, clicked on zoom in, waited until the screen settled.

~35-38fps  FF4
~40-43fps  FF JM nightly no TI
~42-45fps  FF JM nightly, TI
~54-58fps  Chrome 12
~49-57fps  Chromium nightly

So, at least the title does not quite seem to be accurate anymore.  more like 1.5x.  Over here anyway.

Comment 14

[nemo]

More recent results from last month, idling in bubble bobble:
Firefox 8: 58-59fps and smooth, running in my Windows VM.  Did not max out CPU.
Chrome 15: essentially identical to Firefox
Opera 11.6: essentially identical to Firefox and Chrome.

Safari 5.1.2: Similar frame rate and CPU usage, *however* it repeatedly freezes every couple of seconds and seemed more stuttery when it wasn't freezing.
Webkit nightly from 2011-12-06: behaved the same as Safari 5.1.2.


IE9: averaged 55-56fps instead of 58-59fps but was smooth.

So, anyway, I guess this can be considered fixed?

Comment 15

[RNicoletto]

(In reply to nemo from comment #14)
> More recent results from last month, idling in bubble bobble:
> Firefox 8: 58-59fps and smooth, running in my Windows VM.  Did not max out
> CPU.
> Chrome 15: essentially identical to Firefox
> Opera 11.6: essentially identical to Firefox and Chrome.
> 
> Safari 5.1.2: Similar frame rate and CPU usage, *however* it repeatedly
> freezes every couple of seconds and seemed more stuttery when it wasn't
> freezing.
> Webkit nightly from 2011-12-06: behaved the same as Safari 5.1.2.
> 
> 
> IE9: averaged 55-56fps instead of 58-59fps but was smooth.
> 
> So, anyway, I guess this can be considered fixed?

I can confirm performance gain, at least with latest nightly on Windows 7 64-bit.

Comment 16

[Nicholas Nethercote [inactive]]

Thanks for the confirmation!

Comment 17

[Daniel C]

If you get 58-60 FPS in Fx then your computer is probably fast enough to hide any performance difference because the source has:

preferredFrameRate: 60

For me, there is still a difference.

Fx version: Mozilla/5.0 (X11; Linux x86_64; rv:12.0a1) Gecko/20120118 Firefox/12.0a1

Chromium version: 15.0.874.106 (Developer Build 107270 Linux) Ubuntu 11.10

Some of the simpler games hit ~58 FPS but Lemmings shows a significant difference.

Steps:
1. Select Lemmings and wait for it to download.
2. Click Restart and note the current time.
3. Observe FPS while game is loading.
4. When the game gets to the start screen note the current time.
5. Observe FPS at load screen.

For me, here are the results.

Time to load:

Fx: 42s
Chromium: 21s

FPS during intro:

Fx: ~28 FPS
Chromium: ~58 FPS

FPS at start screen:

Fx: ~33s
Chromium: ~58 FPS

So on my machine, Fx is about 100% slower (2x) than Chromium in this testcase.

This is an unfortunate side effect of developers typically having machines much faster than the average user.

Can someone else without a superfast machine do the same test as above? Reopening for now.

Comment 18

[Till Schneidereit [:till]]

Unfortunately, on my mid 2009 MBP (2.8 GHz) with OS X 10.7 the ROMs still don't play without stuttering. In a clean profile with today's nightly, I get 54-58FPS, but movements stutter every few hundred ms or so. 

While a ROM is running, I get very short compartmental GCs almost exactly every 500ms:

GC(T+24.1) Type:Comp, Total:8.4, Wait:0.1, Mark:5.9, Sweep:2.4, FinObj:0.1, FinStr:0.0, FinScr:0.0, FinShp:0.3, DisCod:0.6, DisAnl:0.5, XPCnct:0.6, Destry:0.0, End:0.6, +Chu:0, -Chu:0, Reason:Maybe

GC(T+24.6) Type:Comp, Total:9.1, Wait:1.3, Mark:5.5, Sweep:2.3, FinObj:0.1, FinStr:0.0, FinScr:0.0, FinShp:0.3, DisCod:0.3, DisAnl:0.5, XPCnct:0.6, Destry:0.0, End:0.7, +Chu:1, -Chu:1, Reason:Maybe

GC(T+25.1) Type:Comp, Total:8.4, Wait:0.1, Mark:6.1, Sweep:2.2, FinObj:0.1, FinStr:0.0, FinScr:0.0, FinShp:0.3, DisCod:0.4, DisAnl:0.5, XPCnct:0.6, Destry:0.0, End:0.6, +Chu:0, -Chu:0, Reason:Maybe

GC(T+25.7) Type:Comp, Total:8.5, Wait:0.1, Mark:5.8, Sweep:2.6, FinObj:0.1, FinStr:0.0, FinScr:0.0, FinShp:0.3, DisCod:0.3, DisAnl:0.9, XPCnct:0.6, Destry:0.0, End:0.6, +Chu:0, -Chu:0, Reason:Maybe

GC(T+26.2) Type:Comp, Total:8.5, Wait:0.1, Mark:6.1, Sweep:2.3, FinObj:0.1, FinStr:0.0, FinScr:0.0, FinShp:0.3, DisCod:0.3, DisAnl:0.6, XPCnct:0.7, Destry:0.0, End:0.8, +Chu:0, -Chu:0, Reason:Maybe

It seems like, while the GCs are very fast, they are enough to cause a very noticeable stutter because the CPU is already maxed out even without them.

Comment 19

[Till Schneidereit [:till]]

The Lemmings ROM runs with a slightly higher overall FPS than the Mario Bros. one: About 58FPS. During the intro, there are only two short global and one compartmental GC, which cause a slight stutter (but that's less noticeable than in the Mario Bros. ROM):

GC(T+9.0) Type:Glob, Total:27.5, Wait:0.5, Mark:15.9, Sweep:10.3, FinObj:1.8, FinStr:0.1, FinScr:0.2, FinShp:1.6, DisCod:1.3, DisAnl:3.8, XPCnct:0.6, Destry:0.0, End:1.3, +Chu:50, -Chu:1, Reason:  API

CC(T+11.0) collected: 2012 (2012 waiting for GC), suspected: 2329, duration: 6 ms.

GC(T+14.5) Type:Glob, Total:21.6, Wait:0.1, Mark:15.9, Sweep:5.3, FinObj:0.5, FinStr:0.0, FinScr:0.1, FinShp:1.0, DisCod:0.6, DisAnl:1.8, XPCnct:0.5, Destry:0.0, End:0.7, +Chu:11, -Chu:23, Reason:  API

CC(T+19.5) collected: 46 (46 waiting for GC), suspected: 104, duration: 4 ms.

GC(T+20.7) Type:Comp, Total:13.4, Wait:0.9, Mark:9.4, Sweep:3.0, FinObj:0.1, FinStr:0.0, FinScr:0.0, FinShp:0.3, DisCod:0.4, DisAnl:1.5, XPCnct:0.4, Destry:0.0, End:0.4, +Chu:35, -Chu:1, Reason:Maybe

Once the intro is finished and the start screen is shown, though, the frequent compartmental GCs start again (I suppose it would stutter, too, but there's not enough movement to see that):

GC(T+26.4) Type:Comp, Total:12.5, Wait:0.1, Mark:9.9, Sweep:2.5, FinObj:0.1, FinStr:0.0, FinScr:0.0, FinShp:0.3, DisCod:0.4, DisAnl:1.0, XPCnct:0.4, Destry:0.0, End:0.4, +Chu:30, -Chu:27, Reason:Maybe

GC(T+27.5) Type:Comp, Total:12.9, Wait:0.1, Mark:10.0, Sweep:2.8, FinObj:0.1, FinStr:0.0, FinScr:0.0, FinShp:0.3, DisCod:0.4, DisAnl:1.3, XPCnct:0.4, Destry:0.0, End:0.4, +Chu:0, -Chu:0, Reason:Maybe

GC(T+28.6) Type:Comp, Total:26.5, Wait:0.1, Mark:10.1, Sweep:2.5, FinObj:0.1, FinStr:0.0, FinScr:0.0, FinShp:0.3, DisCod:0.4, DisAnl:0.9, XPCnct:0.4, Destry:0.0, End:14.2, +Chu:0, -Chu:0, Reason:Maybe

Comment 20

[nemo]

Ok, well, that's entirely different from the initial reason for filing the bug ;)

Comment 21

[Brendan Eich [:brendan]]

Sounds like this bug should be blocked by one of the GC tracking bugs, or else closed WFM or FIXED if appropriate.

/be

Comment 22

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

This sounds like a code discarding problem: the GCs are short, but the animation is still stuttery. Unfortunately, the game uses setInterval rather than requestAnimationFrame.

Comment 23

[André Bargull [:anba]]

Test case no longer accessible, therefore closing as INCOMPLETE.

Comment 24

[Marco Castelluccio [:marco]]

It is now available at https://jsnes.org/. I don't know if this is still reproducible though.

Comment 25

[tustamido]

Can't say about JSNES, but Firefox usually performs noticeably much worse when running web emulators. Low FPS and flawed sound. Some examples:

DOSBox - https://archive.org/details/win3_molesquest
GBA.js - https://people.ucsc.edu/~jvranek/Website/gbajs/index.html

Similar bugs (it seems):
bug 773936, bug 1683560, bug 774119, bug 873795
Some of these bugs are marked to macOS, but I use W10 and the bad performance is reproducible here.

Comment 26

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 19 votes.
:sdetar, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.