[Open-graphics] Center for High-Performance Reconfigurable Computing

[Timothy Miller]

On 10/15/06, Nick S-A <nova at macintoshclub.com> wrote:

> I have thought a lot about this problem, and it seems to me that the
> best solutions are to use one of the following:
> 1) Best, use a purely functional language. Haskell is the most common
> of these, and you could probably force a Lisp dialect into this mold.

Yes and no.  For one thing, I thing most supercomputing code is in C
and Fortran.  Avoid making people learn a new language.

Secondly, what I'm describing does not behave in a functional way.
More like IPC.  You explicitly send messages to another process, and
then later get messages back.

There are models of functional programming that juggle multiple
continuations, and we could look into that.  But we're not trying to
solve the multithreading problem here.  We're trying to convert
functions to hardware, and exposing some of the underlying semantics
is an okay thing to do.

> 2) Use stream programming, as in BrookGPU. This leads to C-like code,
> but has the advantage of running really fast. It does have a few
> restrictions, but BrookGPU is based on OpenGL, which basically means
> we just need to support the right subset of OpenGL and we have
> distributed computing for free.

This sounds good.  But I'm trying to not make people learn a new
language.  Just apply stylistic constraints to an exising one.  But
there are other ways of going about it.

> 3) Use nasty semaphore/lock based code, except with Software
> Transactional Memory (http://en.wikipedia.org/wiki/
> Software_Transactional_Memory) so that you can actually write code
> that does stuff instead of just writing code to prevent locks.

The model I was thinking about doesn't require explicit locks because
it uses a message-passing metaphor.

> Purely functional languages are the best option because a) they exist
> today in concurrent form,

Ok, if you can do a concurrent thing, that's what we need.

> b) they often have good exemplatory
> materials (e.g. A Gentle Introduction to Haskell), and c) while they
> are a different methodology than imperative languages like C, they do
> not have restrictions like BrookGPU.

To learn a new language, the performance gain would have to be very serious.

> I suggest we should support a portion of OpenGL that allows BrookGPU
> to run fully in Hardware, and later on write some sort of functional
> language to support the chips. Once that is done, we can attempt a
> Software Transactional Memory based C-like language, or something
> along those lines.

I'm skipping the GPU entirely and proposing that we convert to FPGA logic.