Power-Performance Trade-offs for Energy-Efficient Architectures: A Quantitative Study

Transcription

1 In the Proc. of the Intl. Conf. on Computer Design (ICCD-02), Frieburg, March 2002 Power-Performance Trae-offs for Energy-Efficient Architectures: A Quantitative Stuy Hongbo Yang R. Govinarajan Guang R. Gao Kevin B. Theobal Electrical an Computer Engineering Supercomputer Eucation & Research Centre University of Delaware Dept. of Computer Science & Automation Newark, DE Inian Institute of Science Delaware, U.S.A. Bangalore, , INDIA govin@csa.iisc.ernet.in Abstract The rastic increase in power consumption by moern processors emphasizes the nee for power-performance trae-offs in architecture esign space exploration an compiler optimizations. This paper reports a quantitative stuy on the power-performance trae-offs in software pipeline scheules for an Itanium-like EPIC architecture with ual-spee pipelines, in which functional units are partitione into fast ones an slow ones. We have evelope an integer linear programming formulation to capture the power-performance traeoffs for software pipeline loops. The propose integer linear programming formulation an its solution metho have been implemente an teste on a set of SPEC2000 benchmarks. The results are compare with an Itanium-like architecture(baseline) in which there are four functional units (FUs) an all of them are fast units. Our quantitative stuy reveals that by introucing a few slow FUs in place of fast FUs in the baseline architecture, the total energy consume by FUs can be consierably reuce. When 2 out of 4 FUs are set as slow, the total energy consume by FUs is reuce by up to 31.1% (with an average reuction of 25.2%) compare with the baseline configuration, while the performance egraation cause by using slow FUs is small. If performance eman is less critical, then energy reuction of up to 40.3% compare with the baseline configuration can be achieve. 1. Introuction The past ecae has seen a tremenous increase in the performance of general purpose microprocessors. However, This work is supporte by DARPA through contract number AFRL F this higher performance is often accompanie by an unesirable, sometime excessive, power consumption. This is preicte soon to become a limiting factor in highperformance processor esign [2]. Consequently, architects must consier power-performance traeoffs when exploring the processor esign space. This paper eals with low power architectures, compiler techniques, an their interplay. Recent research in low power esign proposes architectures with components operating at ifferent pipeline spees [12]. In such processors, some functional units (FUs) operate at full CPU spee ( fast FUs) while others run at a slower spee ( slow FUs), typically half of the full spee. Slow FUs can run at lower voltages, which lea to a better-than-linear energy reuction per operation. The rationale behin such a esign is that scheule slack is present for some instructions, i.e., they are not on the critical path, so prolonging their execution time shoul not hurt performance. A limit stuy [3] emonstrates that more than 75% of execution cycles have at least one instruction that has slack. By issuing instructions on the critical path to fast pipelines an those which are off the critical path to slower functional units, significant power an energy reuction can be achieve [10, 21]. This paper reports a quantitative stuy of powerperformance traeoffs in the esign space by exploring the interplay between low-power architecture features an compiler optimizations. Our stuy concentrates on software pipelining [11, 15], a compile-time instruction scheuling technique for loops. In our prior work, performanceoriente software pipelining uner given timing an resource constraints has been formulate as an integer linear programming problem [1, 5, 6] an was successfully use in evaluating the software pipelining algorithm implemente in a prouction-quality compiler [17]. However in the context of low power, effective software pipelining algorithm

