N. Altman and N. Weiderman. Timing variation in dual-loop benchmarks. Technical report, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, October 1987.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....to the different environments of the two approaches, 4] uses measurements of the required clock cycles without considering the decoder s source code in any way. Because the solutions in this paper concentrate on high level examinations, they cannot be directly compared. Trying to measure WCETs [7, 3], is known to be too unsafe and inaccurate. Hence, the goal is to have an analytical method, like this approach. Due to complexity reasons an exact analysis is usually intractable, so most approaches try to approximate the WCET. This has always to be done in a way that does not underestimate at ....

N. Altman and N. Weideman. Timing Variations in Dual Loop Benchmarks. CMU/SEI-87-TR-22, Software Engineering Institute, Carnegie Mellon University, 1987.

....Scheduling, and Allocation of Periodic Hard Real Time Tasks 2. 2 Related Work on Timing Analysis Early work in the field of determining the worst case execution time mainly focussed on measuring the run time of programs on the target machine, like [41] or like the dual loop benchmark paradigm [9]. Within this method the program to be analysed is embedded into a loop, which is executed for a number of times. This way it is possible to measure a maximum average runtime of the program. The disadvantages of this approach are obvious: the results are input dependent and the system overhead ....

.... [4,4] 8 Processor 2: id T d C o s o T I T I r T r B 14 10 2 [2,2] 2,2] 2 [0,0] 0 [4,4] 4 C 14 12 2 [4,4] 4,4] 2 [0,0] 0 [6,6] 6 E 20 14 3 [0,0] 0,0] 0 [0,0] 4 [3,3] 7 G 20 16 2 [3,3] 3,3] 0 [0,0] 8 [5,5] 13 H 20 18 2 [5,5] 5,5] 0 [0,0] 8 [7,7] 15 I 20 20 2 [7,7] 7,7] 0 [0,0] 8 [9,9] 17 K 20 20 2 [4,8] 9,9] 0 [5,1] 8 [11,11] 19 Processor 3: id T d C o s o T I T I r T r A 14 8 2 [0,0] 0,0] 0 [0,0] 0 [2,2] 2 Table 4.1: Input and output data of the example task set of Fig. 4.4 The tasks are listed in priority order for each processor. It is assumed that the initial ....

[Article contains additional citation context not shown here]

N. Altman and N. Weideman. Timing Variations in Dual Loop Benchmarks. CMU/SEI-87-TR-22, Software Engineering Institute, Carnegie Mellon University, 1987.

....techniques that reduce the cost of performing an indirect jump operation, often requiring the execution of only two instructions on a SPARC. The task of filling delay slots for indirect jumps is also dealt with in this chapter. Chapter 7 shows execution time results from performing dual loop tests [10, 2] on SPARCstations to estimate the impact on pipeline stalls when the branch coalescing transformation was applied as another code improving transformation. Furthermore, the benefits of target buffer support for indirect jumps are discussed in this chapter. Various performance measurements are ....

....vary, but indirect jump instructions (as well as conditional branches) can also result in pipeline stalls on many machines. 7. 1 Dual Loop Test To realistically estimate the pipeline impact on RISC architectures from replacing several conditional branches into an indirect jump, a dual loop test [10, 2] has been conducted on a SPARCstation IPC, SPARCstation 5, SPARCstation 20, and UltraSPARC 1. ffl First, an optimized executable 1 for the C code in Figure 7.1 has been generated to estimate the execution time involved with loop overhead. Let E loop denote such an executable. 1 Appendix A ....

N. Altman and N. Weiderman. Timing variation in dual-loop benchmarks. Technical report, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, October 1987.

....the cost of performing an indirect jump operation, often requiring the execution of only two instructions on a SPARC. The task of filling delay slots for indirect jumps is also dealt with in this section. Section 6 shows execution time results from performing dual loop tests [Clapp et al. 1986; Altman and Weiderman 1987] on SPARCstations to estimate the impact on pipeline stalls when the branch coalescing transformation was applied as another code improving transformation. Furthermore, the benefits of target buffer support for indirect jumps are discussed in this section. Various performance measurements are ....

....jump instructions (as well as conditional branches) can also result in pipeline stalls on many machines. 6. 1 Dual Loop Test To realistically estimate the pipeline impact on RISC architectures from replacing several conditional branches into an indirect jump, a dual loop test [Clapp et al. 1986; Altman and Weiderman 1987] has been conducted on a SPARCstation IPC, SPARCstation 5, SPARCstation 20, and UltraSPARCstation 1. First, an optimized executable with a linear sequence of branches and with an indirect jump from a table, were generated for the C code shown in Figure 23. Let E linear and E indirect denote ....

Altman, N. and Weiderman, N. 1987. Timing variation in dual-loop benchmarks. Technical report (Oct.), Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA.

....previously decoded frames. Although rather successful for certain types of streams, the document also shows limitations of this method. In particular, it is possible to have underestimations. However, our approach seems to be the first using WCET analysis for MPEG decoding. Trying to measure WECTs [5, 2], is known to be too unsafe and inaccurate. Hence, the goal is to have an analytical method, like our approach. Due to complexity reasons an exact analysis is usually intracable, so most approaches try to approximate the WCET. This has always to be done in a way that does not underestimate at all, ....

