Home » Forums » Programming
weiqing
Posts: 1
 Joined: 2007-09-17

Hi,
I am very interested in the stream programming model and compilation. I played with the StreamC/KernelC programming whose backend is on Imagine. Unfortunately, I think the programming model has many drawbacks, such as the encapsulation granularity of the StreamC is too coarse, the programmer can not explicitly control the transfer of streams between the off-chip memory and the SRF, it is implicitly in the kernel call, then the programmer can not fully exploit the prefetching and data reuse potencial exposed in the stream architecture. Also I found the StreamC/KernelC compiler has many bugs, I want very much to take part in helping developing it, but it seems to be wrapped up. I also surveyed the Brook(BrookGPU), Streamit and SVM(Stream Virtual Machine). SVM seems to be a good compiler infrastructure for Imagine alike architecture, but its abstract is not so sommon, such as, it only includes 3 level memory hierarchy.Recently I found the Sequoia project. I think it is a good idea to model the explicitly managed memory hierarchies as trees. Now here is my questions,

1. From the SC'06 paper, it seems that only leaf nodes is permitted to take part in computation, inner nodes are only responsible for data transfer and blocking. Could any program be organized into such algorithm? It seems to be difficult for some complicated control flow. And what about if the inner node could and need take part in computation?

2. Have you replaced the Brook with Sequoia?

3. Is there any possibility for me to take part in the development of the Sequoia?

‹ sgemv example

Submitted by weiqing on September 18, 2007 - 5:33pm. login or register to post comments | printer friendly version

mhouston
Posts: 30
 Joined: 2006-08-11
Administrator

1) Complex control flow can be a problem. However, it is possible to return scalar information up to inner tasks to make control decisions. Computation can be done in the inner tasks, but that may not be portable. The compiler will generate a mapping error when map fails. In general, for portability, you want computation to occur at the leafs.

2) We do not currently have GPU backends for Sequoia, but development efforts at Stanford have shifted from Brook to Sequoia. It is possible to write a backend for Sequoia, in fact you could use most of Brook to do that, but both AMD and Nvidia have their own custom systems now for GPGPU.

3) The runtime system is almost ready to be made public. You can hack at that to add more systems as the interface is simple. We can make the compiler available, but the learning curve is quite steep. We are hoping to get the compiler documented as best as possible and release source by the end of the year. If you need the compiler for immediate research, we can make it available to you, but since it is still a research effort on our end, we currently do not plan on providing checkin permissions outside out our group.


September 21, 2007 - 11:15am login or register to post comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.