1526288 - sin() extremely slow

Status: NEW

(Core :: JavaScript Engine, defect, P3)

Description

[linuxcbon]

Attachment: sunspider-3d-morph.txt

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:65.0) Gecko/20100101 Firefox/65.0

Steps to reproduce:

Run http://dromaeo.com/?sunspider in seamonkey then in firefox separetly
and compare the results for 3D Mesh Transformation
(Transforming the points of a matrix. No visual output.)

source code for js http://dromaeo.com/tests/sunspider-3d-morph.html

Actual results:

Seamonkey 2.49.4 (64 bits)
3D Mesh Transformation: 1457.40runs/s

Firefox 65.0 (64 bits)
3D Mesh Transformation: 234.09runs/s

Expected results:

Firefox must faster for 3D Mesh Transformation

Comment 1

[Alice0775 White]

It regressed in 62 cycle in m-c.

Good build: approx. 1400runs/s
Bad build: approx. 700runs/s

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=13efb4f58614a7bb20ca3149b0ca50cf92c7a13d&tochange=c980318f4f82e2175a1f23c6c4d301f01dbd4ed1

Triggered by: Bug 1469044

Comment 2

[Matthew Gaudet (he/him) [:mgaudet]]

When we removed the MathCache we were aware there was a potential for regressions (and in fact, testing on Perfherder at the time highlighted a 27% degradation on Sunspider's 3d-morph in the shell.

It would be nice to try to get some of this performance back at some point, but I'm labelling P3 as I don't think this is a high priority as Sunspider doesn't reflect real web performance these days, and it's definitely not sufficient to warrant bringing back the MathCache.

Comment 3

[Matthew Gaudet (he/him) [:mgaudet]]

PS: Thanks for the bisection Alice0775

Comment 4

[linuxcbon]

I disagree with Matthew Gaudet .

Seamonkey 2.49.4 (64 bits) 3D Mesh Transformation: 1457.40runs/s
Firefox 65.0 (64 bits) 3D Mesh Transformation: 234.09runs/s

It's not a 27% degradation, but much more.
So something is wrong and should be investigated.

Comment 5

[Matthew Gaudet (he/him) [:mgaudet]]

One quick question: What kind of hardware are you using? You're right that the degradation you report is is more severe than anything Alice0075 or I have seen.

I just checked SeaMonkey on OS/X, Firefox 52, and Yesterday's nightly.

Seamonkey: 4972.00runs/s
Firefox 52: 5076.20runs/s
Firefox 67 (20190315215543): 2486.93runs/s

Unfortunately my attempts to run the same experiment on Linux were unsuccessful; Builds of 52 just tab-crash immediately in my VM.

Having said that, a copy of 67 in my VM is also seeing only 2000 runs / s -- slower than the same build on OS/X. It is possible the impact of the Math cache is exacerbated by a slow GLIBC implementation of one of the trigonometric functions we cached.

If the hardware you're using isn't optimized by glibc, we could see a degradation of the scale you're talking about.

I stand by my prioritization however: This code purely tests the performance of sin(); while there may be some websites where this is a bottle neck, I suspect they're few and far between and given limited engineering resources, it's not going to bubble to the top of our list any time soon.

Comment 6

[linuxcbon]

Oh.....that's normal that you don't see the performance problems, it's because your CPU is fast , so very few performance problems appear.
I use a slow dualcore AMD Athlon for testing , so I can detect the performance problems easily

Coming to this bug here : yes sin() is very slow, but you hardly notice it if you use a fast CPU.
Many people still use slow CPUs so this SINUS COSINUS TANGENT bug really affects a lot of people.