20 is going to be a little late, probably next week, because of a late-breaking JavaScript performance regression I finally tracked down which was due to bug 792108. This bug, in return for eliminating a odd execution path for document.all, stuck a stub call right in the middle of a methodjit fast path which caused V8 performance to drop nearly 15% and SunSpider to be 160% slower. I can understand the reasoning from the code cleanup perspective, but eliminating a major methodjit fast path to maintain what is essentially an Internet Explorer 4 holdover shim really sucks (and has no relevance in modern browsing since it only turns up in quirks mode).
Now, this is sort of my fault, because this "fix" (I use the term advisedly) was even back in the betas, but I was slack in the non-Dobbs way and only ensuring that the tests succeeded, not what the actual numbers were. However, you can see from AreWeFastYet that in early-mid December (ignore the actual numbers, just look at the trends) the red JM+TI line suddenly worsened (that's us) in SunSpider and V8, and most of the V8 regression seems to have been due to V8-Richards, which took a nose dive around the same time. This isn't of interest to Mozilla, because they built a fast path into IonMonkey (instead of the quick'n'dirty stub for JaegerMonkey) and the combined purple JM+TI+Ion line marches downwards apace since V8 mostly runs in Ion now, and for ports stuck on the interpreter the speed is probably not any more perceptibly glacial than it was before. It's only us weird arch ports like MIPS and SPARC that have only methodjit, and we're the only ones to get screwed. A heads up would have been nice instead of an opaque message about a minor change to the JSAPI in the technical newsgroup.
If this sounds familiar, that's because similar things happened in the twilight days before the end of TraceMonkey in Firefox 10, our original JIT. So I'm enlisting your help to look for major spikes like this in the future in case I miss them (or the day when the JM+TI line disappears completely). We should expect some minor performance erosion that's probably not worth the headache to fix, but a major hit like this is just not acceptable when our marquee feature is our JavaScript performance. The goal is to make it to Firefox 24 at any cost, even if we have to drag some old JS code with us.
As far as IonMonkey, I've actually made a bit of progress with it. By basing ourselves on the x86 backend -- which incredibly is cleaner than the perverse little ARM one -- I was able to use hints in their code to hopefully preserve all the hard work Ben did on our assembler, particularly his tinkering with G3/G4 and G5 branching for performance on specific processors. I need to do some work on the existing PowerPC assembler to add some new opcodes and Ion jump handling methods, but this is value-added work that shouldn't affect methodjit and will be silently part of 21. The Ion macro assembler, however, is not much like the methodjit macro assembler and will need to be written from scratch using the template in the x86 version. I'm still rather bearish on Ion because it does a lot of mucking around with stack frames, something PowerPC is not very good at, and it's questionable how much advantage it will take of our register set even though theoretically we can pump all 32 at it (but then we have to save those extra non-volatiles in every function prologue plus any non-volatile floating point registers, and that sucks, so we're not going to do that). I think I have all the pieces in js/src/ion/ppcosx; they just don't work or build, and much of the code isn't written (particularly the higher level abstract stuff which I don't even understand yet). The first order of business is just to get it to compile. Volunteers, as always, solicited. These pieces will be part of the 20 changesets when they become available, but if you want an early peek, just ask.
17.0.5 will fix websites using databases affected by issue 213 and should be out sometime this weekend or late Sunday, so watch for it then. 20 (also with that fix) will probably not be out until next weekend because I'm on a work trip in Sacramento, that wretched hive of scum and villainy known as the state capital, but we'll see if I can get some downtime between meetings. However, I want to do some basic compatibility testing on it prior to release to make sure our reverting the "fix" didn't cause some other unpleasant regression somewhere else, so I'll need to be at my desk first.
POSTSCRIPT. Looks like v8-crypto also took a spill, sometime between 17 and 19. This is only good for 5% on V8, and we already shipped this regression (so I'm not going to hold 20 for it if I can't figure it out right away), but if we fix it 20 should be able to clean the JavaScript performance floor with 17 and 19 which are already quite swift.
No comments:
Post a Comment
Due to an increased frequency of spam, comments are now subject to moderation.