Reviews for paper Like Water and Oil: With a Proper Emulsifier, Query Compilation and Data Parallelism Will Mix Well, submitted to VLDB 2020 (Demo Track).
Overall Rating: Accept
1. Overall Evaluation
Accept
2. Reviewer Confidence
Knowledgeable
3. Summary of the contribution (in a few sentences)
The paper presents a demonstration of DogQC, a query compiler that uses two techniques, i.e., lane refill and push-down parallelism, to counteract divergence effects. In batched processing as is typical for GPUs, divergence effects occur when batches only contain few data due to the selectivity of selections and joins. Apart from an evaluation of the effect of the proposed techniques, the paper also contains a good description of the planned demo.
4. List 3 or more strong points, labelled S1, S2, S3, etc.
S1. Based on (strong) prior work (VLDB 2020)
S2. Good description of the planned demo.
S3. Detailed and well-written description of the approach.
5. List 3 ore more weak points, labelled W1, W2, W3, etc.
W1. The push-down parallelism technique is not described.
W2. The title of the paper does not accurately represent its contents.
6. Detailed evaluation, labelled D1, D2, D3 etc.
D1. While the lane refill technique is described very well and in great detailed, the second technique used by DogQC, i.e., push-down parallelism, is not given that same treatment. As I am not an expert in this field, I am not sure whether this is an oversight or whether that second technique is already well-known and does not need to be described. However, since it keeps being mentioned, but is not described nor part of the demo, I feel something is weird here.
D2. I would strongly recommend to use a more specific title. The current title, while clever and entertaining, literally gives no information about the contents of the paper.
1. Overall Evaluation
Weak Reject
2. Reviewer Confidence
Knowledgeable
3. Summary of the contribution (in a few sentences)
The authors demonstrate DogQC, their experimental query engine that enhances the execution of compiled queries on GPUs by detecting under-utilization of compute resources on the GPU causes by compiled pipelines
4. List 3 or more strong points, labelled S1, S2, S3, etc.
S1: The approach addresses an important problem when executing complex operations (like a compiled pipeline) on GPUs.
S2: Good explanation of what cases the load-balancing issues and how the goals of query compilation (building pipelines that are as long as possible) conflict with the way of how parallelism works on GPUs.
S3: It seems that some of the ideas may be applicable to other resource imbalance problems beyond GPUs
5. List 3 ore more weak points, labelled W1, W2, W3, etc.
W1: There are no screenshots for the demonstration and no video was provided. From the description in Section 3, it seems that the user can control where balancing operators are introduced in the query and then explore performance plots for these variant of the query. I am not sure this will result in an interesting demo.
6. Detailed evaluation, labelled D1, D2, D3 etc.
D1: The description of what will be demonstrated in Section 3 (up to Section 3.1) is too brief. Since there is space, I am not sure why the authors did not show any screenshots.
1. Overall Evaluation
Weak Accept
2. Reviewer Confidence
Knowledgeable
3. Summary of the contribution (in a few sentences)
The authors focus on the underutilisation problem which is met in data processing pipelines inside GPUs. They explain that this problem is caused due to the SIMT execution model of the GPU, which expects that all GPU threads will be executing the same instruction on the data. Accordingly, when some data are filtered out early in the pipeline, the corresponding threads are left without having anything to process. For this reason, the authors have developed a solution to refill the pipeline with data in order to keep the GPU utilisation high.
4. List 3 or more strong points, labelled S1, S2, S3, etc.
S1. Important problem in GPU data processing.
S2. Clearly articulated problem and solution.
S3. Divergence on/off mode will allow users to realise the benefits of the approach easily.
5. List 3 ore more weak points, labelled W1, W2, W3, etc.
W1. In most TPC-H queries, naive and optimized versions of DogQC have similar performance, as shown in Figure 6.
W2. The secondary benefit listed by the authors at the end of Section 4 is poorly justified. There is the reference to the paper, but the demo paper should be self-contained.
W3. The same holds for push-down parallelism.
6. Detailed evaluation, labelled D1, D2, D3 etc.
D1. The demo should be self-contained. As such, W2 and W3 should be described in the paper. The space issues are clear, but they could either remove Figure 6 completely, or just leave the queries where naive and optimized versions of the system are different.
D2. The authors should explain why the performance is not improved in some queries. Even some examples would suffice. It is not useful to include a Figure which is not properly explained and poses more questions than answering.