On 10/15/06, Nick S-A <[EMAIL PROTECTED]> 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. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
