Morsel- Drive Parallelism: A NUMA- Aware Query Evaluation Framework for the Many- Core Age. Presented by Dennis Grishin

Transcription

1 Morsel- Drive Parallelism: A NUMA- Aware Query Evaluation Framework for the Many- Core Age Presented by Dennis Grishin

2 What is the problem? Efficient computation requires distribution of processing between many cores and associated memory.

3 Why is it important? Rise of the multi- core CPU architecture Rise of the NUMA architecture Uniform Memory Access (UMA) Non- Uniform Memory Access (NUMA)

4 Why is it hard? How to distribute work evenly between many out- of- order cores? How to maximize NUMA- local execution?

5 Why existing solutions do not work? Plan- driven parallelism: query fragmentation at compile time into big fragments and initiation of static number of threads Insufficient load- balancing due hard- to- predict performance of out- of- order CPUs.

6 What is the core intuition of the solution? Morsel- driven parallelism: query fragmentation at runtime into small fragments and dynamic scheduling of threads Runtime scheduling is elastic and achieves perfect load- balancing.

7 Solution I three- way join select * from R, S, T where R.A = S.A and S.B = T.B Z a Z b Result A 16 A 27 B 8 B 10 C v C y store store HT(T) B C v x y z u Dispatcher probe(8) probe(10) HT(S) A B Figure 1: Idea of morsel-driven parallelism: 5 23 morsel morsel probe(16) probe(27) R A Z 16 a 7 c 10 i 27 b 18 e 5 j 7 d 5 f

8 Solution II build- phase NUMA- aware hash table creation Phase 1: process T morsel-wise and store NUMA-locally Phase 2: scan NUMA-local storage area and insert pointers into HT scan next morsel Storage area of red core v (T) HT(T) global Hash Table Storage area of green core v(t) morsel T v(t) Insert the pointer into HT Storage area of blue core scan Table partitioning on the join key - > matching tuples usually on the same socket - > less cross- socket communication for joins hashtable bit tag for early filtering f d 48 bit pointer Tagging of hash bucket lists reduces - > list traversal skipped - > number of cash misses reduced to 1 e

9 Solution III probe- phase Morsel- wise probing Storage area of blue core HT(T) HT(S) Storage area of green core Storage area of red core v (R) v(r) v(r) next morsel morsel R

10 Solution III - dispatcher Dispatcher Code Lock-free Data Structures of Dispatcher List of pending pipeline-jobs (possibly belonging to different queries) Pipeline- Job J 1 M g1 M b1 Pipeline- Job J 2 Dispatcher implemented as a lock free data structure and executed by work requesting threads dispatch(0) DRAM DRAM (J 1, M r1 ) Socket Pipeline-Job J 1 on morsel M r1 on (red) socket of Core0 Core0 Core Core Core Core Core Core Core Core8 Core Core Core Core Core Core Core Socket M r1 M r2 M r3 M g2 M g3 M b2 M b3 (virtual) lists of morsels to be processed (colors indicates on what socket/core the morsel is located) inter Core Core Core Core Core Core Core Core connect Socket Core Core Core Core Core Core Core Core Socket DRAM DRAM Maintains a list of pending pipeline jobs whose prerequisites have already been processed Segmentation of queries upon request by processing thread NUMA- locality awareness Work stealing if necessary

11 Solution IV morsel size Execution time dependency on morsel size time [s] Morsels should be large enough to amortize scheduling overhead while providing a good response time K 10K 100K 1M 10M morsel size

12 Experiment results I - speedup Processing of 22 TPC- H queries

13 Experiment results II - elasticity Intra- and inter- query parallelism Morsel- wise processing

14 Does the paper prove its claims? Yes.

15 Are there any gaps in the logic? Can the compilation at runtime cause a significant overhead? What is the overhead caused by the dispatcher in morsel- driven parallelism? Can all types of queries be easily broken into morsels?

16 Possible next steps? Priority based scheduling. Hardware specific optimization. Real world testing.