2 s2 s4 + + s0 s1 s3 + + * Figure 1. Motivating Example which strives for both optimal performance an minimal energy is still unexplore. The problem that we are aressing in this paper is: Given a loop an a machine configuration with slow an fast FUs, fin a rate-optimal software pipeline scheule which consumes minimal energy. We use the term rate-optimal scheule to imply that no other scheule for the loop can have a lower initiation interval(ii) [15, 11, 14] for the machine configuration. The term minimal energy scheule means that no other scheule for the loop can have a lower energy consumption with given II for the given architecture. This paper formulates the above problem as an ILP problem an explores both the architecture an compiler sie of esign space using the ILP formulation an its solution metho. In particular, this stuy explores: [Architecture sie:] In orer to achieve significant power reuction without incurring performance egraation, how many of the FUs in an architecture can be slow FUs? By increasing the number of slow FUs, how oes the application performance egrae? [Compiler sie:] To what extent can the compiler exploit this knowlege of slow an fast FUs in the architecture? Further, in such architectures, to what extent can compilers trae-off performance for energy reuction? 1.1. Example We illustrate the benefits of slow FUs with a simple example. Figure 1 shows a ata epenence graph (DDG) for a loop boy, with a loop-carrie epenence (from one iteration of the loop to the next) from s5 to s4. Suppose we want to run this loop on an architecture a1 with 3 Integer A units an 2 Integer Multiply units. All FUs are fast an fully pipeline, an their latencies are 1 cycle for A an 3 for Mult. A rate-optimal scheule for this DDG with an II of 2 is shown in Figure 2. The repetitive kernel in cycles 4 an 5 is shae. We can see that there is some slack in the scheule, an not all FUs are fully utilize. If one A FU s5 + Iteration Time Steps s0 s1,s2 s3 s4 s5 1 s0 s1,s2 s3 s4 s5 2 s0 s1,s2 s3 s4 s5 Figure 2. A Scheule for Architecture a1 Iteration Time Steps s0,s2 s1 s3 s4 s5 1 s0,s2 s1 s3 s4 2 s0,s2 s1 s3 3 s0,s2 s1 s3 4 s0,s2 s1 Figure 3. A Scheule for Architecture a2 an one Mult FU in a1 were replace with slow FUs operating at half the frequency, we coul still achieve the same II with this moifie architecture a2, as shown in Figure 3. In this scheule, instructions s2 an s3 are scheule in the slow A an Mult FUs; these are shown in italics. Although the kernel appears later, i.e., the prologue is longer, the scheule is still optimal with. Architecture a2 may save power relative to a1, without slowing own the loop. On the other han, if two of the A units were slow (architecture a3), the scheule in Figure 3 woul not work. Each loop iteration woul require 5 aitions, but each of the two slow units can perform only one aition every 2 cycles, so that all three A units together can perform only 4 aitions every 2 cycles. The best II that we can achieve for this DDG woul be 3. This example shows that by varying the number of fast an slow FUs, the architecture can be mae more power efficient, but at some point this efficiency will lea to a performance penalty Synopsis Given an architecture with a fixe number of FUs in each resource class, it is interesting to fin out how many of these FUs in each class coul be operate at a slower clock rate, an hence at a reuce power consumption, an what is the egraation in performance, if any. In this paper, we propose an integer linear programming formulation for the above problem base on our earlier work. We apply our approach on SPEC2000 integer benchmarks to evaluate ifferent configurations (with ifferent number of slow an fast FUs) of Itanium processor from both the performance an power angles. Also we stuy the aitional power savings that can be obtaine when the compiler traes performance for energy. Our results show that by introucing two slow FUs in the architecture, in the place of fast FUs, an

