Lecture Notes in Computer Science 4917

More documents

Recommendations

Info

358 S. Sarkar and D.M. Tullsen 4 Independent Data Placement In the next two sections, we consider two different execution scenarios. In this section, we solve the more general and difficult scenario, where the compiler actually does not know which applications will be scheduled together dynamically, or the set of co-scheduled threads changes frequently; however, we assume all applications will have been generated by our compiler. In this execution scenario, then, co-scheduling will be largely unpredictable and dynamic. However, we can still compile programs in such a way that conflict misses are minimized. Since all programs would essentially be compiled in the same way, some support from the operating system, runtime system, or the hardware is required to allow each co-scheduled program to be mapped onto the cache differently. We have modified CCDP techniques to create an intentionally unbalanced utilization of the cache, mapping objects to a hot portion and a cold portion. This does not necessarily imply more intra-thread conflict misses. For example, the two most heavily accessed objects in the program can be mapped to the same cache index without a loss in performance, if they are not typically accessed in an interleaved pattern – this is the point of using the temporal relationship graph of interleavings to do the mapping, rather than just using reference counts. CCDP would typically create a more balanced distribution of accesses across the cache; however, it can be tuned to do just the opposite. This is a similar approach to that used in [19] for procedure placement, but applied here to the placement of data objects. However, before we present the details of the object placement algorithm, we first describe the assumptions about hardware or OS support, how data objects are identified and analyzed, and some options that make the CCDP algorithms faster and more realizable. 4.1 Support from Operating System or Hardware Our independent placement technique (henceforth referred to as IND) repositions the objects so that they have a top-heavy access pattern, i.e. most of the memory accesses are limited to the top portion of the cache. Now let us consider an SMT processor with two hardware contexts, and a shared L1 cache (whose size is at least twice the virtual-memory page size). If the architecture uses a virtual cache, the processor can xor the high bits of the cache index with a hardware context ID (e.g., one bit for 2 threads, 2 bits for 4 threads), which will then map the hot portions of the address space to different regions of the cache. In a physically indexed cache, we don’t even need that hardware support. When the operating system loads two different applications in the processor, it ensures (by page coloring or otherwise) that heavily accessed virtual pages from the threads do not collide in the physically indexed cache. For example, let us assume an architecture with a 32 KB data cache, 4 KB memory pages, and two threads. The OS or runtime allocates physical pages to virtual pages such that the three least significant bits of the page number are preserved for thread zero, and for thread one the same is done but with the third bit reversed. Thus, the mapping assumed by the compilers is preserved, but with
Compiler Techniques for Reducing Data Cache Miss Rate 359 each thread’s “hot” area mapped to a different half of the cache. This is simply an application of page coloring, which is not an unusual OS function. 4.2 Analysis of Data Objects To facilitate data layout, we consider the address space of an application as partitioned into several objects. Anobject is loosely defined as a contiguous region in the (virtual) address space that can be relocated with little help from the compiler and/or the runtime system. The compiler typically creates several objects in the code and data segment, the starting location and size of which can be found by scanning the symbol table. A section of memory allocated by a malloc call can be considered to be a single dynamic object, since it can easily be relocated using an instrumented front-end to malloc. However, since the same invocation of malloc can return different addresses in different runs of an application – we need some extra information to identify the dynamic objects (that is, to associate a profiled object with the same object at runtime). Similar to [1], we use an additional tag (henceforth referred to as HeapTag) toidentify the dynamic objects. HeapTag is generated by xor-folding the top four addresses of the return stack and the call-site of malloc. We do not attempt to reorder stack objects. Instead the stack is treated as a single object. After the objects have been identified, their reference count and lifetime information over the simulation window can be retrieved by instrumenting the application binary with a tool such as ATOM [22]. Also obtainable are the temporal relationships between the objects, which can be captured using a temporal relationship graph (henceforth referred to as TRGSelect graph). The TRGSelect graph contains nodes that represent objects (or portions of objects) and edges between nodes contain a weight which represents how many times the two objects were interleaved in the actual profiled execution. Temporal relationships are collected at a finer granularity than full objects – mainly because some of the objects are much larger than others, and usually only a small portion of a bigger object has temporal association with the smaller one. It is more logical to partition the objects into fixed size chunks, and then record the temporal relationship between chunks. Though all the chunks belonging to an object are placed sequentially in their original order, having finer-grained temporal information helps us to make more informed decisions when two conflicting objects must be put in an overlapping cache region. We have set the chunk size equal to the block size of the targeted cache. This provides the best performance, as we now track conflicts at the exact same granularity that they occur in the cache. 4.3 Object and Edge Filtering Profiling a typical SPEC2000 benchmark, even for a partial profile, involves tens of thousands of objects, and generates hundreds of millions of temporal relationship edges between objects. To make this analysis manageable, we must reduce both the number of nodes (the number of objects) as well as the number
Page 1 and 2:
Lecture Notes in Computer Science 4
Page 3 and 4:
Volume Editors Per Stenström Chalm
Page 5 and 6:
VI Preface The planning of a confer
Page 7 and 8:
VIII Organization Mahmut Kandemir P
Page 9 and 10:
Invited Program Table of Contents S
Page 11:
Table of Contents XIII Turbo-ROB: A
Page 14 and 15:
4 M. Valero and J. Labarta future s
Page 17 and 18:
MIPS MT: A Multithreaded RISC Archi
Page 19 and 20:
2.2 VPEs as Scheduling Domains MIPS
Page 21 and 22:
MIPS MT: A Multithreaded RISC Archi
Page 23 and 24:
6.1 Thread Context Virtualization M
Page 25 and 26:
8 Experimental Results MIPS MT: A M
Page 27 and 28:
Cycles/ Iteration MIPS MT: A Multit
Page 29:
9 Conclusions MIPS MT: A Multithrea
Page 32 and 33:
MPI: Message Passing on Multicore P
Page 34 and 35:
Page 36 and 37:
Page 38 and 39:
overhead per word (cycles) 1200 100
Page 40 and 41:
speedup 3.5 3 2.5 2 1.5 1 0.5 0 rMP
Page 42 and 43:
speedup 9 8 7 6 5 4 3 2 1 0 rMPI: M
Page 44 and 45:
Page 46 and 47:
Page 48 and 49:
Modeling Multigrain Parallelism on
Page 50 and 51:
Page 52 and 53:
Page 54 and 55:
Page 56 and 57:
Page 58 and 59:
Page 60 and 61:
Page 63 and 64:
BRAM-LUT Tradeoff on a Polymorphic
Page 65 and 66:
32 L0 L1 BRAM-LUT Tradeoff on a Pol
Page 67 and 68:
Page 69 and 70:
Page 71 and 72:
Page 73:
Page 76 and 77:
Architecture Enhancements for the A
Page 78 and 79:
Page 80 and 81:
Page 82 and 83:
Page 84 and 85:
Page 86 and 87:
Page 88 and 89:
Page 90 and 91:
Page 92 and 93:
Implementation of an UWB Impulse-Ra
Page 94 and 95:
Page 96 and 97:
Page 98 and 99:
Page 100 and 101:
Page 102 and 103:
Page 104 and 105:
Page 107 and 108:
Fast Bounds Checking Using Debug Re
Page 109 and 110:
Page 111 and 112:
Page 113 and 114:
Page 115 and 116:
Page 117 and 118:
Page 119 and 120:
Page 121:
Page 124 and 125:
Studying Compiler Optimizations on
Page 126 and 127:
Page 128 and 129:
Page 130 and 131:
avg normalized execution time 1.000
Page 132 and 133:
Page 134 and 135:
Page 136 and 137:
Page 138 and 139:
Page 140 and 141:
CLI as an Effective Deployment Form
Page 142 and 143:
Page 144 and 145:
Page 146 and 147:
Page 148 and 149:
Page 150 and 151:
Page 152 and 153:
Page 155 and 156:
Compilation Strategies for Reducing
Page 157 and 158:
Page 159 and 160:
Page 161 and 162:
Page 163 and 164:
Page 165 and 166:
Page 167 and 168:
180% 160% 140% 120% 100% 80% 60% 40
Page 169 and 170:
Experiences with Parallelizing a Bi
Page 171 and 172:
Page 173 and 174:
Page 175 and 176:
Page 177 and 178:
Page 179 and 180:
Page 181 and 182:
Page 183:
Page 186 and 187:
Drug Design Issues on the Cell BE 1
Page 188 and 189:
Page 190 and 191:
Page 192 and 193:
Page 194 and 195:
speed-up 8 6 4 2 0 FFT3D 256 64-A F
Page 196 and 197:
Page 198 and 199:
Page 201 and 202:
COFFEE: COmpiler Framework for Ener
Page 203 and 204:
Page 205 and 206:
Benchmark Source Code * transformed
Page 207 and 208:
Page 209 and 210:
RTL for each Component * Gate−lev
Page 211 and 212:
Page 213 and 214:
Normalized Cycle Count 1.00 0.90 0.
Page 215 and 216:
Page 217 and 218:
Integrated CPU Cache Power Manageme
Page 219 and 220:
Page 221 and 222:
Page 223 and 224:
Page 225 and 226:
Page 227 and 228:
Page 229 and 230:
Page 231:
Page 234 and 235:
Variation-Aware Software Techniques
Page 236 and 237:
Page 238 and 239:
Page 240 and 241:
Page 242 and 243:
Page 244 and 245:
Average leakage-power saving (%) Va
Page 246 and 247:
Page 248 and 249:
Page 250 and 251:
244 Y. Sazeides et al. of mispredic
Page 252 and 253:
246 Y. Sazeides et al. Affector BB1
Page 254 and 255:
248 Y. Sazeides et al. 2.3 How to U
Page 256 and 257:
250 Y. Sazeides et al. Cumulative D
Page 258 and 259:
252 Y. Sazeides et al. ijpeg, andbo
Page 260 and 261:
254 Y. Sazeides et al. Misses/KI 12
Page 262 and 263:
256 Y. Sazeides et al. Mahlke and N
Page 265 and 266:
Turbo-ROB: A Low Cost Checkpoint/Re
Page 267 and 268:
260 P. Akl and A. Moshovos Original
Page 269 and 270:
262 P. Akl and A. Moshovos Oldest I
Page 271 and 272:
264 P. Akl and A. Moshovos new firs
Page 273 and 274:
266 P. Akl and A. Moshovos throttli
Page 275 and 276:
268 P. Akl and A. Moshovos 80% 70%
Page 277 and 278:
270 P. Akl and A. Moshovos 25% 20%
Page 279:
272 P. Akl and A. Moshovos [4] Burg
Page 282 and 283:
274 A. García et al. execution tim
Page 284 and 285:
276 A. García et al. whenever LPA
Page 286 and 287:
278 A. García et al. @12: load r2,
Page 288 and 289:
280 A. García et al. Target Loop E
Page 290 and 291:
282 A. García et al. reduction 100
Page 292 and 293:
284 A. García et al. IPC speedup 7
Page 294 and 295:
286 A. García et al. SPECfp benchm
Page 297 and 298:
Complementing Missing and Inaccurat
Page 299 and 300:
90 100 100 25 75 25 25 100 100 10 1
Page 301 and 302:
Page 303 and 304:
Page 305 and 306:
Page 307 and 308:
6.1 Filling Edge Profile from Verte
Page 309 and 310:
Page 311 and 312:
Using Dynamic Binary Instrumentatio
Page 313 and 314: L1 D-Cache Miss Rate (%) CPI 5 4 3
Page 315 and 316: Using Dynamic Binary Instrumentatio
Page 319 and 320: CPI Error (%) 10 5 0 -5 -10 FP Resu
Page 321 and 322: CPI Error (%) 40 30 20 10 0 Using D
Page 325: Using Dynamic Binary Instrumentatio
Page 328 and 329: Phase Complexity Surfaces: Characte
Page 336 and 337: ( log10) phases of Number 4.0 3.5 3
Page 343 and 344: MLP-Aware Dynamic Cache Partitionin
Page 353 and 354: (a) IPC as we vary the number of as
Page 359 and 360: Compiler Techniques for Reducing Da
Page 363: Compiler Techniques for Reducing Da
Page 371 and 372: 40 35 30 25 ) te ( % 20 -ra M is s
Page 373 and 374: References Compiler Techniques for
Page 375 and 376: Code Arrangement of Embedded Java V
Page 389: Code Arrangement of Embedded Java V
Page 392 and 393: Aggressive Function Inlining: Preve
Page 394 and 395: f1(){ ...g();....} f2(){....q();...
Page 400 and 401: foo:(80 times) BB1: Call bar BB2: C
Page 406: 400 Author Index Shajrawi, Yousef 3
show all

Lecture Notes in Computer Science 4917

Create successful ePaper yourself

Delete template?

Save as template?