Proposal for a small language change
Ulf Zibis
Ulf.Zibis at gmx.de
Mon Apr 13 14:43:08 PDT 2009
+1
-Ulf
Am 13.04.2009 23:21, Angelo Borsotti schrieb:
> 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