Understanding Big Data Analytics Workloads on Modern Processors

Abstract

Big data analytics applications play a significant role in data centers, and hence it has become increasingly important to understand their behaviors in order to further improve the performance of data center computer systems, in which characterizing representative workloads is a key practical problem. In this paper, after investigating three most important application domains in terms of page views and daily visitors, we chose 11 representative data analytics workloads and characterized their micro-architectural behaviors by using hardware performance counters, so as to understand the impacts and implications of data analytics workloads on the systems equipped with modern superscalar out-of-order processors. Our study reveals that big data analytics applications themselves share many inherent characteristics, which place them in a different class from traditional workloads and scale-out services. To further understand the characteristics of big data analytics workloads we performed a correlation analysis of CPI (cycles per instruction) with other microarchitecture level characteristics and an investigation of the big data software stack impacts on application behaviors. Our correlation analysis showed that even though big data analytics workloads own notable pipeline front end stalls, the main factors affecting the CPI performance are long latency data accesses rather than the front end stalls. Our software stack investigation found that the typical big data software stack significantly contributes to the front end stalls and incurs bigger working set. Finally we gave several recommendations for architects, programmers and big data system designers with the knowledge acquired from this paper.

BigDataBench: A Scalable and Unified Big Data and AI Benchmark Suite

“…So they suffer from more penalties because of switching to a special unit. Fourth, corroborating the previous work [32], the first bottleneck is backend bound for Big Data and AI. However, different from the previous work [32], we observe that the data movement delay among memory hierarchies is the main reason for backend bound, especially the latency delay from DRAM memory.…”

“…However, to explore deeply, their bottlenecks that incur the frontend and backend stalls are different, which means AI benchmarks have distinct computation patterns comparing to the traditional benchmarks. Corroborating the observations in the previous work [4], [31], [32], the frontend bound of Big Data is more severe than that of the traditional benchmarks. However, we notice that the frontend bound varies across different workload types.…”

DAMOV: A New Methodology and Benchmark Suite for Evaluating Data Movement Bottlenecks

“…High-performance systems have evolved to include mechanisms that aim to alleviate data movement's impact on system performance and energy consumption, such as deep cache hierarchies and aggressive prefetchers. However, such mechanisms not only come with significant hardware cost and complexity, but they also often fail to hide the latency and energy costs of accessing DRAM in many modern and emerging applications [1,5,50]- [52]. These applications' memory behavior can differ significantly from more traditional applications since modern applications often have lower memory locality, more irregular access patterns, and larger working sets [36,45,46,53]- [61].…”

DAMOV: A New Methodology and Benchmark Suite for Evaluating Data Movement Bottlenecks

“…High-performance systems have evolved to include mechanisms that aim to alleviate data movement's impact on system performance and energy consumption, such as deep cache hierarchies and aggressive prefetchers. However, such mechanisms not only come with significant hardware cost and complexity, but they also often fail to hide the latency and energy costs of accessing DRAM in many modern and emerging applications [49,185,194,374,396]. These applications' memory behavior can differ significantly from more traditional applications since modern applications often have lower memory locality, more irregular access patterns, and larger working sets [4,47,57,104,130,132,161,171,213,296,299,362].…”