JaegerMonkey: Difference between revisions

Jump to navigation Jump to search

JaegerMonkey (view source)

Revision as of 00:15, 5 May 2010

3,016 bytes removed ,  5 May 2010
→‎Major Optimizations
Line 18: Line 18:
== Major Optimizations<br>  ==
== Major Optimizations<br>  ==


Here is a chart of the major optimizations that we think we need to do in order to make JM&nbsp;fast, defined as cutting 950ms from our current JM-only SunSpider score and 13500ms from our v8-v4 score. For each optimization, the table shows a guess as to how many ms it will cut off our JM-only SunSpider and v8-v4 scores, the size of the task in person-weeks, and a possible assignee. All numbers are just guesses except as noted in the comments. Keep in mind that benefits are not really additive, but for the purpose of this table, interaction benefits or penalties are shared out among the individual items.
[Updated 4 May 2010]


Note that most of these items can be worked on independently. The main exception is that compiler fast paths need to be done after we have decided what a jsval is. Thus, those two items form the critical path. Note that those items together are 1/3-1/2 of the win we need, so we cannot be fast without them.  
First, how far do we have to go? The rough numbers on our reference machine are (arewefastyet.com):


It's not known that we will be fast after completing and tuning these items--there may be other issues, e.g., with object allocation and GC, that are not covered here.
{| width="50%" cellspacing="1" cellpadding="1" border="0"
|-
|
| align="right" | '''SunSpider (ms)'''
| align="right" | '''v8-v4 (ms)'''
|-
| Current score
| align="right" | 1150
| align="right" | 9100
|-
| Target score
| align="right" | 400
| align="right" | 2300
|-
| Needed improvement
| align="right" | 750
| align="right" | 6800
|}


<br>
Now, how do we get there?


{| width="80%" cellspacing="1" cellpadding="1" border="0"
{| width="95%" cellspacing="1" cellpadding="1" border="0"
|-
|-
! scope="col" | Name<br>
| '''Optimization'''
! colspan="2" scope="col" | Est. SS Benefit (ms)<br>
| align="right" | '''SunSpider improvement (ms)'''
! scope="col" | Est. V8 Benefit<br>
| align="right" | '''v8-v4 improvement (ms)'''
! scope="col" | Size (wks)<br>
| align="right" | '''Size (wks)'''
! scope="col" | Candidate Assignee<br>
| '''Candidate Assignee'''
|-
|-
| PIC<br>
| Globals
| align="right" colspan="2" | 100<br>
| align="right" | 100
| align="right" | 3500<br>
| align="right" | 1000
| align="center" | 1
| align="right" | 2
| dmandelin<br>
| dvander
|-
|-
| Compiler value handling<br>
| Regexes
| align="right" colspan="2" | 100<br>
| align="right" | 25
| align="right" | 1000<br>
| align="right" | 300
| align="center" | 1<br>
| align="right" | 2-8
| dvander<br>
| cdleary,intern
|-
|-
| Globals<br>
| Strings
| align="right" colspan="2" | 100<br>
| align="right" | ???
| align="right" | 500<br>
| align="right" | ???
| align="center" | 4<br>
| align="right" |  
| dvander<br>
|  
|-
|-
| Scope chain<br>
| Dates
| align="right" colspan="2" | 0<br>
| align="right" | ???
| align="right" | 500<br>
| align="right" | ???
| align="center" | 4<br>
| align="right" |  
| intern<br>
|  
|-
|-
| Regexps<br>
| Math
| align="right" colspan="2" | 25<br>
| align="right" | ???
| align="right" | 300<br>
| align="right" | ???
| align="center" | 6
| align="right" |  
| cdleary<br>
|  
|-
|-
| New jsvals<br>
| jsvals
| align="right" colspan="2" | 300<br>
| align="right" | *300
| align="right" | 3500<br>
| align="right" | *2500
| align="center" | 8<br>
| align="right" | 8
| lw (+others)<br>
| lw+others
|-
|-
| Compiler fast paths<br>
| Compiler fast paths
| align="right" colspan="2" | 350<br>
| align="right" | *325
| align="right" | 3500<br>
| align="right" | *3000
| align="center" | 4<br>
| align="right" | 8
| all<br>
| dvander+others
|}
|}


<br>
* means the improvement value is just a guess. Values without stars are based on some kind of measurement.


Item descriptions and commentary:  
Description and comments for each item:


