Difference between revisions of "MindTheSemanticGap"

From JVMLangSummit
Jump to navigationJump to search
(Our systems exhibit better performance but a worse performance model due to the large semantic gap between the source program and its execution in silicon.)
(No difference)

Revision as of 13:55, 17 September 2009

On Wednesday afternoon (9/16), we held an impromptu workshop (rant?) about the increasing semantic gap between programs and their execution, and the consequent degradation in the performance model. The performance model should not to be confused with the performance. While the absolute performance has increased, it has become much more difficult to predict the performance of our programs due to the increasing complexity of processors, VMs, and languages. It may seem counterintuitive, but the quality of the performance and the performance model are inversely related. To increase performance, we complicate our system, resulting in a worse performance model.

No one knew of a solution to the problem, but Brian Goetz opined that it was only a problem for the most sophisticated programmers. That said, we put together a little list of performance gotcahs: constructs whose performance was far worse than it appears. Here is the list in its raw form. Hopefully we can illustrate these things with actual code:

(1) Manual outlining to allow for subsequent inlining.

(2) && and || are branches. Unpredictable branches are very expensive (~100 instructions).

(3) Watch out for field accesses, especially volatile fields. They aren't free, and some are expensive. Some field accesses cause method invocations (e.g., accessing private fields in enclosing classes from nested classes).

(4) Polymorphic method invocations are much more expensive than monomorphic.

(5) Division is expensive (except for some division by constants in some VMs). Both / and % are division operators (i.e., both are expensive). Some VMs, included the HotSpot server compiler, know how to optimize division by certain constants.

(6) Bounds checking elimination in loops is a big win. To enable it, ensure that iteration is by a constant, and when iterating over arrays, that no aliasing can occur.

In the presence of the huge semantic gap, performance measurement becomes even more important than it was. It was noted several profiling tools; they will give you different answers. Some systematic biases due to the fact that they run at "safepoints."