Parallelism: The future of programming
“Darren Hobbs has written an interesting article”:http://www.darrenhobbs.com/archives/2006/10/the_paradigm_sh.html on what he sees as the future of programming.
bq. The future is about making things smaller and having more of them. We’re moving from a world where clock speed doubled every 18 months to one where cores will double every 18 months. Dual core CPUs are commonplace. Quad core is just around the corner. In 5 years time 16 or 32 core chips will be in your desktop.
This means that we as programmers are going to need to master concurrent programming and to do that we need new tools, new ideas, and a new way of expressing and understanding concurrent programming.
bq. [Make] it [parallelism] easy for application developers to leverage all those cores to win tomorrow’s market. Threads (ie. Java and C# threads) are old technology, and a dreadful way of expressing concurrency. Language constructs such as “CSP(Communicating Sequential Processes)”:http://doi.acm.org/10.1145/359576.359585 (see also: the “book”:http://www.usingcsp.com/cspbook.pdf and “wikipedia”:http://en.wikipedia.org/wiki/Communicating_sequential_processes) that allow developers to explicitly describe concurrency are far easier to understand and reason about.
You might be interested in our approach to concurrency and coordination. The primary aim of our technology is to simplify the writing of scaleable, resilient, concurrent/distributed software solutions especially in the case of irregular concurrency. It would appear to us that the majority (if not all) of the other programming tools available seem to target ‘data parallel’ applications. We believe that we are the only provider of a solution that is effective for both regular and irregular concurrency.
We have not implemented a DSL in an ‘application related’ sense as we regard the area of concurrency as the domain we are interested in. It has been our intent to seperate the communications aspects of the solution from the algorithmic/processing aspects of the solution (similar to a co-ordination language). However, we extend the toolset to allow the developer to describe his/her solution using a graphical editor to create something similar to an electronic circuit; this will then be translated to the target language (currently C++). The developer will then be able to write the processing/algorithmic code without any knowledge of the threading/locking/synchronisation issues that writing ‘thread-aware’ code would entail.
We have a runtime which allows the solution to run on a number of OS’es without any changes, and, to run on any hardware topology without any changes (single process on one or more CPU’s (SMP), on shared memory multiprocessors (AMP), and/or heterogeneous networks of these platform types). This ‘hardware independent’ approach facilitates the development of the solution on, say, a desktop PC and allows the choice of hardware to deferred until closer to time of deployment. Hope this interests you from at least from a technological point of view.
It looks and sounds interesting. Let me know when you have a Java implementation.