*PIC. Polymorphic inline caching for property accesses. This is basically done--all that remains are to sort out some minor correctness issues and get it running on ARM. Performance is pretty much done, so the estimated perf benefits are real measured perf benefits in this case.  
*[https://bugzilla.mozilla.org/show_bug.cgi?id=561218 Globals]. This means optimizing global variable access with fast paths. dvander has already started this and has wins of 50/500 ms (SS/v8) so far.  
*Compiler value handling. Currently, each jsop is compiled to work exactly the way it does in the interpreter: load values from the stack or local slots; do stuff; then store values back to the stack. We are improving the compiler so that it can hold values in machine registers across jsops. It will also avoid moves and stores entirely when possible. "Register allocation" would be a reasonable name for this optimization, but doesn't capture all of it. We found a 10-20% perf improvement in early tests, which is reflected in the table estimates. This is partially done--the 1 week size is to finish.
*Regexes. There are some regexes we don't compile in SunSpider and v8. There is only one in SunSpider and it would not be hard to extend our current compiler to handle that case. v8 has more, and we don't know which ones count yet and what features are needed.<br>The regex project could be completed either by improving our regex compiler, or just taking yarr from JSC. The latter should be preferred if possible. The licensing on yarr is OK, but it uses vector and unicode classes that are GPL&nbsp;and would need to be replaced.
*Globals. Globals work as they do in the interpreter right now. It should be possible to get them down in most cases to 1-2 loads per global, plus a shape guard if the global was undeclared. Some initial thoughts on how to do this were posted in the js newsgroup.
*Strings, Dates, Math. These are key runtime functions. They may be very fast already, or we might have some functions that are slower than they could be. We are doing measurements now.
*Scope chain. AKA "closure variable access". This is similar to globals. We don't know how much of this is present in the benchmarks, but it's clearly important for general web perf. It seems to require a major overhaul of the scope chain.<br>
*[https://bugzilla.mozilla.org/show_bug.cgi?id=549143 jsvals]. This is the 128-bit jsvals. This may not turn out to be a huge speedup all on its own, but together with the compiler fast paths it will be very important.
*Regexps. The estimates should be very accurate--they are based on measurements by cdleary of how much time we spend running uncompiled regexps (30 ms and 350 ms, with an assumed 6x speedup from compilation). This item means getting a new regexp compiler, or upgrading our current one, so we can compile them all.  
*Compiler fast paths. This means making the JIT inline all commonly run ops. There are probably about 50 of them. This is partially blocked on the new jsvals, because the code generation depends somewhat on the jsval format. But we could start these before finishing the jsvals are done, and patch things up as needed.
*New jsvals. We are going to a new jsval format. Currently, we are working on a 128-bit format, with a 64-bit value payload (that can hold any int, double, or pointer without masking or compression on any 32- or 64-bit platform) and 64 bits for alignment and type tags. <br>We know that we need a new format to be fast, but there is some risk about exactly what format. The pluses for the 128-bit idea are that it performed well in a pilot study and that extracting the unboxed value is simply taking the right bits, with no masking, shifting, or arithmetic. A minor risk is that it will increase memory usage too much, but measurements there suggest we will be OK. A bigger risk is that it will require more register pressure, or more memory traffic when copying values, decreasing performance. There is no way to know which format is best without implementing it and testing it for real. <br>The specific benefits of a new format are (a) doubles don't have to be on the heap, making allocation much faster and reducing indirection, (b) integers can be 32 bits, allowing a larger range to be stored in an integer format and making boxing much cheaper following bit operations, and (c) potentially reducing the number of operations it takes to box and unbox, depending on the format. Benefits (a) and (b) can be achieved with any reasonable alternate boxing format (32-bit NaN-boxing, 64-bit NaN-boxing, or "fat" values like our 128-bit values). Benefit (c) is maximized if the boxing format contains the unboxed value unmodified--only fat value formats like our current 128-bit values achieve that.  
*Compiler fast paths. It's clear from our past experience and measurements that staying on fast paths and avoiding stub calls is key to method JIT performance. Good fast paths for the most common 50 or so ops should cover 99% of ops run. It doesn't make sense to start this before the new jsvals are done. The good thing about this one is that it parallelizes very well.


== Ongoing Work  ==
== Ongoing Work  ==
Dmandelin
313

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/220711"

Navigation menu