On 01/25/2017 03:23 AM, Nicolas B. Pierron wrote:
Thanks for this email, and these investigations.
On 01/25/2017 05:47 AM, Steve Fink wrote:
[what is slower in Fx vs Chrome]>> - eliminate all or most bailouts
I will try to explain more the details here, and hopefully help people
understand why this is a bad idea to eliminate *all* bailouts.
When we have no bailout from a code produced by a compiler, this means
that the compiler generated code which is infallible, and thus handle
all the cases. Basically, this implies that we have to handle all the
cases, this is what our Baseline compiler do.
Bailouts are a necessary evil. They give us the opportunity to remove
code paths which are unlikely to be used, and thus to have more
optimization coming out of it, such as most basic one: unboxing values.
Bailouts are a JIT compiler trade-off. They are optimization which can
be costly to proove, bailouts are a trade-off between the time we spend
in an all-guarantee compiler, and the time we get we a heuristic-based
compiler. Also, a heuristic-based compiler has more opportunities to
find optimizations can cannot be safely guaranteed.
I honestly would prefer to optimize our compiler such that we could
afford more heuristic-based optimizations, including the trade-off of
having more bailouts. And, I already suggested ways to achieve that in
SpiderMonkey!
Let's not follow other JS engine on this fact, there is much more
performance opportunities to gain by embracing bailouts than refusing them.
Sorry, I didn't meant to imply that eliminating bailouts is at all a
good idea. I understand those reasons. But it *is* a natural reaction to
seeing the current profiler output -- the only information it gives is a
list of bailouts, and the very name implies something bad. And most
importantly, when people are looking for stuff within their control to
fix, it is bailouts are an obvious target -- since it's possible to
change the JS code to make things single-typed, people are going to kill
themselves trying to do that because it makes all those scary bailouts
go away. (And then they'll be pissed off because their code runs slower.)
So bailout counts *are* a good example of a naive suggestion that will
come up over and over again when people start looking at performance
problems. Which implies to me that we need to give them a better metric
to focus on. Repeated bailouts, or compiles that ended up not being
worth it, or something.
_______________________________________________
dev-tech-js-engine-internals mailing list
dev-tech-js-engine-internals@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