3 b average energy savings of 25.2% can be obtaine while the performance egraation is within 6.2% on the average. The rest of the paper is organize as follows. The next section presents an elegant ILP formulation for poweraware software pipelining base on our previous work. In Section 3 we elaborate our experimental framework. Section 4 eals with the experimental results. A iscussion on relate work an concluing remarks are provie respectively in Sections 5 an Integer Linear Programming Formulation Let the number of noes in the DDG be an let be the initiation interval. In this paper we consier only repetitive scheules or moulo scheuling. The software pipelining methos attempts to fin a scheule for each value of initiation interval, starting from the minimum initiation interval (MII) [15, 11, 14]. The methos stops as soon as a scheule is foun for the first greater than or equal to MII. In moulo scheuling, the scheule time of operation in the th iteration is given by where is the scheule time of operation in the first iteration. We use an vector! ""#$&%'%&%"(*)#,+.- to represent the scheule time of the operations in the first iteration. We use an /* matrix 0 to represent the repetitive pattern of instructions in the moulo scheule. The matrix where if an only if noe is scheule at time step in the moulo scheule. It is easy to see that 7&8 9 ;:=< > 5? if mo We 6AB!,AC#D'%&%&%&,A!(E)F#,+ -, where G 9ÏH CJ? Further an 0 are relate by the following equation. K LNMOPRQSUTWV XY<:=<"MMM<ZN[U:]\^S (1) Since each instruction is scheule in the repetitive pattern exactly once, the following equation must be satisfie for a legal scheule: a`cb 8.e9f 7&8 9 ;: for all gch VXY<Zij[U:]\ (2) For resources that operate on a single spee, that is those which are not partitione to fast an slow ones, e.g., the issue unit, the resource constraint can be specifie using the following simple inequality..k$lamon"p 7&8 rqs n for all h VXY<t&N[U:]\ (3) where uwv is the number of resources of type x an y{z x} represent the set of instructions in the loop that use resource type x. Next we formulate the resource constraints for resources types which have slow an fast FUs. For an instructions which goes to these resource types x, we also nee to know whether the instruction is scheule on slow or fast FU. We use two sets of variables ~ 354 an 354 for this purpose: ~ 354 if instruction is scheule on fast FU an 2354 ; likewise D354 if instruction is scheule on slow FU an Since the resource assignment for instruction can be either fast FU or slow FU but not both, the following equation hols: 7&8 9 ƒ 8 w 8 for all h VXY<5 [:]\.< an for all g h VXY<Zi [:]\ (4) If there are u v4 $ˆ ]3 fast FUs an u v4 ]ŠŒ slow FUs in resource type x, then the resource constraint for software pipeline scheule can be enforce using the inequality ƒ 8 qs n] a = 8 for all k$l,mžnp h VXY<t [U:]\ an for all (5) 8 rqs n] 5 for all.kdl,mžnp h VXY<t [U:]\ an for all (6) Since the time steps in our scheule is base on the fast clock, slow FUs (operating at half the clock frequency) have a structural hazar, an can have instructions scheule on them only once every two cycles [19]. To reflect this, we a the conition that if z 354 Y an z Y, then z C 3 š# 54 shoul also be 1, where œ represents z Y ŸžLD. This can be expresse in the form of a linear constraint as: 8! 7'8 {[ m 8 p U? (7) Note that if both z 354 $ an z Y then C 3 šw# 54 shoul be 1 in orer to make the left han sie (strictly) less than 2. Next we will express the preceence constraint. For this, we efine a variable for each instruction to inicate whether instruction is scheule on fast FU (in which case D 1 ) or on slow FU (in which case B ª ). The variable D is efine as: c a`cb 8.e9f ƒ 8 for all g h VXY<]i[ :]\ (8) Now, for each epenence arc z a5 in the DDG, the preceence constraint between an is formulate as [16]: ^ P[ F R & P[ T* w where o± is the latency from instruction to an ž Ž± is the epenence istance [15, 11, 14]. In the ual-spee architecture, the latency Ž± will be o± 4 Yˆ& 53 an o± 4 5ŠŒ " for fast an slow FUs. The preceence constraints can be expresse as: ^ [/ r 'M. " a = 8 ² :[ ³'M. " 5 [ T w for all ² g <.'³ (9) A power/energy aware software pipelining metho shoul try to construct a scheule that oes not incur any performance egraation an also consumes the minimum energy. A simple objective function to minimize the energy consumption for the same initiation interval, is the one which minimizes the number of instructions issue to fast FUs. Assuming µ v"4 Yˆ& 53 an µ v4 ]ŠŒ are the weights for fast

