Hardware-Conscious Hash-Joins on GPUs

Sioulas, Panagiotis; Chrysogelos, Periklis; Karpathiotakis, Manos; Appuswamy, Raja; Ailamaki, Anastasia

doi:10.1109/icde.2019.00068

Cited by 41 publications

(40 citation statements)

References 13 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…GPU/FPGA-based acceleration of database systems is another line of research that allows improving database performance by using alternative computing devices to powerhungry processors. [9,42,45] present techniques on using GPUs for accelerating analytical processing queries such as hash join. Kim et al [24] have proposed a transaction processing engine architecture that exploits the wide-parallelism.…”

Section: Lessons Learnedmentioning

confidence: 99%

Micro-architectural analysis of in-memory OLTP: Revisited

et al. 2021

Self Cite

View full text Add to dashboard Cite

Micro-architectural behavior of traditional disk-based online transaction processing (OLTP) systems has been investigated extensively over the past couple of decades. Results show that traditional OLTP systems mostly under-utilize the available micro-architectural resources. In-memory OLTP systems, on the other hand, process all the data in main-memory and, therefore, can omit the buffer pool. Furthermore, they usually adopt more lightweight concurrency control mechanisms, cache-conscious data structures, and cleaner codebases since they are usually designed from scratch. Hence, we expect significant differences in micro-architectural behavior when running OLTP on platforms optimized for in-memory processing as opposed to disk-based database systems. In particular, we expect that in-memory systems exploit micro-architectural features such as instruction and data caches significantly better than disk-based systems. This paper sheds light on the micro-architectural behavior of in-memory database systems by analyzing and contrasting it to the behavior of disk-based systems when running OLTP workloads. The results show that, despite all the design changes, in-memory OLTP exhibits very similar micro-architectural behavior to disk-based OLTP: more than half of the execution time goes to memory stalls where instruction cache misses or the long-latency data misses from the last-level cache (LLC) are the dominant factors in the overall execution time. Even though ground-up designed in-memory systems can eliminate the instruction cache misses, the reduction in instruction stalls amplifies the impact of LLC data misses. As a result, only 30% of the CPU cycles are used to retire instructions, and 70% of the CPU cycles are wasted to stalls for both traditional disk-based and new generation in-memory OLTP.

show abstract

Section: Lessons Learnedmentioning

confidence: 99%

Micro-architectural analysis of in-memory OLTP: Revisited

et al. 2021

Self Cite

View full text Add to dashboard Cite

show abstract

“…Results are then shipped back to the CPU. Researchers have worked on optimizing various database operations under the co-processor model: selection [40], join [18,19,22,34,38,39,47], and sort [16,42]. Several fullfledged GPU-as-coprocessor database query engines have been proposed in recent years.…”

Section: Query Execution On Gpumentioning

confidence: 99%

“…Partitioned hash joins use a partitioning routine like radix partitioning to partition the input relations into cache-sized chunks and in the second step run the join on the corresponding partitions. Efficient radix-based hash join algorithms (radix join) have been proposed for CPUs [9][10][11]14] and for the GPUs [34,38]. Radix join requires the entire input to be available before the join starts and as a result intermediate join results cannot be pipelined.…”

Section: Kbmentioning

confidence: 99%

A Study of the Fundamental Performance Characteristics of GPUs and CPUs for Database Analytics

Shanbhag

Madden

2020

Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data

View full text Add to dashboard Cite

There has been significant amount of excitement and recent work on GPU-based database systems. Previous work has claimed that these systems can perform orders of magnitude better than CPU-based database systems on analytical workloads such as those found in decision support and business intelligence applications. A hardware expert would view these claims with suspicion. Given the general notion that database operators are memory-bandwidth bound, one would expect the maximum gain to be roughly equal to the ratio of the memory bandwidth of GPU to that of CPU. In this paper, we adopt a model-based approach to understand when and why the performance gains of running queries on GPUs vs on CPUs vary from the bandwidth ratio (which is roughly 16× on modern hardware). We propose Crystal, a library of parallel routines that can be combined together to run full SQL queries on a GPU with minimal materialization overhead. We implement individual query operators to show that while the speedups for selection, projection, and sorts are near the bandwidth ratio, joins achieve less speedup due to differences in hardware capabilities. Interestingly, we show on a popular analytical workload that full query performance gain from running on GPU exceeds the bandwidth ratio despite individual operators having speedup less than bandwidth ratio, as a result of limitations of vectorizing chained operators on CPUs, resulting in a 25× speedup for GPUs over CPUs on the benchmark.

