DOS emulator where Chrome is 4X faster than FF

NEW
Unassigned

Status

()

defect
7 years ago
2 years ago

People

(Reporter: kodwyer2002, Unassigned)

Tracking

(Depends on 1 bug)

Trunk
x86
macOS
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [js:t], URL)

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2

Steps to reproduce:

This is a Chrome is faster than FF scenario. To be filed under "core/javascript engine". Dosbox port to Js.  Autorunning a DOS 64k demo with a precalc stage and status bar for easy comparison.  

address: 8.retropcdemos.appspot.com

When enabling dynarec core
8.retropcdemos.appspot.com?verbose=true&core=dynamic&compilethreshold=1000



Actual results:

Using a wall clock the diff is 4X on my machine.  FF version 13 versus Chrome 22 dev.    Even more pronounced when using dynarec (Js code block generating) core, diff over 10X.  Oh well, seemed like a good idea at the time.
Memory use is also markedly different in both cases.


Expected results:

JIT magic to occur.
Assignee: nobody → general
Component: Untriaged → JavaScript Engine
Product: Firefox → Core
Version: 13 Branch → Trunk
This is exciting.

  35% of the time is under js::CrossCompartmentWrapper::set (and 43% total is under the
    corresponding SetElem stub calls).
  20% of the time is under js::CrossCompartmentWrapper::get (and 28% total is under the
    corresponding GetElem stub calls).

Luke, Bobby, does Firefox 13 have cpg?  Or is what I'm seeing even slower than Firefox 13?

Reporter, does the testcase involve script running in one window touching objects in another window or frame?  Based on the profile it certainly looks like it does...
Oh, and to be clear... of that 35% under CrossCompartmentWrapper::set, about 2% is actually doing sets on a typed array.  The rest is proxy overhead, JSComparment::wrap, js::ContextStack::pushDummyFrame.  pushDummyFrame via that callpath is 10% of the profile I'm looking at!
Ah, yes.  No cpg in Firefox 13.  This is ridiculously, ludicrously slower on trunk than in Fx13. :(

I filed bug 774119 on the trunk behavior.  There's no point even measuring/profiling here until that's fixed.  :(
Depends on: 774119
Posted image Jit Inspector screen
Ah so I guess this was the very hot access, I saw with the inspector.
Status: UNCONFIRMED → NEW
Ever confirmed: true
We should definitely rip out dummy frames: bug 625199.
(Reporter)

Comment 6

7 years ago
On the question of one window touching another window/frame.  If it is doing what you suggest, it isn't by design.  The emulator is a port of jDosbox to Js with the help of Google web toolkit (GWT).  More info on sourceforge.net/projects/jsdosbox/ (jsdosbox.apppsot.com). I guess i'm coding a level removed.   The emulator is however more advanced then my previous effort sourceforge.net/projects/jspcemulator/ (pc-emulator.appspot,com) from way back.  Curiously the port of JPC ran in FF somewhat closer to the speed of Chrome then what is seen here.  That said they work very differently and much of the tech I added wasn't available back then.
Blocks: WebJSPerf
Whiteboard: [js:t]
Assignee: general → nobody
You need to log in before you can comment on or make changes to this bug.