Issue 2223 in v8: 15x slower than spidermonkey on skinning benchmark

[codesite...@google.com]

Status: New
Owner: ----

New issue 2223 by alonza...@gmail.com: 15x slower than spidermonkey on
skinning benchmark
http://code.google.com/p/v8/issues/detail?id=2223

Attached is a benchmark of vertex skinning compiled with emscripten, in
HTML and shell versions (the latter is now possible after typed arrays were
added to d8, which is great). After running it prints out the number of
milliseconds it took.

In both the shell and the browser, v8 takes 15 seconds while spidermonkey
takes 1 second. Similar ratios shows up in a few other emscripten-compiled
benchmarks and projects as well. Please let me know if there is something
we can tweak in emscripten to work around this problem.


Attachments:
skinning.html 99 KB
skinning.js 99 KB

[codesite...@google.com]

Comment #1 on issue 2223 by veg...@chromium.org: 15x slower than

spidermonkey on skinning benchmark
http://code.google.com/p/v8/issues/detail?id=2223

I looked at it briefly sometime ago and here are my observations.

Benchmark spends all the time in a single function that is called only once.

It has many locals and we fail to perform OSR in it due to constraints on
LUnallocated operand encoding.

However just fixing this is not enough. If I steal some bits in the
encoding to increase number of locals that OSR can handle I see the
following: we OSR function once then deoptimize on soft-deoptimization
(@deoptimize) and never attempt to OSR function again unless I artificially
bump loop nesting level to kMaxLoopNestingMarker immediately. I did not
look why this happens, but it might be a caused by a bug in our stubs that
perform counting on back edges.

It seems that there are two major issues here :

1) LUnallocated encoding prevents us from doing an OSR;
2) some issue with back edge counting causes us not to re-attempt OSR again;

Additional issue is soft-deoptimization itself, it might be that type
propagation inside the function could have allowed us to avoid it, but I
did not analyze that.

[codesite...@google.com]

Comment #2 on issue 2223 by sven...@chromium.org: 15x slower than

spidermonkey on skinning benchmark
http://code.google.com/p/v8/issues/detail?id=2223

Regarding LUnallocated encoding: I've seen the same on the Emscripten
version of Box2D at http://kripken.github.com/misc-js-benchmarks/box2d/.

I'll submit a small CL so that we can see the reason for disabling
optimization a bit easier.

[codesite...@google.com]

Comment #3 on issue 2223 by alonmozi...@gmail.com: 15x slower than

spidermonkey on skinning benchmark
http://code.google.com/p/v8/issues/detail?id=2223

Here is an updated version of this benchmark with additional emscripten
optimizations not in the previous version (we can now remove more temporary
variables now than before which I hoped would help). However v8 is still
14.22x slower on this benchmark.

Attachments:
skinning.js 49.9 KB

[codesite...@google.com]

Updates:
Status: Accepted

Comment #4 on issue 2223 by sven...@chromium.org: 15x slower than

spidermonkey on skinning benchmark
http://code.google.com/p/v8/issues/detail?id=2223

I've tried the skinning.js from comment #3 with our current v8 from
bleeding_edge, and it finishes after 30ms, while the skinning.js from the
original post still takes 13.2 seconds. In the 30ms run, nothing is
actually crankshafted (apart from valueOf/IsPrimitive/toString), but I
can't see the reason for this. There are no deopts and there is no OSR,
which in summary seems a bit strange. Although 30ms looks OK compared to
13.2 seconds, we should look into this, I think.

Which version of v8 have you used for your testing? Is it possible to get a
non-minified version of the latest skinning.js?

[codesite...@google.com]

Comment #5 on issue 2223 by alonza...@gmail.com: 15x slower than

spidermonkey on skinning benchmark
http://code.google.com/p/v8/issues/detail?id=2223

Sorry, I forgot to include the commandline arguments in that last version.
Attached is a version with the arguments, also non-minified as you asked.


Attachments:
skinning.nice.js 119 KB

[codesite...@google.com]

Comment #6 on issue 2223 by weiliang...@gmail.com: 15x slower than

spidermonkey on skinning benchmark
http://code.google.com/p/v8/issues/detail?id=2223

A simple test case to demonstrate the 'many locals' issue. V8 is more than
3X slower than SpiderMonkey.

Attachments:
locals.js 7.1 KB

[codesite...@google.com]

Comment #7 on issue 2223 by alonza...@gmail.com: 15x slower than

spidermonkey on skinning benchmark
http://code.google.com/p/v8/issues/detail?id=2223

Here's an updated version of this benchmark. v8 (latest svn) is now 4.5x
slower than spidermonkey on my machine, which is a significant improvement
over the original 15x from before.


Attachments:
skinning.js 105 KB

[codesite...@google.com]

Comment #8 on issue 2223 by sven...@chromium.org: 15x slower than

spidermonkey on skinning benchmark
http://code.google.com/p/v8/issues/detail?id=2223

I took a quick look, and things are a bit strange: As before, basically all
time is spent in a single function (_main). The problem is that we do OSR
(on-stack replacement) very late, so we run almost all the time in
non-optimized code. Fractions of a second before we terminate, we finally
do OSR, deopting almost immediately, because we boldly go where no v8 has
gone before... :-P (not nice, but not the main problem)

In a nutshell: The benchmark currently measures the performance of our
non-optimized code, because we do an extremely bad OSR decision. Someone
should definitely look into this.

[codesite...@google.com]

Updates:
Status: Fixed

Comment #9 on issue 2223 by jkum...@chromium.org: 15x slower than

spidermonkey on skinning benchmark
http://code.google.com/p/v8/issues/detail?id=2223

We've fixed this a while ago.

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings