Summary Session

Moderator: Mark Horowitz       Scribe: Steve Keckler

[Commentary]   [Research Questions]   [Wishlist]   [Items Needing Consensus]   [Willing to Contribute]   [Goals]   [Promoting Streaming]  

I. Graybeard commentary

A. Jack Dennis

Jack made the case that the functional programming model augmented with stream data types is the right approach for stream programming. First, it provides a formal model of composition which can be used to compose stream kernels into larger programs. Second, functional programming's strong links to mathematics and mathematical structure will enable more sophisticated top-down program analysis, especially those that are more difficult with imperative programming models. Jack sees a great need for analysis of signal processing programs and promise in applying high-level compiler transformations on this application domain. Finally, functional programming provides the benefits of implicit parallelism, which he sees as a good match for the streaming application domain.

His second point focused on determinacy vs. non-determinacy in streaming systems. His definition of determinacy aims at program results - the same output is produced given the same input. While he allows for the possibility non-deterministic behavior encapsulated within module boundaries, it is critical to choose a language and programming model that enables determinism for the sake of debugging.

Commenting on architecture, Jack suggested that the key objective of streaming hardware was to take advantage of the flow of successive data values, and in particular the organized flow of information from storage into the computational elements of the machine. He observed that conventional processors typically lack mechanisms for loading or storing more than a single "word" to memory and suggested that conventional processors could be enhanced with multi-word load/store instructions. Even with conventional cached memory hierarchies, these augmentations could help provide stream-like behavior to conventional processors.

B. Burton Smith

Burton presented his observations on a series of slides, which are available here. Burton observed a collection of recurring themes through the workshop, either as points of agreement or debate:

Burton then posited that the question of what *isn't* streamable is intriguing. Examples included:

Finally, Burton suggested several areas of investigation that deserve further attention:

C. Arvind

Arvind suggested that general purpose languages are too broad and that streaming must define a restricted domain. In addition, the actual target architecture will likely matter a lot (streaming, general purpose, VLIW, FPGA) in how streaming applications are optimized and mapped. As corollaries, he made the following observations:

Consequently, the programming model interface needs serious examination and may require both heterogeneous systems and architectures.

D. Al Oppenheim

As a self-proclaimed "outsider" to the so-called streaming community, Al suggested that a major challenge for the group is to describe to people outside the field, what the field actually is. He gave the example that he could define "signal processing" in a few sentences, but does not think that the group has yet been able to articulate the definition of "stream processing". He also thought that "stream processing" may require some different terminology as people have different pre-conceived notions about the term "stream" outside of this group. He further suggested that when the definition was ready, that an invited lecture at ICASSP would be appropriate (Dally and Horowitz agreed that either of them could do it).

Al also thought that there is a difference between "can it be streamed" and "should it be streamed," and that this area deserved further discussion. Finally, his biggest takeaway from the workshop was his increased excitement about signal processing compilers and opportunities for interesting work in this area, but he wasn't sure if this pertained to streams.

In the ensuing discussion, Saman asked the panel whether they thought that we were about to remake past mistakes. Burton responded with the suggestion that the community be open minded about how to exploit stream-oriented concurrency and locality, as there are probably many ways to solve the problem.

II. Important and open research questions the community should address

III. What do you want someone else to provide to you so that you can make progress in stream processing?

IV. What do we need to agree on to make further progress?

V. What are you willing to contribute....?

Horowitz left this as a hanging question for the group to ponder, but two items were volunteered:

VI. What goals should we set for ourselves to show progress?

VII. What should we do as a community to promote this area, to make the community stronger?