Proposal for a small language change

Joseph D. Darcy Joe.Darcy at Sun.COM
Mon Apr 13 14:28:49 PDT 2009


The Project Coin call for proposals phase is over; no new proposals are 
being accepted.

Microbenching is a tricky area, but not one requiring language support!

-Joe

PS Somewhat related might be JSR 284: Resource Consumption Management API
http://www.jcp.org/en/jsr/detail?id=284

Angelo Borsotti wrote:
> Author: Angelo Borsotti, former Senior Director Software Technology,
> Alcatel-Lucent Optics
>
> Overview
>   Feature Summary: fast and accurate measurement of execution time
>   Major Advantage: optimization of algorithms by measuring execution
>       times of small snippets of code executed many times
>   Major Benefit: greatly increases observability of programs
>   Major Disadvantage: very little cost
>   Alternatives: there are no alternatives
>
> Examples:
>
>   Simple example:
>        long c0 = System.cycles();
>        i++;
>        long c = System.cycles() - c0;
>   Advanced example:
>        long cycles = 0;
>        for (int i = 0; i < bound; i++){
>           ...
>           long c0 = System.cycles();
>           some statements
>           cycles += System.cycles()- c0;
>        }
>
> Details
>   Specification
>      Add a new method System.cycles().
>   Compilation
>      The method must be compiled inline, translating it into a single
> instruction,
>      present in most architectures, that reads the cycle counter
> register (e.g. the
>      TSC in x86 architectures).
>      To measure execution time, System.nanoTime() is currently
> provided. This, however,
>      is by far too inaccurate to measure the execution time of code
> which lies inside
>      methods, possibly inside loops. The accuracy that it provides is
> comparable to the
>      time needed to execute thousands of java statements, which is too low.
>      Moreover, the time spent to execute the nanoTime() method itself
> makes this tool
>      too much invasive. Execution times become often much higher when
> nanoTime() is
>      added, to the point to provide useless results.
>      Note that when a piece of code lies inside loops, measuring its execution
>      time means adding many small durations. This means that the invasivity
>      and the accuracy of the tool to measure time is extremely important.
>      Note that also a native method would be too much invasive. The
> only way to provide
>      a means to measure execution times that introduces an acceptable
> noise (i.e. an
>      error that is sufficiently lower than the times measured) is to
> compile the call
>      inline into a machine instruction. Profilers are orders of
> magnitude coarser than
>      what is needed.
>   Testing
>      A simple test case in which a very simple example (as the one
> above) is used,
>      that computes the number of cycles needed to perform a simple
> operation. The
>      result should then be compared agains an estimate.
>   Library suppor
>      None needed
>   Reflective APIs
>      No change
>   Other changes
>      None
>   Migration
>      None
>
> Compatibility
>   Completely downward compatible
>
> References
>   Bug ID: 6685613
>
>   




More information about the coin-dev mailing list