Many-Core Graph Workload Analysis

Eyerman, Stijn; Heirman, Wim; Bois, Kristof Du; Fryman, Joshua B.; Hur, Ibrahim

doi:10.1109/sc.2018.00025

Cited by 22 publications

(21 citation statements)

References 16 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…To evaluate ISLE's performance, we use a modified version of the Sniper multicore simulator [6]. Following the recommendations by Eyerman et al [12], and similar to both PIUMA and Emu, we use a baseline architecture consisting of many in-order cores and highbandwidth memory, but no large shared caches (see Table 4). For some experiments, we use an out-of-order core similar to Intel's Knights Landing [36].…”

Section: Methodsmentioning

confidence: 99%

“…On large graph workloads, the performance of conventional out-of-order processors is often latency-bound as the cores wait for (hard-to-predict) memory operations to return [12]. In contrast, most specialized graph processors employ massive multithreading to keep many independent memory accesses outstanding.…”

Section: Graph Analytics Processor Architecturementioning

confidence: 99%

“…Our baseline configuration has a 512 KB L2 cache and prefetchers, which improve performance on more complex algorithms with moderate working sets. Eyerman et al [12] suggested a more extreme architecture with only 16 KB of cache per core and no prefetchers, motivated by the low memory access locality. Figure 9 evaluates the effect of ISLE when applied to a number of different memory subsystem implementations for those workloads that are sensitive to sublining.…”

Section: Isle and Alternative Processor Configurationsmentioning

confidence: 99%

“…When removing the effect of bad prefetches, the impact of input sizes becomes more clear: for small graph sizes (18 and 20), a larger fraction of the data fits in cache so sublining is not needed. The no-L2/PF option represents the extreme no-cache architecture from [12]. In all of these cases, ISLE is able to adapt each workload to the configuration to find significant performance improvements.…”

Section: Isle and Alternative Processor Configurationsmentioning

confidence: 99%

“…Moreover, they show inefficient use of memory bandwidth: for every access of a single element (e.g., 8 B), a full cache line (e.g., 64 B) is fetched from memory, leading to low bandwidth efficiency. As a result, sparse accesses not only have low performance, they also degrade the performance of more regular accesses by thrashing caches, triggering useless prefetches, and exhausting memory bandwidth [12].…”

Section: Introductionmentioning

confidence: 99%

See 4 more Smart Citations

Automatic Sublining for Efficient Sparse Memory Accesses

Heirman¹,

Eyerman²,

Bois³

et al. 2021

ACM Trans. Archit. Code Optim.

Self Cite

View full text Add to dashboard Cite

Sparse memory accesses, which are scattered accesses to single elements of a large data structure, are a challenge for current processor architectures. Their lack of spatial and temporal locality and their irregularity makes caches and traditional stream prefetchers useless. Furthermore, performing standard caching and prefetching on sparse accesses wastes precious memory bandwidth and thrashes caches, deteriorating performance for regular accesses. Bypassing prefetchers and caches for sparse accesses, and fetching only a single element (e.g., 8 B) from main memory (subline access), can solve these issues. Deciding which accesses to handle as sparse accesses and which as regular cached accesses, is a challenging task, with a large potential impact on performance. Not only is performance reduced by treating sparse accesses as regular accesses, not caching accesses that do have locality also negatively impacts performance by significantly increasing their latency and bandwidth consumption. Furthermore, this decision depends on the dynamic environment, such as input set characteristics and system load, making a static decision by the programmer or compiler suboptimal. We propose the Instruction Spatial Locality Estimator ( ISLE ), a hardware detector that finds instructions that access isolated words in a sea of unused data. These sparse accesses are dynamically converted into uncached subline accesses, while keeping regular accesses cached. ISLE does not require modifying source code or binaries, and adapts automatically to a changing environment (input data, available bandwidth, etc.). We apply ISLE to a graph analytics processor running sparse graph workloads, and show that ISLE outperforms the performance of no subline accesses, manual sublining, and prior work on detecting sparse accesses.

show abstract

Section: Methodsmentioning

confidence: 99%

Section: Graph Analytics Processor Architecturementioning

confidence: 99%

Section: Isle and Alternative Processor Configurationsmentioning

confidence: 99%

Section: Isle and Alternative Processor Configurationsmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations