|
![](/i/fill.gif) |
Kevin Wampler wrote:
> Only time will tell, but my guess would be language features to help the
> compiler understand how to efficiently run a program in a highly
> parallel or even heterogeneous environment. This has already started to
> a degree as there are now multiple programming languages targeted to GPUs.
>
> It's not clear to me if this will require a major new programming
> paradigm to solve or if it can be shoehorned into existing techniques,
> but it seems like the best bet for what's next. Also, I suspect that
> "everyone starts using pure FP" will not be the way in which this
> happens, although maybe some FP ideas will pay a role.
Most programming languages I've seen tackle parallel programming using
threads, locks and semaphores. These are not exactly ground-breaking
techniques. Over in Haskell land, we have sparks, parallel arrays,
software transactional memory... and also threads and locks if you
prefer. I find all this very exciting.
Parallel arrays in particular look very suitable for the GPU... but
then, how long has Haskell been claiming that running on the GPU is
"just around the corner"? Hasn't happened yet. (Although I think this is
due to lack of manpower rather than anything more fundamental. It seems
there's barely enough people to keep GHC going. But hey, where are you
going to get more people from?)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |