Bitcoin generator (SHA-256) 2X faster in Chrome

RESOLVED FIXED

Status

()

defect
RESOLVED FIXED
8 years ago
6 years ago

People

(Reporter: megabyte, Unassigned)

Tracking

(Blocks 1 bug)

Trunk
x86_64
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

()

Attachments

(1 attachment)

10.97 KB, application/x-javascript
Details
Reporter

Description

8 years ago
For the bitcoin generator at http://bitp.it/, which is essentially an SHA-256 benchmark in a Web Worker, I get the following results (Core i7-960, Windows 7 64-bit):

Chrome 13.0.767.1 ~11500
Opera 11.11 ~5800
Firefox Nightly 20110521 x64 ~5000
Safari 5.0.5 ~4700
Reporter

Updated

8 years ago
Thanks, Aaron.

Could you try the 32-bit Firefox on your machine as well?
Reporter

Comment 2

8 years ago
It's a bit worse:
Firefox Nightly 20110521 ~4900
Reporter

Comment 3

8 years ago
javascript.options.methodjit_always = true adds ~100
Posted file Shell version
Here's a shell version of the generator. I don't think the numbers are comparable, but I get these numbers:

- d8: > 7000-8000
- JM+TM: ~4000
- JM: 2000-3000
- TM: 8000-9000

TI does not help JM much here. 

Unfortunately, JIT flags for web workers are hardcoded to mjp...
The main problem is here:
--
var ...,
e = function (a, b)
{
    var c = (a & 65535) + (b & 65535),
        d = (a >> 16) + (b >> 16) + (c >> 16);
    return d << 16 | c & 65535
},
f = function ()
{
    var a = arguments[0];
    for (var b = 1; b < arguments.length; b++) a = e(a, arguments[b]);
    return a
},
...;
--
Performance of |f| is critical here. It's slow in JM because

1) arguments[b] is not optimized to argsub. It's an (arguments, getlocal, getelem) sequence. Result is that we end up in Arguments/GetElem stubs.

2) The call to |e| is a CALLNAME op. Adding an IC for CALLNAME is bug 624298.
Depends on: 624298
(In reply to comment #5)
> 1) arguments[b] is not optimized to argsub. It's an (arguments, getlocal,
> getelem) sequence. Result is that we end up in Arguments/GetElem stubs.
> 

Hm jsop_argsub is only used when the index is a constant int, of course. Adding a GetElem PIC for |arguments| is bug 616744.
Depends on: 616744
So related questions are:

1)  Why are we not tracing this?  Seems like that would help!
2)  _Could_ TI help here?
At least looking at comment 5, the main way TI would help would be to do bug 658638 --- much more robust handling for operations on non-escaping arguments.  With not a lot of work we should be able to make non-escaping arguments accesses about as fast as dense array accesses are now in JM+TI.  Hoping to do that bug this week.
Added the testcase to the AWFY assorted page (bug 649487, needs more tests!).
With bug 658638 and bug 624298 fixed, I get these rates from the shell version (average over five seconds):

js -m -n: 22023
d8: 11155
js -j: 9931
js -m -j -p: 5350
js -m: 3687
Sorry, forgot to update to TM tip first (so -m and -m -j -p did not reflect bug 624298).  Revised numbers:

js -m -j -p: 6219
js -m: 5397
http://hg.mozilla.org/projects/ionmonkey/rev/de23a9fc29db made IonMonkey the fastest JS Engine for this test now (89.7ms).

We probably can't resolve this bug until Ion is merged into m-c and enabled, but I figured an update here could be useful :)
(In reply to Jared Wein [:jaws] from comment #12)
> http://hg.mozilla.org/projects/ionmonkey/rev/de23a9fc29db made IonMonkey the
> fastest JS Engine for this test now (89.7ms).
> 
> We probably can't resolve this bug until Ion is merged into m-c and enabled,
> but I figured an update here could be useful :)

Based on AWFY results, it seems that we can.

(In reply to Jan de Mooij (:jandem) from comment #5)
> The main problem is here:
> --
> var ...,
> f = function ()
> {
>     var a = arguments[0];
>     for (var b = 1; b < arguments.length; b++) a = e(a, arguments[b]);
>     return a
> },
> ...;
> --
> Performance of |f| is critical here. It's slow in JM because
> 
> 1) arguments[b] is not optimized to argsub. It's an (arguments, getlocal,
> getelem) sequence. Result is that we end up in Arguments/GetElem stubs.

Bug 735406 is fixing this issue in IonMonkey by implementing the getter of arguments when we don't need to allocate an argument object.
We get 33000 hashes per second now, stays very stable. d8 starts at 28000 but after a few seconds it drops as low as 22000 ==> FIXED.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.