show abstract

“…Following this, Kaldewey et al [11] designed a system that takes advantage of the UVA feature. Later, with the introduction of separate streams for data transfer and computation by GPU vendors, database systems adopted overlapping of data transfer and computation to minimize the impact of the data transfer overhead on the overall query execution [12,129]. More recently, there have also been attempts…”

Section: Data Storage and Data Accessmentioning

confidence: 99%

“…Operator level optimizations attempt to improve the performance of individual database operators on single or multiple GPUs. In this regard, significant effort has been put into optimizing compute and memory intensive operators like join [10][11][12], aggregation [13][14][15][16] and sort [17][18][19][20]. A variant of the join operation, partitioned hash join, has especially received significant attention from the research community [10,12,21].…”

Section: Chapter 1 Introductionmentioning

confidence: 99%

In-memory analytical query processing on GPUs

Paul¹

View full text Add to dashboard Cite

The high global memory bandwidth and the large number of parallel cores available in modern Graphics Processing Units (GPUs) make them ideal for highperformance Online Analytical Processing (OLAP) systems. However, it is challenging to design efficient high-performance query processing systems for GPUs due to the following reasons: 1) the rapid evolution of GPU hardware in the last decade, 2) the significant differences in the hardware architecture of GPUs when compared to CPUs, 3) the high overhead of moving the data between the CPU and GPU and 4) the small global memory size of a single GPU that necessitates the access of remote data over PCIe or NVLink interconnects when processing large data sets. In this thesis, we study existing query processing systems for GPUs and propose techniques to improve query execution efficiency on GPUs.We begin by studying the performance of hash join, which is one of the most compute and memory intensive relational operator in OLAP systems. Specifically, we first revisit the major GPU hash join implementations in the past decade that were designed to execute on a single GPU. We then detail how these implementations take advantage of different GPU architecture features and conduct a comprehensive evaluation of their performance and cost-efficiency using different generations of GPUs. This helps shed light on the impact of different GPU architecture features on the performance of the hash join operation and identify the factors guiding the choice of these features. We further study how data characteristics like skew and match rate impact the performance of GPU hash join implementations. Novel techniques to improve the performance of the hash join operation when joining input relations with severe skew or high match rate were also proposed as part of this study. Our evaluation finds that the proposed techniques help avoid any performance degradation when joining skewed input relations and achieve up to 2.5x better performance when joining input relations with high match rate.Next, we extend our study on the hash join operation to modern multi-GPU architectures. The recent scale-up of GPU hardware through the integration of multiple xi Contentsxii GPUs into a single machine and the introduction of higher bandwidth interconnects like NVLink 2.0 has enabled new opportunities of relational query processing on multiple GPUs. However, due to the unique characteristics of GPUs and the interconnects, existing hash join implementations spend up to 66% of their execution time moving the data between the GPUs and achieve lower than 50% utilization of the newer high bandwidth interconnects. This leads to extremely poor scalablity of hash join performance on multiple GPUs, which can be slower than the performance on a single GPU. In this thesis, we propose MG-Join, a scalable partitioned hash join implementation on multiple GPUs of a single machine. In order to effectively improve the bandwidth utilization, we develop a novel multi-hop routing for cross-GPU communication that adaptively chooses...

show abstract

Hardware-Conscious Hash-Joins on GPUs

Cited by 41 publications

References 13 publications

Micro-architectural analysis of in-memory OLTP: Revisited

Micro-architectural analysis of in-memory OLTP: Revisited

A Study of the Fundamental Performance Characteristics of GPUs and CPUs for Database Analytics

In-memory analytical query processing on GPUs

Contact Info

Product

Resources

About