501509 - TM: Understand perf effects of Number representation choices

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[David Mandelin [:dmandelin]]

Mike Pall recommends using floating-point numbers for everything. See bug 495569 comment 28 for the argument, but the basic idea is that only integer loop variables and array indexes should be represented by machine ints, while numbers in other arithmetic codes should always be machine doubles, because (integer arithmetic + guards) ends up being more expensive than simply double arithmetic.

We should check this out in the context of TM. Suggested outline of steps:

1. Create a JS microbenchmark or two that does some non-integer-loop, non-array-indexing arithmetic. The benchmark can either avoid the integer-favoring ops entirely, or segregate them from the general arithmetic we want to analyze.

2. Extract key LIR fragments from the microbenchmark for individual analysis using lirasm.

3. Run the benchmark LIR fragments under various demotion settings: no demotion, demote only certain variables, aggressive demotion, etc. Measure the run time of each setting, and also look at the generated asm to make sure it looks reasonable.

4. Hand-optimize the asm for the all-integer and all-floating-point versions. Measure run time to compare with results from step 3 and provide a limit study of each technique.

5. Use the above to figure out what perf losses we are incurring, if any, by our current narrowing strategy and how to fix.

Comment 1

[Nicholas Nethercote [inactive]]

Julian commented later in bug 495569 about how ARM processors have weak FP support.  Not that I want to stop this analysis from occurring;  it might even be possible to generate different LIR for ARM if it helped.

Comment 2

[Ryan VanderMeulen [:RyanVM]]

Obsolete with the removal of tracejit.