313
edits
Changes
→Major Optimizations
|-
| Regexps<br>
| align="right" colspan="2" | 025<br> | align="right" | 1000300<br>
| align="center" | 6
| cdleary<br>
*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.
*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>
*Regexps. I believe The estimates should be very accurate--they are based on measurements by cdleary of how much time we don't compile all the spend running uncompiled regexps in v8(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.
*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.
