Reviews for paper Streams on Wires—A Query Compiler for FPGAs, submitted to VLDB 2009.
Overall rating: accept
Accept
No
Medium
Medium
Very good
The paper's main contribution is to take a data base query language and suitably reduce it to a base set of query operations which can be compiled directly to FPGA. Using query operations exposes the opportunity for hardware parallelism in compute intensive database / stream query operations.
S1: Query language abstraction for FPGA compiliation
S2: Analysis of issue rate and latency for the operations and optimizations
S3: Relevance in real world compute intensive application
W1: Comparison against Linux system is weak. More explanation on performance problems would have been good.
W2: It is unclear if the performance gains are due to network DMA bottleneck alone.
W3: The abstract doesn't reveal the problem statement clearly. Instead of summarizing technique please consider commenting on the hardware parallelism of FPGAs and the benefits of reconfigurability in contrast with current many-core architectures.
My only complaint is the treatment given to the Linux system used for comparison. It would be nice if the bottleneck in the system could be explained. The bottleneck is likely to be the number of DMA transfers per unit time. In such a case, it may be a good idea to run the FPGA on data already available in memory. That would remove the doubt that most of the gains in performance seen in comparison with Linux was due to the NIC DMA bottleneck.
It may be a good idea to pitch the advantages of FPGAs in the context of modern CPUs having MBs of cache, in the same section where you give the hardware details of FPGAs (section 3).
Typo, last page, left column, 5th line: Tough
Accept
No
High
Medium
Very good
This paper explores the use of FPGAs to process query streams. The paper is motivated by multicore CPUs with the ideas that some cores might be conventional processors while others might be specialized processors implemented with FPGAs (for example). As a target they look at compiling steaming operators into FPGA circuits.
S1) Very well written, easy to understand paper.
S2) Reader comes away with an excellent understanding of how streaming queries get turned into circulits.
W1) Support for a limited set of stream queries (no joins between streams)
W2) Does it all really matter??? How many streaming applications require being able to handle 100M input tuples/second - or even 1M input tuples/second. Please identify some tuple rates of the most demanding applications
W3) FPGAs are an obvious technique for processing streams of tuples
D1) Section 2. Could you add some text describing what it would take to add support for multiple streams so that the system could do joins. I know you mentioned that as future work but tell us about what additional problems join cause
D2) I really, really liked section 4. I learned a lot. Thanks for doing such a good job on this section.
D3) With software based streaming systems one can share portions of the plans from multiple concurrent queries. Can you do this with an FPGA based solution
Accept
No
Medium
Medium
Adequate
This paper presents the design of a basic compiler, Glacier, for continuous queries implemented on top of an FPGA. Using Glacier's specific building blocks, the paper shows how to map common operators for relational stream processing into FPGA circuits. It also presents several simple optimizations to improve performance. The performance study shows performance results of five basic stream queries.
S1: Using FPGA to expedite stream processing is a worthwhile exercise.
S2: The design of the compiler seems to be based on sufficient knowledge of the FPGA hardware.
W1: The paper does not convince the reader that FPGA can be used to support common stream queries. In particular, joins are not included. It seems that any operator that may use an unpredictable size state, such as holistic aggregates, is left out. Is this a fundamental limitation of FPGA?
W2: The implementation of a sliding window is based on replication. Given window size k and slide size l, the number of replicas n is k/l + 1. This approach has a scalability issues, e.g., when k = 1,000 and l = 1.
W3: The performance study is based on five fixed simple queries. It is hard to tell if the compiler can indeed support all stream queries that involve selections, projections, sliding windows, aggregates, and group by, with different complexities of predicates, windows, etc.
1. The paper does not explain what are the fundamental challenges of using FPGA to support stream queries. Is the design of the the compiler straightforward to anyone familiar with FPGA? Or is there anything novel needed to complete the design?
2. The paragraph on "Holistic Aggregate Functions" is confusing: Is median supported by the current compiler or not?
3. The performance study needs to be significantly extended to try more workloads and in particular, address the question on sliding windows as mentioned above.