Supporting dynamic data structures on distributed-memory machines

Rogers, Anne; Carlisle, Martin C.; Reppy, John; Hendren, Laurie

doi:10.1145/201059.201065

Cited by 228 publications

(107 citation statements)

References 17 publications

Supporting

Mentioning

107

Contrasting

Order By: Relevance

“…Second, gating superscalar ways can be accomplished with two techniques: segmenting the bypass/writeback network so that only buses to active ways are driven, and (assuming that the register file achieves its high port count by using multiple replicas) writing results only to register file replicas for active execution lanes/ways. Workloads: We evaluate HBA with a set of 184 distinct checkpoint/traces, collected from the SPEC CPU2006 [52], Olden [45], and MediaBench [32] suites, and an array of other software: Firefox, FFmpeg, the Adobe Flash player, the V8 Javascript engine, the GraphChi graph-analysis framework [31], MySQL, the lighttpd web server, L A T E X, Octave (a MATLAB replacement), and a checkpoint/trace of the simulator itself. Many of these benchmarks had multiple checkpoint/traces collected at multiple representative regions as indicated by PinPoints.…”

Section: Methodsmentioning

confidence: 99%

The heterogeneous block architecture

Fallin¹,

Wilkerson

Mutlu³

2014

2014 IEEE 32nd International Conference on Computer Design (ICCD)

View full text Add to dashboard Cite

This paper makes two new observations that lead to a new heterogeneous core design. First, we observe that most serial code exhibits fine-grained heterogeneity: at the scale of tens or hundreds of instructions, regions of code fit different microarchitectures better (at the same point or at different points in time). Second, we observe that by grouping contiguous regions of instructions into blocks that are executed atomically, a core can exploit this heterogeneity: atomicity allows each block to be executed independently on its own execution backend that fits its characteristics best.Based on these observations, we propose a fine-grained heterogeneous design that combines heterogeneous execution backends into one core. Our core design, the heterogeneous block architecture (HBA), breaks the program into blocks of code, determines the best backend for each block, and specializes the block for that backend. As an initial, concrete design, we combine out-of-order, VLIW, and in-order backends, using simple heuristics to choose backends. We compare HBA to multiple baseline core designs (including monolithic out-of-order, clustered out-of-order, in-order and a state-of-the-art heterogeneous core design) and show that HBA can provide significantly better energy efficiency than all designs at similar performance. Averaged across 184 traces from a wide variety of workloads, HBA reduces core power by 36.4% and energy per instruction by 31.9% compared to a 4-wide out-of-order core. We conclude that HBA provides a flexible substrate for exploiting fine-grained heterogeneity, enabling new energy-performance tradeoff points in core design.

show abstract

Section: Methodsmentioning

confidence: 99%

The heterogeneous block architecture

Fallin¹,

Wilkerson

Mutlu³

2014

2014 IEEE 32nd International Conference on Computer Design (ICCD)

View full text Add to dashboard Cite

show abstract

“…The remaining 10 are randomly-chosen mixes from our set of 39 applications. Our application set consists of 26 SPEC CPU2006 benchmarks (including two traces of mcf), three SPEC CPU2000 benchmarks (vpr, art, crafty), and 10 other server and desktop traces: health (from the Olden benchmarks [45]), matlab [33], sharepoint.1, sharepoint.2 [37], stream [34], tpcc [1], xml (an XML-parsing application), search-1, search-2 (web-search traces from a commercial search engine).…”

Section: Workloadsmentioning

confidence: 99%

CHIPPER: A low-complexity bufferless deflection router

Fallin

Craik

Mutlu

2011

2011 IEEE 17th International Symposium on High Performance Computer Architecture

165

222

View full text Add to dashboard Cite

As Chip Multiprocessors (CMPs) scale to tens or hundreds of nodes, the interconnect becomes a significant factor in cost, energy consumption and performance. Recent work has explored many design tradeoffs for networks-on-chip (NoCs) with novel router architectures to reduce hardware cost. In particular, recent work proposes bufferless deflection routing to eliminate router buffers. The high cost of buffers makes this choice potentially appealing, especially for lowto-medium network loads.However, current bufferless designs usually add complexity to control logic. Deflection routing introduces a sequential dependence in port allocation, yielding a slow critical path. Explicit mechanisms are required for livelock freedom due to the non-minimal nature of deflection. Finally, deflection routing can fragment packets, and the reassembly buffers require large worst-case sizing to avoid deadlock, due to the lack of network backpressure. The complexity that arises out of these three problems has discouraged practical adoption of bufferless routing.To counter this, we propose CHIPPER (Cheap-Interconnect Partially Permuting Router), a simplified router microarchitecture that eliminates in-router buffers and the crossbar. We introduce three key insights: first, that deflection routing port allocation maps naturally to a permutation network within the router; second, that livelock freedom requires only an implicit token-passing scheme, eliminating expensive age-based priorities; and finally, that flow control can provide correctness in the absence of network backpressure, avoiding deadlock and allowing cache miss buffers (MSHRs) to be used as reassembly buffers. Using multiprogrammed SPEC CPU2006, server, and desktop application workloads and SPLASH-2 multithreaded workloads, we achieve an average 54.9% network power reduction for 13.6% average performance degradation (multiprogrammed) and 73.4% power reduction for 1.9% slowdown (multithreaded), with minimal degradation and large power savings at low-to-medium load. Finally, we show 36.2% router area reduction relative to buffered routing, with comparable timing.

show abstract

“…One is to explicitly differentiate between local and remote pointers (by using a different programming notation for each type). The main drawback of this approach, taken in several existing systems, including Cid [7], Earth [3], Olden [10], or MCRL [4], is that the original program must be significantly modified (manually or using compiler analysis [6] [10]) such that it always uses the correct reference-remote or localbased on the given mapping of the data structure. It also prevents the mapping of the data structure to be decided at runtime, which is a major limitation on dynamic pointerbased data structures.…”

Section: The Programming Modelmentioning

confidence: 99%