Finding Cool Code: An Analysis of Source-LevelCauses of Temperature Effects

Dan Upton and Kim HazelwoodDepartment of Computer Science

University of Virginia

I. INTRODUCTION

Temperature issues have become a first-order concern formicroprocessors over the last several microprocessor gener-ations. An increase in on-chip transistor density has led toincreased power density and therefore higher on-die temper-atures. Higher processor temperatures lead to concerns forboth cooling costs and reliability. In the short term, highertemperatures can affect the correctness of calculations or leadto throttling or disabling a processor [1]. Over time, increasingthe average execution temperature by 10-15◦C can reduce theprocessor lifespan by as much as half [2].

In addition to hardware throttling, there are a variety ofsoftware-based approaches using dynamic frequency scal-ing [3], scheduling [4], or a combination of the two [5]. Thesemay be driven either by static algorithms or some amountof prediction based on the current temperature and recenthistorical temperatures. However, this leads to the questionof whether application characteristics, either at the softwareor microarchitectural level, can provide information aboutthermal characteristics without having to directly monitortemperature. Predicting temperatures or temperature changesfrom application characteristics enables predictive thermalmanagement, rather than waiting and managing the thermalstate when higher temperatures have been reached.

Understanding the relationship between software-level char-acteristics and thermal characteristics leads to many pos-sibilities: hints could be given to a thermally-aware OSscheduler, code transformations could be developed to reducetemperatures in potentially hot code regions, or programmerscould write code with thermal management in mind from thebeginning. Considering thermal management at developmenttime gives the developer the ability to make a tradeoff betweentemperature and throughput, or choose whether they want tomanage temperature in advance or rely on run-time manage-ment.

This work presents correlations between temperature andother microarchitectural and software-level characteristics.Previous work [6] demonstrated a correlation between phasesin various microarchitectural characteristics such as IPC, cachemiss rates, and power; we extend this to show a correlationbetween microarchitectural phase changes and temperaturechanges. This is true of applications with long stable phases aswell as applications with short or rapidly-changing phases. Wethen map information about temperature back to the applica-

-3

-2

-1

0

1

2

3

0 500 1000 1500 2000 2500 3000Time

IPC

TempDelta Temperature

IPC

Fig. 1. IPC over time compared to temperature deltas for 473.astar’s firstinput. Although temperature rises with phases, several temperature changesalso correspond to application phase changes.

tion source. We show that lower temperatures tend to correlatewith complex control flow and data access patterns based onpointer chasing, while predictable branches or regular cache-access patterns tend to correlate with higher temperatures.Finally, we consider the effects of changing the compileror hardware environment. We show that compiler instructionselection can significantly impact temperature behavior, whilethe change in temperature with respect to phase changes tendsto be consistent across hardware platforms.

II. TEMPERATURE PHASES

We use the change in temperature from the last time step asthe best comparison point to see how temperature changes cor-relate with phase changes. Since previous work [6] on phasebehavior showed the same phases occur in all characteristics,we compare temperature to IPC.

Figure 1 shows a comparison of the IPC and the temperaturedeltas on 473.astar’s first input from the SPEC 2006benchmark suite. The application has several distinct phases,including four phases with low average IPC and one with ahigher IPC. Comparing the temperature deltas shows that thetemperatures will increase some during phases, due to moreheat being injected to the system than can be removed by thecooling solution. However, there are also several temperaturechanges that occur right after a phase change, including the

117978-1-61284-368-1/11/$26.00 ©2011 IEEE

void regwayobj::makebound2(regboundart& b1arp,regboundart& b2arp)

{i32 i,j;regobjpt region1p,region2p;b2arp.clear();for (j=0; j<b1arp.elemqu; j++){region1p=b1arp[j];for (i=0; i<region1p->nb1ar.elemqu;

i++){

region2p=region1p->nb1ar[i];if (isaddtobound(region1p,region2p))

addtobound(b2arp,region2p);}}}

Fig. 2. Code for regwayobj::makebound2, which dominates the secondand fifth phases of 473.astar. In this case, the work is mostly pointerchasing, which leads to an increase in cache misses and a drop in IPC andtemperature.

increase in IPC and increase in temperature around timex = 1000 and the decreases in temperature and IPC at timesx = 408, x = 2053, and x = 2300.

