Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: X10 1.7.2 - C++ hosted, X10 1.7.3
-
Fix Version/s: X10 2.0.5
-
Component/s: XRX Runtime
-
Labels:None
Description
Opening this issue for ongoing general status and discussion of issues relating to sequential performance of array-related code (point, region, dist, array).
Some preliminary measurements:
. cpp-opt x10-cpp-opt SeqRail2 a: 256 Mop/s b: 146 Mop/s SeqPseudoArray2a c: 256 Mop/s d: 71.5 Mop/s SeqPseudoArray2b e: 2.15 Mop/s SeqArray2 f: 323 kop/s
Over and above the general performance issues in C++ generated code (a/b/d/e), there is an additional 6x performance difference between "best possible" generic array and actual library array (e/f).
A known issue is that array bounds checks cannot currently be disabled. Will measure performance impact of that by commenting out bounds checks locally.
The array design depends heavily on inlining; will investigate whether that may be inhibited by the same issues that cause the general C++ performance issues (a/b/d/e).
Issue Links
- is depended upon by
-
XTENLANG-962
Array library redesign
-
After commenting out array bounds checking the performance of the actual x10.lang.Array code (f in the table above) becomes 2.13 Mop/s, essentially the same as SeqPseudoArray2b, which is the "best possible" generic array code (e in the table above).
In other words, it doesn't appear at the moment that there's anything that can be done in the array library beyond disabling bounds checking to improve performance. Will investigate a mechanism for disabling bounds checking.
Also I'm a little surprised that bounds checking has such an effect, because it should be reasonably optimal. Will investigate.