Gpu Join Presentation
-
Upload
mansu -
Category
Technology
-
view
2.812 -
download
1
description
Transcript of Gpu Join Presentation
Relational Joins on Graphics Processors
Suman KarumuriJamie Jablin
Background
Introduction
• Utilizing hardware features of the GPU– Massive thread parallelism– Fast inter-processor communication– High memory bandwidth– Coalesced access
Relational Joins
• Non-indexed nested-loop join (NINLJ)• Indexed nested-loop join (INLJ)• Sort-merge join (SMJ)• Hash join (HJ)
Block Non-indexed nested-loop join (NINLJ)
foreach r in R: foreach s in S:
if condition(r,s) output = <r,s>
Block Indexed nested-loop join (INLJ)
foreach r in R: if S[].has(r.f1)
if condition(r,s) output = <r,s>
Hash join (HJ)
Hr = Hashtable()foreach r in R:Hr.add(r) if Hr.size() == MAX_MEMORY:
for s in S:if Hr(s):
output sHr.clear()
Sort-merge join (SMJ)Sort(R), Sort(S) ; i, j = 0while !R.empty() && !S.empty():
if (R[i] == S[j])output += R[i]
i++ ; j++elif (R[i] < S[j])
i++else
j++
Algorithms on GPU
• Tips for algorithm design– Use the inherent concurrency.– Keep SIMD nature in mind. – Algorithms should be side-effect free.– Memory properties:
• High memory bandwidth.• Coalesced access (for spatial locality)• Cache in local memory (for temporal locality)• Access memory via indices and offsets.
GPU Primitives
Design and Implementation
• A complete set of parallel primitives:– Map, scatter, gather, prefix scan, split, and
sort• Low synchronization overhead.• Scalable to hundreds of processors.• Applicable to joins as well as other relational query
operators.
Map
Scatter
• Indexed writes to a relation.
Gather
• Performs indexed reads from a relation.
Prefix Scan• A prefix scan applies a binary operator on the input
of size n and produces an output of size n.• Ex: Prefix sum: cumulative sum of all elements to
the left of the current element.– Exclusive (used in paper)– Inclusive
Split
Each thread constructs tHist from Rin
L[(p-1)*#thread+t]=
tHist[t][p]
Prefix sum L(i) = sum(L[0…i-1])
Gives the start location of partitions
tOffset[t][p]=
L[(p-1)*#thread+t]
Scatter tuples to Rout based on offset.
Sort
• Bitonic sort– Uses sorting networks, O(N log2N).
• Quick sort– partition using a random pivot until partition fits in
local memory– Sort each partition using bitonic sort.– Partioning can be parallelized using split.– Complexity is O(N logN).– 30% faster than bitonic sort in experiments– Use Quick sort for sorting
Spatial and Temporal locality
Memory Optimizations
• Coalesced memory improves memory bandwidth utilization (spatial locality)
Local Memory Optimization
• Quick sort– Temporal locality– Use the bitonic sort to sort each chunk after
the partitioning step.
Joins on GPGPU
NINLJ on GPU
• Block nested• Uses Map primitive on both relations
– Partition R into R’ and S into S’ blocks respectively.
– Create R’ x S’ thread groups– A thread in a thread group processes one
tuple from R’ and matches all tuples from S’.– All tuples in S’ are in local cache.
B+ Tree vs CSS Tree
• B+ tree imposes – Memory stalls when traversed (no spatial locality)– Can’t perform multiple searches ( loses temporal
locality).• CSS-Tree (Cache optimized search tree)
– One dimensional array where nodes are indexed.– Replaces traversal with computation.– Can also perform parallel key lookups.
Indexed Nested Loop Join (INLP)
• Uses Map primitive on outer relation• Uses CSS tree for index.• For each block in outer relation R
– Start with a root node to find the next level• Binary search is shown to be better than sequential search.
– Go down until you find the data node.• Upper level nodes are cached in local memory
since they are frequently accessed.
Sort Merge Join
• Sort the relations R, S using the sort primitive• Merge phase
– Break S into chunks (s’) of size M.– Find first and last key values of each chunk in s’ and
partition R into those many chunks.– Merge all chunks in parallel using map
• Each thread group handles a pair• Each thread compares 1 tuple in R with s’ using binary
search.
• Chunk size is chosen to fit in local memory.
Hash Join
• Uses split primitive on both relations• Developed a parallel version of radix hash join
– Partitioning• Split R and S into the same number of partitions, so S
partitions fit into the local memory
– Matching• Choose smaller one of R and S partitions as inner partition to
be loaded into local memory• Larger relation will be used as the outer relation• Each tuple from outer relation uses a search on the inner
relation for matching.
Lock-Free Scheme for Result Output
• Problems– Unknown join result size. Max size of joins
doesn’t fit in memory.– Concurrent writes are not atomic.
Lock-Free Scheme for Result Output
• Solution: Three-phase scheme– Each thread counts the number of join results.– Compute a prefix sum on the counts to get an
array of write locations and the total number of results generated by the join.
– Host code allocates memory on device.– Run join again with outputs.
• Run joins twice. That’s ok, GPU’s are fast.
Experimental Results
Hardware Configuration
• Theoretical Memory bandwidth – GPU: 86.4 GB/s– CPU: 10.4 GB/s
• Practical Memory bandwidth – GPU: 69.2 GB/s– CPU: 5.6 GB/s
Workload• R and S tables with 2 integer columns.• SELECT R.rid, S.rid FROM R, S WHERE <predicate>• SELECT R.rid, S.rid FROM R, S WHERE R.rid=S.rid• SELECT R.rid, S.rid FROM R, S WHERE
R.rid<=S.rid<=R.rid + k• Tested on all combinations:
– Fix R, Vary S. All values uniform distribution. |R| = 1M– Performance impact varying join selectivity. |R| = |S| = 16M– Non – uniform distribution of data sizes and also varying join
selectivity. |R| = |S| = 16M• Also tested with columns as strings.
Implementation Details on CPU
• Highly optimized primitives and join algorithms matching hardware architecture
• Tuned for cache performance.• Compiled programs using MSVC 8.0 with
full optimizations.• Used openMP for threading mechanisms.• 2-6X faster than their sequential counter
parts.
Implementation Details on GPU
• CUDA parameters– Number of thread groups (128)– Number of threads for each thread group (64)– Block size is 4MB (main memory to device
memory)
Memory Optimizations Work
Works when join selectivity is varied
Better than in-memory database
CUDA vs. DirectX10
• DirectX10 is difficult to program, because the data is stored as textures.
• NINLJ and INLJ have similar performance.• HJ and SMJ are slower because of texture
decoding.• Summary: low level primitives on GPGPU
are better than graphics primitives on GPU.
Criticisms
• Applications of skew handling are unclear.• Primitives are sufficient to implement the
given joins, but they do not prove the set of primitives to be minimal.
Limitations and future research directions
• Lack of synchronization mechanisms for handling read/write conflicts on GPU.
• More primitives.• More open GPGPU hardware spec for
optimizations.• Power consumption on GPU.• Lack of support for complex data types.• On GPU in-memory database.• Automatic detection of thread groups and
number of threads using program analysis techniques.
Conclusion
• GPU-based primitives and join algorithms achieve a speedup of 2-27X over optimized CPU-based counterparts.
• NINLJ, 7.0X; INLJ, 6.1X; SMJ, 2.4X; HJ, 1.9X
Refrerences
• Scan Primitives for GPU Computing, Sengupta et al
• wikipedia.org• monetdb.cwi.nl
Thank You.
Scan Primitives for GPU Computing, Sengupta et al
Skew Handling
• Skew in data results in an imbalanced partition size in partitioned-based algorithms (SMJ and HJ)
• Solution– Identify partitions that do not fit into the local
memory– Decompose partitions into multiple chunks the
size of local memory
Implementation Details on GPU
• CUDA parameters– Number of threads for each thread group– Number of thread groups
• DirectX10– Join algorithms implemented using
programmable pipeline• Vertex shader, geometry shader, and pixel shader