940062 - [WBGP] Principled Technologies's WebXPRT 2013 Face Detection regression

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P3)

Description

[Naveed Ihsanullah [:naveed]]

Firefox 25 is 5x slower than Firefox 22 on the Face Detection subtest of this benchmark. This has a large impact of our overall score. 

See also 935299

Comment 1

[Boris Zbarsky [:bzbarsky]]

Can we find a regression range?

Comment 2

[Naveed Ihsanullah [:naveed]]

Sean hypothesizes that the loss of JM is the cause of this regression. He looked at their some of their code and there are several very large function bodies. IM would bail but JM with chunk compilation could still JIT these. 

We lost JM between 22 and 23 so this seems likely.

Could we increase our function size limit to allow this test to get JITed? What would be the consequences of doing so?

Comment 3

[Jan de Mooij [:jandem]]

A profile shows we spend a lot of time in the VM because Baseline is not attaching a GETELEM stub. Fixing that should help a lot. I will investigate a bit more.

Comment 4

[Jan de Mooij [:jandem]]

Attachment: Testcase

Standalone HTML testcase. Runs the algorithm on the first image. Testcase is much slower than it was in Firefox 22.

(Note: if you want to run this in Chrome, you have to use the --disable-web-security command line flag.)

Comment 5

[Jan de Mooij [:jandem]]

Some numbers for the attached benchmark:

Firefox 22:      240 ms
Safari 6.0.5:    571 ms
Chrome 33:       285-320 ms
Firefox 25, 28: 1189 ms

This matches the ~5x slower Naveed posted in comment 0.

Comment 6

[Jan de Mooij [:jandem]]

Two problems:

(1) The slow GETELEM VM calls I mentioned in comment 3 are caused by typed array accesses with a double instead of int32 index. Baseline's typed array stubs should support double-to-int32 conversion of the index. I will post a patch for this. I think this should make us almost 2x faster.

(2) There are some functions that we Ion-compile a bunch of times. We should figure out why. These functions are pretty big but nothing extreme: bytecode size is 3400 bytes, we can compile that just fine with off-thread compilation.

Comment 7

[Jan de Mooij [:jandem]]

The main problem is that there's a JSOP_MUL with an operand that's |undefined| sometimes. Then Ion looks at the Baseline IC's to determine how to specialize this op, sees only an int32 stub and specializes as int32. This will bailout for |undefined| though and we don't enter the Ion code again.

Ion shouldn't look at the baseline cache if it had unoptimizable inputs. A fix for this gets us to 290-300 ms. About 50 ms slower than Firefox 22 but about as fast as Chrome and there's probably more we can optimize.

Comment 8

[Chris Peterson [:cpeterson]]

After Jan fixed bug 940925 in Firefox 28, we're still slower (~330 ms) than Firefox 22 (~220 ms) but we're about as fast as Chrome.

Comment 9

[Jan de Mooij [:jandem]]

For the attached benchmark (requires a webserver instead of file:// url):

Nightly: 343 ms
Chrome:  369 ms
Safari:  474 ms