* * Vyacheslav Egorov <[email protected]> 於 2011年12月30日上午4:33 寫道：
> If you run with --print-code --code-comments you will see generated code > (v8 should be build with objectprint=on disassembler=on) and you'll have to > locate bailout in the code and figure out why it happens. > > If it happens only once then the reason it probably that the function was > optimized before it got correct type feedback. > > I took a very quick look through 2nd version of code that V8 generates > for Arbiter.applyImpulse, without trying to understand what it does, just > by looking for inefficiencies. I don't see anything obvious but there are > two things: > > 1) V8 seems to exhaust inlining budget when trying to inline things into > applyImpulse. It leaves one call in the loop not inlined, which prevents > proper LICM and probably causes unnecessary boxing. If I relax inlining > budget by --nolimit-inlining I get 10% boost on the benchmark. > > 2) There are fields mutated in the loop that contain floating point > values. This currently requires boxing (and boxing requires heap > allocation, heap allocation puts pressure on GC etc). I wonder if you can > put typed arrays (e.g. Float64Array) to work here. > > -- > Vyacheslav Egorov > > > On Thu, Dec 29, 2011 at 4:18 AM, Joseph Gentle <[email protected]> wrote: > >> Wow, thats awesome information. That would explain why the function in >> question is slow, and why inlining a couple of the function calls it makes >> decreases overall speed. >> >> How do I read the trace I get back? I'm getting this: >> >> **** DEOPT: Arbiter.applyImpulse at bailout #49, address 0x0, frame size >> 264 >> [deoptimizing: begin 0x1b70ac6a67f1 Arbiter.applyImpulse @49] >> translating Arbiter.applyImpulse => node=432, height=216 >> 0x7fff6f711630: [top + 248] <- 0x3ebe7f33eb9 ; [esp + 296] >> 0x3ebe7f33eb9 <JS Object> >> 0x7fff6f711628: [top + 240] <- 0x2457afa6b4ad ; caller's pc >> 0x7fff6f711620: [top + 232] <- 0x7fff6f7116c0 ; caller's fp >> .... >> >> I assume address 0x0 means something the function is doing is hitting a >> null object. Does bailout #49 mean anything? The function is (later) >> repeatedly optimized and deoptimized again with bailout #8. How do I track >> these down? >> >> -J >> >> >> On Monday, 26 December 2011 23:56:31 UTC+11, Vyacheslav Egorov wrote: >> >>> This is a multiplication stub that is usually called from non-optimized >>> code (or optimized code that could not be appropriately specialized). >>> Non-optimizing compiler does not try to infer appropriate representation >>> for local variable so floating point numbers always get boxed. >>> >>> If this stub is high on the profile then it usually means that >>> optimizing compiler either failed to optimize hot function which does a lot >>> of multiplications or it failed to infer an optimal representation for some >>> reason. >>> >>> Bottom up profile should show which functions invoke the stub. Then you >>> should inspect --trace-opt --trace-bailout --trace-deopt output to figure >>> out what optimizer does with those function. >>> >>> -- >>> Vyacheslav Egorov >>> >>> On Mon, Dec 26, 2011 at 7:00 AM, Joseph Gentle <[email protected]> wrote: >>> >>>> What does it mean when I see BinaryOpStub_MUL_Alloc_**HeapNumbers in >>>> my profile? Does that mean the compiler is putting local number variables >>>> on the heap? Why would it do that? >>>> >>>> -J >>>> >>>> -- >>>> v8-users mailing list >>>> [email protected] >>>> http://groups.google.com/**group/v8-users<http://groups.google.com/group/v8-users> >>> >>> >>> -- >> v8-users mailing list >> [email protected] >> http://groups.google.com/group/v8-users >> > > -- > v8-users mailing list > [email protected] > http://groups.google.com/group/v8-users -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
