Number.prototype.math benchmark

[Jorge]

Hi,

I've done a small benchmark in order to see how do the different
implementations handle the extra work required by this approach:

http://jorgechamorro.com/cljs/096/

Browser Math math (Mhz) Proto Math (MHz) Prop.
Opera 10.5 20.70 0.64 32.3x
FF3.6 23.46 1.04 22.5x
Webkit r54921 13.26 2.61 5,0x
Chrome 5.0.307.9 11.51 10.14 1,1x

It varies from very very bad 32.3x slower, to the nearly as fast as
Math.method 1.1x. I think that Chrome proves that there's room for
optimization, and that, if this were ever done natively, the
difference could easily be nil.

 

[Gregor Kofler]

Jorge meinte:

Hi,

I've done a small benchmark in order to see how do the different
implementations handle the extra work required by this approach:

http://jorgechamorro.com/cljs/096/
Ahem...

Browser Math math (Mhz) Proto Math (MHz) Prop.
Opera 10.5 20.70 0.64 32.3x

Opera 10.10 on Ubuntu AMD64:
935kHz / 291kHz ~ 3x

FF3.6 23.46 1.04 22.5x

FF3.5.8 on Ubuntu AMD64:
2.13MHz / 519.5kHz ~ 4x

Webkit r54921 13.26 2.61 5,0x

Midori 0.2.2 (WebKitGTK+ 1.1.21) on Ubuntu AMD64:
5.81Mhz / 2.07MHz ~ 3x

Chrome 5.0.307.9 11.51 10.14 1,1x

Chromium 5.0.330.0 on Ubuntu AMD64:
4.45MHz / 280.3kHz ~ 15x

It varies from very very bad 32.3x slower, to the nearly as fast as
Math.method 1.1x. I think that Chrome proves that there's room for
optimization, and that, if this were ever done natively, the
difference could easily be nil.

No on my computer/OS with my browsers...

Gregor

 

[Jorge]

No on my computer/OS with my browsers...

So your worst case is much better (15x vs 32.3x), but your best case
is much worse (3x vs 1.1x). Ok. Fine. Thanks!

 

[Gregor Kofler]

Jorge meinte:
Should be "Not".

So your worst case is much better (15x vs 32.3x), but your best case
is much worse (3x vs 1.1x). Ok. Fine. Thanks!

The interesting bit: Your best case (Chrome/Chromium) is the worst on my
setup.

Gregor

 

[Jorge]

Jorge meinte:


The interesting bit: Your best case (Chrome/Chromium) is the worst on my
setup.

Yep, interesting...

But, I need just *one* implementation in which it runs ~ as fast as
Math.method() to prove that it's possible, and I've got it: Chrome in
a Mac

 

[Jorge]

Chrome 4.0.249.89 on Windows NT
Test    Ops/sec
mathCos 2.15Mhz (0.00046600ms)
protoCos        4.04Mhz (0.00024744ms)

Are you sure ? That's pretty weird ! ... ¿?

In my WinNT virtual "box" it gives:

Chrome 4.0.249.89 on Windows NT
Test Ops/sec
mathCos 15.99Mhz (0.00006256ms)
protoCos 14.85Mhz (0.00006734ms)

Ratio: 1.07x

 

[Jorge]

Yes, to both.

http://img175.imageshack.us/img175/9949/mathcosvsprotocos.jpg

My system was under noticeably heavy load, or at least it felt very
unresponsive, at the time btw, if it matters much.

What happens if you hit the "run tests" button a few times more ? Do
you get the same results in every run ?

 

[Scott Sauyet]

How does that "prove that it is possible"? Doesn't writing the code and
seeing it execute prove the possibility, or even just knowing the
language's behaviour?

"possible to run approximately as fast as Math.method()"

The point is, I believe, that in at least one environment, this is a
viable technique, which might lend credence to the notion that if the
ES-implementations improve enough, this could be worthwhile doing. It
probably wouldn't be worthwhile considering much further if it was an
order or two of magnitude slower in all implementations. This finding
does not of course imply that we could use this for math-heavy work,
even in Chrome, but it does say that we might be able to do so some
day.

I personally don't find

(2).pow(10)

much more expressive than

Math.pow(2, 10).

My college degrees were in mathematics, and I see notational
conventions change regularly over domains, so I don't expect my
programming languages fit into any particular model for this. It's an
interesting idea, though, to my mind.

-- Scott

 

[Jorge]

How does that "prove that it is possible"? Doesn't writing the code and
seeing it execute prove the possibility, or even just knowing the
language's behaviour?

Performance speaks to viability rather than possibility, and where
viability related to performance is in question the worst case is most
significant; is the worst too bad or good enough. If the worst case is
acceptable then anything better will be OK as well.

Doesn't it prove that it can run ~ as fast as Math.method() ?

I mean, the code I'm benchmarking -at least according to the specs-
does an additional function call for protoCos that mathCos does not
have to do, and an additional lookup through the prototype chain of
the wrapper Number object, and an additional new Number() object, but
still, in Chrome, it runs nearly as fast. The observed difference must
be due to one of those (I'd bet it's the additional f() call), right ?
or not ?

And, if running non-natively it runs nearly as fast, when/if
implemented natively it could very likely be as fast as if not faster,
in spite of the additional steps spec'ed in the specs, those that
Pointy's been Pointyng out Or if not native, at the very least, we
know that with an optimized JS engine the difference could be diminute
(a few hundredths %).

 

[Jorge]

<span id="noNo">(a few hundredths %)</span>

#noNo { text-decoration:line-thru; }