VM: const array indexing modulo

[jtmcdole]

My code for number of trailing zeros should be pretty fast: https://gist.github.com/jtmcdole/297434f327077dbfe5fb19da3b4ef5be

But a const array of size modulo still has a range check when indexed by said modulo. Also, modulo is apparently slow on all arm64 and arm32 dartvm snapshots?

https://github.com/dart-lang/sdk/blob/master/runtime/vm/cpu_arm.cc#L227

[a-siva]

/cc @aartbik

[aartbik]

Let's start with the bounds check. For the constant arrays, we see the array lengths as constants, so it is indeed a low hanging fruit to eliminate the check altogether given the modulo operator. Coming up!

[aartbik]

I completed a CL that improves range analysis for modulo operators. This implies the bounds check is now eliminated. Performance of a micro-benchmark (on an Intel Xeon 2.60GHz desktop for the time being) before this improvement:

JIT
DartNTZ.NTZ32(RunTime): 439.99929036515624 us.
DartNTZ.NTZ64(RunTime): 373.55112268907567 us.

AOT
DartNTZ.NTZ32(RunTime): 562.560742407199 us.
DartNTZ.NTZ64(RunTime): 560.3938464555898 us.

And after the range analysis improvements:

JIT
DartNTZ.NTZ32(RunTime): 377.65250944108766 us.
DartNTZ.NTZ64(RunTime): 357.13150723085164 us.

AOT
DartNTZ.NTZ32(RunTime): 518.6002999740732 us.
DartNTZ.NTZ64(RunTime): 536.2601919571046 us.

[aartbik]

The performance of modulo (or division for that matter) on arm is clearly a much "higher" hanging fruit. There is probably not much we can do about the assumptions what processor on what device supports integer division across all potential target architectures. However, perhaps we can do slightly better for the constant x % c operator for various c (currently, and to a certain extent, we do that for powers of two only). Investigating.....

[ds84182]

I imagine you could emit a call directly to the ARM builtins (__aeabi_idiv and friends). It would probably be faster than transitioning in and out of the VM.

[aartbik]

Note, to clarify, the cpu_arm code linked to above determines what to generate when compiling arm32, but running on arm32 or arm64. When compiling for arm64, cpu_arm64 is used, and you should unconditionally see a division, e.g. for ntz64:

0x7f81247788f0 d2801062 movz r2, 0x83 // 131
0x7f81247788f4 9ac20c85 sdiv r5, r4, r2

[aartbik]

Intel results on our performance cluster are in (from bounds check elimination only):

  | Benchmark     |Improvement|Mode      |Processor      |OS          |Noise Level
  | DartNTZ.NTZ32 | +3.88 %   | dart     | Intel Core i5 | linux-ia32 | 1.09 x noise
  | DartNTZ.NTZ32 | +5.57 %​   | dart     | Intel Core i5 | linux-x64  | 1.07 x noise
  | DartNTZ.NTZ32 | +13.7 %​   | dart-aot | Intel Core i5 | linux-x64  | 3.01 x noise
  | DartNTZ.NTZ32 | +12.5 %​   | dart-aot | Intel Xeon    | linux-x64  | 1.99 x noise
  | DartNTZ.NTZ64 | +5.29 %   | dart     | Intel Core i5 | linux-x64  | 2.42 x noise
  | DartNTZ.NTZ64 | +10.5 %​   | dart-aot | Intel Core i5 | linux-x64  | 3.16 x noise
  | DartNTZ.NTZ64 | +12.8 %​   | dart-aot | Intel Xeon    | linux-x64  | 1.41 x noise

[jtmcdole]

How do I read those results? Does that mean they are faster?

[aartbik]

@jtmcdole I added a header. The second column shows improvement, the noise level indicates how reliable the improvement is compared to noise that the benchmarks has between runs (> 1 is confident, and higher is more confident).