Status: New
Owner: ----
New issue 2741 by [email protected]: max_opt_count is implemented using
the wrong kind of limit
http://code.google.com/p/v8/issues/detail?id=2741
It seems I've found one major flaw in V8, as I've been trying to relax the
optimizers aggressivity lately from misbehaviour and I'm confused as to why
this variable is a loop count instead of a weight/strength/multiplier
value. I have been trying to tune this runtime variable but it shouldn't
even be a threshold, you try to override it in places anyway showing its
pointless being implemented as it is now regardless. It should be a weight
or % of the overall loop and be more dynamic in it's aggression. Firefox's
SpiderMonkey basically behaves right for this case. It doesn't compile
unneeded code that it will never see again intelligently from the tracing
and V8 really needs to do a similar loop length heuristic to judge the
benefit of compiling the loop beyond interpretation because this is just
unbelievably bad and if changed should be significant and bring gains
EVERYWHERE.
There are ways to reproduce it's bad behaviour even thought I wish I had
some custom .js file to demonstrate this but this will have to do.
Set the --js-flags="--max_opt_count=1000" or something high and try out two
Octane benchmarks which degrade and are affected unlike the others tests,
pdf.js degrades more and more the higher the max_opt_count variable is set
above 40 or so. The "CodeLoad" test behaves oppositely but it's effect is
seen after you disable crankshaft with --js-flags="--nocrankshaft". pdf.js
barely suffers and CodeLoad actually increases in perf 2000-4000 points in
the benchmark with the optimizer disabled... making the problem obvious and
really stick out. Makes me wonder why the heck it's a flat out # and not a
factor of loop length. Code even tries to compensate by forcing it to
compile regardless far after setting the no-opt value but obviously that's
not working at all as intended here:
https://code.google.com/p/v8/codesearch#v8/trunk/src/objects-inl.h&l=4839
so just simplafy and make it more dynamic and on-demand.
Theres only one other issue on the tracker which came remotely close to
this behavour and it is https://code.google.com/p/v8/issues/detail?id=2139
regarding this weird yet catchy music video:
http://digisnap.bplaced.net/70s/ It is affected by having it's initial load
go so slow I didn't even wait, I reloaded chrome with a lower max_opt_count
to let it cache the JS and found it to not be as impacted afterwards but
the first time ever trying to load that site with a large opt value was
painful, 20 seconds per load bar progress indication bad.
I hope I gave enough information regarding how to repro as an end-user, and
I hope this can be changed to be how aggressive the compiler should be and
not just be some useless limit which isn't even obeyed as the pdf.js
performance shows.
--
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
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
