2013
DOI: 10.14778/2536206.2536216
|View full text |Cite
|
Sign up to set email alerts
|

Revisiting co-processing for hash joins on the coupled CPU-GPU architecture

Abstract: Query co-processing on graphics processors (GPUs) has become an effective means to improve the performance of main memory databases. However, the relatively low bandwidth and high latency of the PCI-e bus are usually bottleneck issues for co-processing. Recently, coupled CPU-GPU architectures have received a lot of attention, e.g. AMD APUs with the CPU and the GPU integrated into a single chip. That opens up new opportunities for optimizing query coprocessing. In this paper, we experimentally revisit hash join… Show more

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
3
1
1

Citation Types

0
77
0

Year Published

2014
2014
2020
2020

Publication Types

Select...
4
3

Relationship

1
6

Authors

Journals

citations
Cited by 107 publications
(77 citation statements)
references
References 24 publications
0
77
0
Order By: Relevance
“…Despite the effectiveness of previous studies on query coprocessing on coupled architectures, both CPU and GPU execute homogeneous workloads in previous studies [19,7,38,21]. However, due to the unique architectural design of coupled CPU-GPU architectures, such homogeneous workload distribution schemes can hinder query co-processing performance on the GPU.…”
Section: Introductionmentioning
confidence: 95%
See 1 more Smart Citation
“…Despite the effectiveness of previous studies on query coprocessing on coupled architectures, both CPU and GPU execute homogeneous workloads in previous studies [19,7,38,21]. However, due to the unique architectural design of coupled CPU-GPU architectures, such homogeneous workload distribution schemes can hinder query co-processing performance on the GPU.…”
Section: Introductionmentioning
confidence: 95%
“…Coupled CPU-GPU architectures call for new data processing mechanisms. There have been studies on more collaborative and fine-grained schemes for query co-processing [19,38] and other data processing workloads (e.g., key-value stores [21] and MapReduce [7]). …”
Section: Introductionmentioning
confidence: 99%
“…Since this survey should cover relational GDBMS, we only consider systems that are capable of using the GPU for most relational operations. That is, we disregard stand-alone approaches for accelerating a certain relational operator (e.g., He and others [30,32]), special co-processing techniques (e.g., Pirk and others [49]), or other -non data-processing related -applications for GPUs in database systems [33]. Furthermore, we will not discuss systems using other data models than the relational model, such as graph databases (e.g., Medusa from Zhong and He [64,65]) or MapReduce (e.g., Mars from He and others [28]).…”
Section: Research Questionsmentioning
confidence: 99%
“…Access structures and algorithms for the GPU: In order to support GPUacceleration, a DBMS needs to implement access structures on the GPU (e.g., columns or B + -trees) and operators that work on them. Here, the most approaches were developed [7,21,29,32,48,49]. Data Placement Strategy: A DBMS needs to keep track of which data is stored on the GPU, and which access structure needs to be transferred to GPU memory [29].…”
Section: Summary: Extension Points For Main-memory Dbmssmentioning
confidence: 99%
See 1 more Smart Citation