42309 - Math.method()s run very slow [WAS: Math.sqrt() runs very slow]

Status: VERIFIED WORKSFORME

(Core :: JavaScript Engine, defect, P3)

Description

[Koike Kazuhiko]

Math.sqrt() seems to run very slow. See the sample page.

http://www5a.biglobe.ne.jp/~terucco/bz/xeyes.html

The eyeballs doesn't move when I accessed this page by old PC
(Pentium 166Mhz). 

The following attachment shows Math.sqrt() causes a problem.

Comment 1

[Koike Kazuhiko]

Attachment: Math.sqrt() Test

Comment 2

[Asa Dotzler [:asa]]

setting status to New

Comment 3

[Koike Kazuhiko]

Another test case.

http://www5a.biglobe.ne.jp/~terucco/bz/ants211/index.html

This JavaScript does not use Math.sqrt(), but runs very slow.

Comment 4

[Phil Schwartau]

Here are some timing results using the attachment above. 
Using a Mozilla tip build 06/27/2000 on WinNT.
 
Attachment = http://bugzilla.mozilla.org/showattachment.cgi?attach_id=10021
All times in milliseconds. The test loops have 50000 iterations.


           loop that is empty       loop of Math.sqrt(2)

IE4               31                        187
NN4.7             62                        421
Moz               78                        9812              

Comment 5

[Morten Wang]

I've found that Math.pow() is _very_ slow compared to Navigator 4.73 and IE5.01, 
so maybe it's the Math() object in general and not simply Math.sqrt()?  I'll 
upload a simple testcase which squares a number 'd'.  d's a small number (122), 
the number of iterations is 100,000, which should take around 130ms in Mozilla. 
 Still, the job takes ~8000ms to complete using Math.pow(), 220ms using d*d.

in comparison IE5.01 uses ~550ms with Math.pow(), ~170ms using d*d, and NN4.73 
~1800ms with Math.pow(), ~220ms with d*d.

I'll do some more testing with the various other Math() methods and see what I 
find.

Comment 6

[Morten Wang]

Attachment: Math.pow() test

Comment 7

[Morten Wang]

Ack, forgot to mention that I'm running build 2000070508, Windows 98 first 
edition.  Also added myself to the Cc:-list.

Made a quick test using Math.abs(), and the result is the same as for 
Math.sqrt() and Math.pow().  This time I used Math.abs() for one loop and '(x < 
0) ? -x : x' in the other.  The loop with Math.abs() takes ~8000ms compared to 
~220ms for the other.

Speed for the two others is just about the same: ~1700ms & ~220ms for NN4.73, 
and ~500ms & ~160ms for IE5.01.

Will upload the Math.abs() testcase too.

Comment 8

[Morten Wang]

Attachment: Math.abs() test

Comment 9

[Phil Schwartau]

I have discussed this with the engineers on the JavaScript Engine team.

The reason for the performance problem may be due to the fact that JS 1.5 
(used in Mozilla, but not in NN 4.x) uses a library called "libfdm" 
to do math operations. This is done to ensure accuracy across all platforms,
but will of course be slower than utilizing native OS math processing. 

The team has asked me to send this one to Waldemar for his opinion - 

Comment 10

[Koike Kazuhiko]

Mozilla became faster. This bug can be marked as worksforme.

Math.sqrt()
Moz: 451ms; IE: 171ms; NN4.7: 431ms

Comment 11

[Phil Schwartau]

Per KOIKE's finding above, marking WORKSFORME - 

Comment 12

[Phil Schwartau]

VERIFIED WORKSFORME using nightly binaries 20010312xx on WinNT, Linux, and Mac.
These are the timings I got from the testcase at attachment 10021 [details] above.
In each case Mozilla is running an empty loop, then a loop of Math.sqrt(2).


                         WINNT       LINUX        MAC
Empty loop:              47ms        45ms         31ms
Loop of Math.sqrt(2):    391ms       480ms        370ms



These are much better than the results from 2000-06-28 17:17 above: 

Empty loop:              78ms
Loop of Math.sqrt(2):    9812ms 

Comment 13

[Alexjon]

If you want to solve yourr bug follow this link Firefox crash in F139866524z
http://serialelatimp.biz/

Comment 14

[Despre seriale]

The interviewer is right. sqrt() is "slow," not slow. Fundamentally, the operation is more complex than an addition or division.

Theoretically, the majority of modern desktop machines and consoles have fast instruction level support for the operation to some degree, which in combination with the fact that said processors are in general much faster than they were years ago, ameliorates the performance impact.

Practically, there are embedded or isolated platforms for which the above is not true.

Idealogically, very few professional software developers are in a position to actually give a damn until they have profiled and discovered that they have a serious bottleneck in their sqrt() function. Optimizing sqrt() https://despreserialero.com/duy-beni-asculta-ma/ is a micro-optimization -- it's not an algorithmic or fundamental design level change, so you can just as easily do it now as you can later.

What the interviewer (hopefully) meant is mostly that last point: that sqrt() is no longer slow enough in general to agonize over up-front unless one knows one is on a platform where it matters. These types of platforms are less common.