N. Altman and N. Weideman. Timing Variations in Dual Loop Benchmarks. CMU/SEI-87-TR-22, Software Engineering Institute, Carnegie Mellon University, 1987.

....readily measure. The tested program is run several times inside a loop. But this loop adds time and this time must be factored out, that is why there is this second loop with no test program. However, the accuracy of a dual loop benchmark depends upon a highly specific set of circumstances (see [1]) and cannot be controlled by a general technique when the benchmark is written. 6.3. Measurements To find out the coefficients of regression for the execution time estimation of a program, it is necessary to measure the execution time of this program and of the narrow programs. These measurements ....

....be accomplished with an important care. Some assumptions about an eventually wrong way of proceeding have been disputed through experiments. The following paragraphs deal with this problem of accuracy of measurement. Constancy We started the measurements according to the hypothesis of Altman [1] who made experiments about the constancy of the time measurements of a test benchmark. His conclusions are the following ones. Since each of the tested systems have a consistent pattern of variation, the order of execution of the individual loops has no effect on the times. The compiler places ....

Altman N., Weiderman N., Timing Variation in Dual Loop Benchmarks, Tech. Rep. CMU/SEI-87-TR-21, Carnegie Mellon University

....benchmarks would actually take longer to run than the test loop, and the execution time of the language feature being measured (expressed as the difference of the test and control times) would sometimes be negative. A more detailed discussion of the so called dual loop problem can be found in [1]. A complete report on the problems encountered during the AEST benchmarking effort, and a discussion of other possible benchmarking pitfalls, is contained in [2] Another interesting issue is the accuracy of times reported by the PIWG benchmarks. One of the PIWG benchmark support packages, ....

Altman, N. A., and Weiderman, N. H. Timing Variation in Dual Loop Benchmarks. Technical Report SEI-87-TR-21, Software Engineering Institute, September, 1987.

....4 some experimental results are presented. Finally, Section 5 gives some conclusions. 2. Related Work Early work in the field of determinating the worst case execution time focussed mainly on measuring the program runtimes on the target machine, like [9] or like the dual loop benchmark paradigm [4]. Within this method the program to be analysed is embedded into a loop, which is executed for a number of times. This way it is possible to measure a maximum average runtime of the program. The disadvantages of this approach are obvious: the results are input dependent and the system overhead ....

N. Altman and N. Weideman. Timing Variations in Dual Loop Benchmarks. CMU/SEI-87-TR-22, Software Enginieering Institute, Carnegie Mellon University, 1987.

....the time measurement. In addition, software monitors can only provide rough timing measurements, depending upon the precision of the system clock [13] 2. 4 Dual Loop Benchmark The dual loop benchmark paradigm is a commonly used method of measuring code execution time using a standard system clock [1]. The resolution of the system clock may vary from one implementation to another. However, the dual loop benchmark approach deals with imprecise clocks by extending the duration of the test to a length that the clock can measure. This is accomplished by inserting the test code in a loop that is ....

....T4 : CLOCK; for I in 1. LOOPCOUNT loop CONTROL LOOP null; end loop; T3 : CLOCK; AVGEXECUTIONTIME : T1 T2) T3 T4) LOOPCOUNT) end DLEXAMPLE; Figure 1: Dual loop timing example loop constructs of the control loop and the benchmark loop may not be same. Altman and Weiderman in [1] showed that identical loops exhibited substantial variations in execution time (as much as 12 percent) on specific test systems. For example, if the control loop fits into cache but the benchmark loop does not, then the control loop will execute faster than the benchmark loop. This variation in ....

Altman, N. and Weiderman, N. 1987. Timing Variation in Dual Loop Benchmarks. Technical Report CMU/SEI-87-TR-22, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA 15213.

....optimising compilers to the LLA is presented in [9] 3. Related Work Principally, there are two ways to determine the WCET of a program: dynamically, i.e. by measuring the runtime with some sample input data; and statically, i.e. by analysing the program structure. Since the measuring approach [4] is unsafe (one cannot be sure that the considered input data in fact produces the worst case) most recent research concentrates on the static approach. Most publications focus on only one or a few of the aspects: LEPS, instruction caching, data caching or pipelining. M ller [28] developed a ....

N. Altman, N. Weideman. "Timing Variations in Dual Loop Benchmarks". Technical Report CMU/SEI87 -TR-22, Software Engineering Institute, Carnegie Mellon University, 1987.

No context found.

N. Altman and N. Weiderman. Timing variation in dual-loop benchmarks. Technical report, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, October 1987.

No context found.

N. Altman and N. Weideman. Timing Variations in Dual Loop Benchmarks. CMU/SEI-87-TR-22, Software Engineering Institute, Carnegie Mellon University, 1987.

No context found.

N. Altman and N. Weiderman, "Timing Variation in Dual Loop Benchmarks", Technical Report CMU/SEI87 -TR-22, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA 15213, October,1987.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC