840927 - Nightly slow in JS based benchmark of http://create.stephan-brumme.com/eratosthenes/

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Mayank Bansal]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20130212 Firefox/21.0
Build ID: 20130212031120

Steps to reproduce:

1. Create fresh profile
2. Go to http://create.stephan-brumme.com/eratosthenes/ . Scroll down a bit.
3.  uncheck "show prime" and "PHP/AJAX"
4. Enter number as  100000000 . 
5.Press start


Actual results:

Nightly takes longer than IE10 !

IE10 :  9 seconds
nightly : 17 seconds
Chrome : 30 ish seconds
Opera : 40 ish seconds


Expected results:

faster than IE10, please.

Took a profile. IonMonkey is kicking into action, but is slower than IE10RC.

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

per JIT Inspector:

eratosthenesOdd : http://create.stephan-brumme.com/eratosthenes/ (line 462)function eratosthenesOdd(lastNumber)

   {
     var memorySize = (lastNumber-1) >> 1;

     // initialize
     for (var i = 0; i <= memorySize; i++)
       isPrime[i] = 1;

     // find all odd non-primes
     for (var i = 3; i*i <= lastNumber; i += 2)
       if (isPrime[i >> 1] == 1)
         for (var j = i*i; j <= lastNumber; j += 2*i)
           isPrime[j >> 1] = 0;

     // sieve is complete, count primes
     var found = (lastNumber >= 2) ? 1 : 0;
     for (var i = 1; i <= memorySize; i++)
       found += isPrime[i];

     return found;
   }

Comment 2

[Boris Zbarsky [:bzbarsky]]

The time here is dominated (80% of total time is there) by the js::ion::LessThanOrEqual call.  And most of _that_ is js::ToNumberSlow calling js_strtod and whatnot.

The point being that the lastNumber input to the function on the page is a string.  So all those wonderful "<= lastNumber" compares are having to convert that string to a number over and over again.

I'm going to point that out to the page author, so the testcase on the page might stop being useful once he fixes his bug....

Comment 3

[Boris Zbarsky [:bzbarsky]]

Oh, and the point is that making this faster means either caching the number or making the string-to-number conversion faster.

Comment 4

[Mayank Bansal]

the JS code is a direct translation of a C code the author wrote. In the C code he used strings for some performance reason, which he has explained on the page.

Comment 5

[Boris Zbarsky [:bzbarsky]]

The C code uses a string (more precisely a byte array) to store the set of "isPrime" booleans.  The JS code uses a "new Array()" for the equivalent.  The C code most certainly does not use a string for the lastNumber like the JS code does:

  int eratosthenesOdd(int lastNumber)

Comment 6

[Boris Zbarsky [:bzbarsky]]

Fwiw, page has been updated with a parseInt, and now we're fastest.

Might still be worth doing something about the slow string-to-number bits.

Comment 7

[Tom S [:evilpie]]

Uh parseInt(x), without a 10! Bug 654190 would probably help here.

Comment 8

[Mayank Bansal]

I did a retest there.  On the first attempt, Nightly gets 4.4 seconds. If you press start again, without refreshing teh browser, we get 1.04 seconds.

IE10 gets 2.2 seconds on the first run, 1.8 on the second.
Chrome gets 2.8 seconds on first run, and 1.9 seconds on the second run.

Comment 9

[Guilherme Lima]

Nightly 33.0a1 (2014-06-17)
1.952s / 1.668s

Chrome 35
2.543s / 1.768s

IE 11
2.862s / 1.453s

Firefox Beta (31)
4.4s / 1.667s

Comment 10

[Mayank Bansal]

I think a victory can be declared here.

Comment 11

[Emanuel Hoogeveen [:ehoogeveen]]

Retested to get some more recent numbers:

Nightly 41.0a1 2015-06-04 (32-bit)
1.863s / 0.458s

Nightly 41.0a1 2015-06-04 (64-bit)
1.671s / 0.445s

Chrome 45.0.2414.0 dev-m (64-bit)
1.217s / 1.001s (first load)
0.780s / 0.975s (subsequent loads)

I don't know if Chrome is doing some caching or if there was some lag spike going on the first time, but their performance on the asmjs version leaves something to be desired.

Comment 12

[Emanuel Hoogeveen [:ehoogeveen]]

By caching I mean on-disk caching. I restarted the browsers between runs, since Firefox also speeds up if you just keep clicking the button (presumably able to reuse the previously JITed code).