4 n an slow functional units of type x, the objective function is given by: BkPl,mŽnp ² n = a 8? B n] 5 N² :F[ ³t³ (10) The full ILP formulation has the objective function as Equation 10 uner the constraints given by Equations Experimental Framework Using the ILP formulation propose in the previous section, we explore how the esign space of an Itanium-like architecture [8, 9] can be mae power-efficient by introucing slow FUs. Itanium is an Explicitly Parallel Instruction Computing (EPIC) processor that can issue 6 instructions in a single cycle. It has four types of functional units: M-unit, I-unit, F-unit, an B-unit, which work primarily for memory access, integer operations, floating-point operations an branch instructions respectively [9, 8]. In our work, we concentrate on M-unit an I-unit for power/energy reuction. We use a simple power moel in our experiments. Empirically, it was foun that FUs working on half frequency consume about 40% (represente by µ in following equation) of the energy consume by fast FUs [21]. That is, 5 U a = 8? Also, since we consier only slow M-unit an I-unit FUs in our experiments, we assume that the energy consume by the two types of FUs are same. Thus, Further, we assume the total energy consume by FUs incurre for the software pipeline scheule is the sum of the energy incurre for each instruction in the scheule. Ignoring the energy consume by inactive functional units an components such as issue logic an caches, the energy consume by a single iteration of the scheule of a loop as: = Li a = 8 a = 8 i 5 5 wherew Yˆ& 5354 anw 5ŠŒ " 4 represent the number of instructions scheule on fast an slow FUs. Using the trip counts of iniviual loops, the total energy consume by all software pipelineable loops as well as their total execution time were calculate. For etails on the energy moel, we reaers are referre to [19]. In our implementation, we use the Open64 compiler [18], with the highest optimization level enable, to extract the DDGs for software pipelineable loops from the SPEC2000 integer benchmark suite. For the extracte DDGs, our implementation generates the ILP formulation which is solve by a commercial integer linear programming solver, CPLEX [7]. The CPLEX solver gave us the scheule, the initiation interval of the loop, an instruction partitioning (to fast an slow FUs) of each DDG. By taking trip count of each DDG (which we obtaine by profiling using the train ata sets) into account, we get an overall estimate of the program performance an energy consumption. Table 1 summarizes the benchmarks use in our experiments, the number of software pipelineable loops in them, an the characteristics of the DDGs associate with these loops. Benchmark No. of # of noes # of eges Minimum II Loops (avg) (max) (avg) (max) (avg) (max) 164.gzip vpr mcf crafty parser bzip twolf Table 1. Statistics on DDGs Use 4. Experimental Results 4.1 Impact of Slow FUs In all our experiments, we consiere fast an slow FUs for the I-unit FUs an M-unit FUs only, together referre to as integer FUs. Further, in our experiments we kept the total number of integer FUs as 4, while the number of slow/fast FUs is varie among the configurations. We consier the following four configurations: C0 2 fast I-unit an 2 fast M-unit FUs C1 1 fast I-unit, 1 slow I-unit, an 2 fast M-unit FUs C2 1 fast an 1 slow in each integer FU type C3 2 slow I-unit, 1 slow M-unit, an 1 fast M-unit FUs Figure 4(a) an (b) show the energy gain an performance loss of configurations C1 C3 on all benchmarks, compare against the energy an performance of the baseline configuration C0. The last set of bars inicate the average energy reuction an performance egraation taken across all benchmarks. For configuration C1, we observe an energy gain of 12% or more in all the applications. With configurations C2, the energy savings increase to 18% an more. Lastly, for configuration C3, the energy gain is higher, ranging from 20% to 41%. It is important to note that the above energy savings are obtaine only by compromising a little or no performance in many cases. For configuration C1, except for benchmarks gzip an crafty which show relatively large performance egraation, 19.6% an 10% respectively, all other benchmarks incur very little performance egraation, often less than 1%. With configurations C2, the performance egraes, by 5% 20%, in 4 of the benchmarks, while for other three (mcf, parser an twolf) the performance egraation is negligible. Lastly, for configuration C3, both the performance egraation an the energy gain are higher. It shoul be

5 gzip vpr mcf crafty parser bzip2 twolf avg C1 C2 C C1 C2 C rate optimal PDT = 10% PDT = 20% PDT = 30% Energy saving Performance loss Energy saving with performance slack Benchmarks (a) Energy Gain uner Different Configurations 0 gzip vpr mcf crafty parser bzip2 twolf avg Benchmarks (b) Performance Penalty uner Different Configurations 0 gzip vpr mcf crafty parser bzip2 twolf avg Benchmarks (c) Energy Gain Traing Performance Figure 4. Energy-Performance Traeoff note here that even with configurations C2 an C3 (with, respectively, 2 an 3 slow FUs), the egraation in performance is within 15% for all the benchmarks, except gzip. Lastly, we observe that gzip suffers relatively large performance loss when slow functional units are introuce. This observation agrees with that of relate work by Seng et al [10]. Interestingly, two benchmarks, namely mcf an parser, incur no performance egraation even when 3 of the 4 integer units act as slow FUs. To summarize, for the benchmarks we stuie, configurations C1, C2 an C3 consume, respectively, 17.5%, 25.3%, an 30.2% less energy, on the average, compare to the baseline architecture. 4.2 Traing Performance for Energy Next we aress the question that whether further energy savings can be obtaine in ual spee architectures if the compiler is allowe to trae performance. To answer this question, we conuct a set of experiments on configuration C2 (with 2 fast an 2 slow FUs). Here, for each software pipelineable loop, we set the optimal II obtaine for configuration C2 as the base II value. We allow our compiler to choose an II value which is within a performance egraation threshol (PDT) from the base II value, an try to obtain energy-efficient scheules. We chose PDTs as 10%, 20%, 30% for each application. In Figure 4(c) we plot the energy savings compare to the baseline configuration (C0) for various PDT values. As shown in the figure, energy gains in three benchmarks, namely vpr, mcf, an twolf, increase with increase PDT value. However, in the other benchmarks, the energy savings appear only when the PDT is increase from 10% to 20%. The insignificant benefit in performance when the PDT is increase from 0% to 10% can be explaine by the fact that these benchmarks have a lower average Minimum II(MII) than the three benchmarks, as shown in Table 1. For those DDGs with small minii, 10% PDT leaves no space for them to increase its II. When a PDT value of 30%, is use, the energy gain is more apparent for all benchmarks. The average energy savings for PDTs of 20% an 30% are 31.8% an 34% respectively. Lastly, we note that a PDT value refers to an increase in the iniviual II. Hence a PDT of, say 20%, oes not necessarily mean a 20% egraation on the execution time. The average performance egraation for the benchmarks is only 15.4% when the PDT is 20%. 5. Relate Work A limit stuy on available scheule slack was performe by Casmira et al [3] which report that in more than 75% of the execution cycles there exists at least one instruction that has slack. Pyrey et al [12] exten this iea by partitioning functional units to fast ones an slow ones, operating the slow ones at half the rate of fast ones, an using runtime profiling to guie instruction issue to these two sets of functional units. In contrast, Seng et al propose to analyze instruction criticality ynamically an issue critical instructions to fast functional units while non-critical instructions to slow ones [10]. The mechanism they aopt to preict instruction criticality is the critical path preictor buffer [4]. Although interesting, the buffer consumes aitional power which may offset the power gain in functional units. The work by Zhang et al [21] uses compilation techniques to etermine the fast or slow functional units where each instruction shoul be issue to. They esigne a energy-oriente heuristic algorithm to re-orer a scheule mae by some performance-oriente scheuling algorithm to achieve energy saving with minimal performance egraation. A relevant work by Yun et al [20] targets poweraware software pipelining. They propose a heuristic algorithm which extene iterative moulo scheuling [13], tries to minimize step power for a software pipeline loop on a cycle-by-cycle basis.

6 6. Conclusions This paper reports a quantitative stuy of powerperformance trae-offs in the esign space of energy efficient architectures. It stuies the interplay between lowpower architecture features an compiler optimization techniques, specifically software pipelining. It explores both the architecture an the compiler sie of esign space. An Itanium-like architecture moel involving ual spee pipelines (slow an fast FUs) is use in this stuy. We have propose an elegant integer linear programming formulation for rate-optimal software pipelining on architectures involving ual-spee pipelines. We explore the esign space of Itanium-like architectures for energyperformance traeoffs. Our experimental results show that consierable energy saving can be achieve by introucing a few small functional units, with very small performance egraation. We also emonstrate that further energy gains can be obtaine by traing performance. Acknowlegment The authors woul like to acknowlege George Cai from Intel for his support on builing our power-aware computing testbe. We wish to thank Roy Ju from Intel, Chenyong Wu from Open Research Compiler (ORC) team of Chinese Acaemy of Sciences, an Peng Zhao from University of Alberta, for their help an comments on the initial rafts of this paper. Last, we acknowlege the research funings from DOE an NSF for builing our compiler infrastructure. References [1] E. R. Altman, R. Govinarajan, an G. R. Gao. Scheuling an mapping: Software pipelining in the presence of structural hazars. In Proc. of SIGPLAN PLDI 95, pages , La Jolla, Calif., Jun [2] D. Brooks, P. Bose, S. Schuster, H.Jacobson, P. K. Kuva, A. Buyuktosunoglu, J.-D. Wellman, V. Zyuban, M. Gupta, an P. Cook. Power-aware microarchtiecture: Design an moelling challenges for next-generation microprocessors. IEEE Micro, 20(6), Nov [3] J. Casmira an D. Grunwal. Dynamic instruction scheuling slack. In Proceeings of the 2000 KoolChips workshop, Monterey, California, Dec 10th [4] E.Tune, D.Liang, D.Tullsen, an B.Caler. Dynamic preiction of critical path instructions. In Proceeings of the 7th International Symposium on High Performance Computer Architecture, Feb [5] R. Govinarajan, E. R. Altman, an G. R. Gao. Minimizing register requirements uner resource-constraine rateoptimal software pipelining. In Proc. of MICRO-27, pages 85 94, San Jose, Calif., Nov. Dec [6] R. Govinarajan, E. R. Altman, an G. R. Gao. A framework for resource-constraine rate-optimal software pipelining. IEEE Trans. on Parallel an Distrib. Systems, 7(11): , Nov [7] ILOG. CPLEX mixe integer solver. [8] Intel. Intel IA-64 Architecture Software Developer s Manual, Aug [9] Intel. Itanium Processor Microarchitecture Reference for Software Optimization, Aug [10] J.Seng, E.Tune, an D.Tullsen. Reucing power with ynamic critical path information. In Proc. of MICRO-34, pages , Austin, TX, Dec [11] M. Lam. Software pipelining: An effective scheuling technique for VLIW machines. In Proc. of SIGPLAN PLDI 88, pages , Atlanta, Geor., Jun [12] R. Pyrey an G. Tyson. Evaluating esign traeoffs in ual spee pipelines. In Workshop on Complexity-Effective Design, Goteborg, Sween, Jun [13] B. R. Rau. Iterative moulo scheuling: An algorithm for software pipelining loops. In Proc. of MICRO-27, pages 63 74, San Jose, Calif., Nov. Dec [14] B. R. Rau an J. A. Fisher. Instruction-level parallel processing: History, overview an perspective. J. of Supercomputing, 7:9 50, May [15] B. R. Rau an C. D. Glaeser. Some scheuling techniques an an easily scheulable horizontal architecture for high performance scientific computing. In Proc. of MICRO-14, pages , Chatham, Mass., Oct [16] R. Reiter. Scheuling parallel computations. J. of the ACM, 15(4): , Oct [17] J. Ruttenberg, G. R. Gao, A. Stouchinin, an W. Lichtenstein. Software pipelining showown: Optimal vs. heuristic methos in a prouction compiler. In Proc. of SIGPLAN PLDI 96, pages 1 11, Philaelphia, May [18] SGI. Open64 open source compiler. [19] H. Yang, R. Govinarajan, G. R. Gao, an K. B. Theobal. A quantitative stuy on performance-power impact of ualspee pipeli ne architectures. CAPSL Tech. Memo 42, Dept. of Elec. an Computer Eng., U. of Delaware, Newark, Del., Jun In ftp://ftp.capsl.uel.eu/pub/oc/memos. [20] H.-S. Yun an J. Kim. Power-aware moulo scheuling for high-performance vliw processors. In Proceeings of the International Symposium on Low Power Electronics an Design 2001, Aug [21] W. Zhang, N.Vijaykrishnan, M.Kanemir, M.Irwin, D.Duarte, an Y. Tsai. Exploiting VLIW scheule slacks for ynamic an leakage energy reuction. In Proc. of MICRO-34, pages , Austin, TX, Dec 2001.