Design Article
2028: Concurrent processing--from revolution to legacy
David May, CTO and Cofounder of XMOS
11/6/2008 4:00 PM EST
![]() |
| November 2028 is the 40th anniversary of ESD. Click here read other 2028 lookbacks. |
It's now almost 20 years since the emergence of components designed to enable system design using concurrent communicating processes--an idea that actually originated 50 years ago with the publication of C. A. R. Hoare's article "Communicating Sequential Processes" (Communications of the ACM 21 [8]) and the formation of Inmos with its transputer concept.
These system components enabled a revolution in electronic design alongside a revolution in programming. For the first time, the artificial distinction between hardware and software design was eliminated. Today we teach both engineers and computer scientists to design systems in terms of communicating concurrent processes and that we synthesize hardware from the same languages we use for programming.
Two decades ago, it was already becoming clear that using more, smaller, slower processors made system design easier and improved power-efficiency.
And by making processing event-driven--inherent in message-passing concurrency--further gains in energy were achieved by switching off components when they had nothing to do.
Highly responsive systems became easy to build and scale by dedicating processors to specific tasks; high data throughputs were supported by processor pipelines and scaled by using many concurrent channels; high processing throughput was achieved by composing systems with many processors.
Over the last 20 years, this technology has produced miracles and shows every sign of continuing to do so. Multicore chips have enabled the number of processors in a system to be scaled up and costs to fall in line with the long-term trend that has seen a factor-of-two improvement in the performance-per-cost ratio every one to two years.




BobKlein999
11/13/2008 12:07 PM EST
The future David May describes is already happening. Ambric, Inc. offers massively-parallel array processor (MPPA) devices with up to 336 RISC/DSP processors in a single device (a next-gen device w/ > 600 processors is on the way.) Each processor has its own, local memory and communicates via configurable channels -- just as David describes. In this way, the processors are "encapsulated"; small blocks of code execute autonomously and communicate only through self-synchonizing channels -- allowing large applications to be quickly developed, debugged, and tested piece-meal. The pieces are then easily assembled (connected) via channels. This eliminates the tedious, time-consuming timing closure step associated with conventional FPGAs and ASICs, as well as the multi-level cache management and cache coherency issues associated with other parallel processor / multi-core architectures. See: www.ambric.com
Sign in to Reply
gheorghe
11/16/2008 3:26 PM EST
The Future in Software for 2000 Years
M# -- Universal Programming Language of the Informational Space based on an informational entity called the Informational Individual.
M# language is not a combination of current languages. This is a very power alternative vision to the current software model.
The goal of these words is to show you a new conceptual approach in software, on a new model inspired from the real world and having the same stability as the real world: The Informational Individual!
I talk about a new kind of thinking in software, a new context of work and a new perspective, from now forever!
The Informational Individual opens a new universe! This is limited only of our thinking, of our imagination, of our intuition, of our desire.
There is no limit!!
The multi-core is not the solution. We are thinking as in the current model of programming. Here is the mistake. For the future we will work on a new software model -- the Informational Individual! The processor will build on a structure and functionality of Informational Individual not a C++ language. Now we are thinking as in 1970. Now the problems are in the kind of thinking in software. Here is the barrier.
You can see www.gheorghematei.blogspot.com
Sign in to Reply
Eric Verhulst_Altreonic
1/4/2012 5:45 PM EST
Software is really modeling and the real or virtual world we model can best be described in terms of interacting entities. It's universal and it can model almost any system.
We share with David May the formalism that could handle this first, i.e. CSP. It's actually simple. At the local level, you have (sequential) statemachines just like our von Neuman processors operate, even when they are "multicore". At the system level, you have interconnected statemachines. Rather than trying to extrapolate the von Neuman paradigm to the system level, you have to do it the other way around. Make the von Neuman machines look like a sea of concurrent and interacting entities in the software itself.
The result can be seen in the OpenComRTOS implementation, a single approach for many-multi-parallel-distributed systems. Scalable and platform independent in just 5 KB/node. This implementation uses C, but it can be done in any language (there is a prototype in python).
Benefits: you get real portability, real scalability, real orthogonality, real real-time, etc. See www.altreonic.com
Sign in to Reply