A natural question is whether the correlation betweenphase changes and temperature changes on 473.astar isdue to the long, stable phases in that application. However,we see the same relationship between phase changes andtemperature changes on 410.bwaves, which has severalrapid positive and negative changes in IPC that correspondto similar oscillating temperatures. The correspondence isalso seen on applications with shorter run times, such as thevarious inputs to 403.gcc. Finally, there are applicationsthat consist of only a single phase, such as the single-loop436.cactusADM. Applications with no distinct phases tendto only increase in temperature.

III. SOURCE CODE AND TEMPERATURE

For each temperature sample, we also determined thecurrently-executing instruction. We then used Pin [7], a dy-namic binary instrumentation system, to access the debuginformation and map instruction pointers to source code lines.We used this information to see what code was most frequentlyexecuted during a phase to determine how source code patternsrelate to temperature. When phases primarily executed librarycode, we used /proc/$pid/maps to determine the libraryand function name.

One example is regwayobj::makebound2 from473.astar, which dominates two of the phases. The rel-evant source is shown in Figure 2. In this case, the A*pathfinding algorithm operates on a graph and uses pointerchasing to determine a path. As a result, the code has a highermiss rate in the data and last level caches. The increased cachemiss rate decreases IPC and in turn leads to a decrease intemperature.

In addition to the cache miss rate, we found the control-flow

complexity and related branch misprediction rate to have aneffect on temperature. On 410.bwaves, there are essentiallytwo phases, both of which are implemented using SIMDinstructions; however, the lower-temperature phase have abranch misprediction rate of 6%, while the higher-temperaturephase has a branch misprediction rate of only 1%.

IV. COMPILER AND HARDWARE EFFECTS

The work in the previous sections used a desktop Core 2Duo and gcc 3.4.6. We tested the code on the same hard-ware as compiled with icc 11.1 and found that significantlydifferent code generation led to 410.bwaves having a differ-ent phase pattern and hotter temperatures. Other benchmarkshad shorter run times but similar behavior otherwise.

We also tested with gcc on an eight-core server machine.The phase relationships were similar across the two machines,although the thermal characteristics of the server cores aredifferent and the thermal range was much smaller.

V. CONCLUSIONS

This work discussed how source- and microarchitectural-level characteristics correlate with processor temperature. Wefirst looked at correlations between phase changes and tem-perature changes. We showed that transitions to high-IPCphases tend to correlate with increases in temperature, whiletransitions to low-IPC phases tend to correlate with decreasesin temperature. Applications that exhibit no phase behaviortend to increase steadily in temperature. We then showed thatsource characteristics such as control flow and data accesspatterns also tend to correlate with temperature behaviors.Finally, we showed that the relationship between phases andtemperature are consistent across architectures but that codeselection by the compiler can have an impact on phaselengths and temperature behaviors. Understanding temperaturebehaviors at the application level can lead to hints for thermalmanagement or allow the developer to write code with thermalmanagement in mind.

REFERENCES

[1] Intel Corporation, Intel 64 and IA-32 Architectures Software Developer’sManual, Volume 3: System Programming Guide. Order #253668-026US,February 2008.

[2] R. Viswanath, V. Wakharkar, A. Watwe, and V. Lebonheur, “Thermal per-formance challenges from silicon to systems,” Intel Technology Journal,Q3 2000.

[3] L. Miao, Y. Qi, D. Hou, and Y. Dai, “Energy-aware scheduling taskson chip multiprocessor,” in 2007 International Conference on NaturalComputation. Washington, DC, USA: IEEE Computer Society, 2007,pp. 319–323.

[4] A. K. Coskun, T. S. Rosing, and K. Whisnant, “Temperature aware taskscheduling in MPSoCs,” in 2007 Conference on Design, Automation andTest in Europe, Nice, France, 2007, pp. 1659–1664.

[5] R. Jayaseelan and T. Mitra, “Temperature aware task sequencing andvoltage scaling,” in 2008 International Conference on Computer-AidedDesign, San Jose, CA, November 2008.

[6] T. Sherwood, S. Sair, and B. Calder, “Phase tracking and prediction,”in 2003 International Symposium on Computer Architecture, San Diego,CA, 2003, pp. 336–349.

[7] C.-K. Luk, R. Cohn, R. Muth, H. Patil, A. Klauser, G. Lowney, S. Wal-lace, V. J. Reddi, and K. Hazelwood, “Pin: building customized programanalysis tools with dynamic instrumentation,” in 2005 Conference onProgramming Language Design and Implementation, Chicago, IL, USA,2005, pp. 190–200.

118