Netcentric View:

By Bernard Cole
iApplianceWeb
(10/14/01, 3:10:54 AM GMT)

"Sun is only partly right with its marketing slogan 'The Network Is The Computer,'" a software developer remarked to me at a recent conference. "What I think is more true is that the network is a dataflow processor, and that's what will fundamentally change the computer industry at all levels and in all segments."

His comment got me thinking about what architectural model will be in the mainstream of net-centric computing in the future. It also got me thinking about issues related to sequential versus parallel programming and whether or not we can transition to the latter, if necessary, and if so, how. Will the shift be relatively seamless, through some extension of today's C/C++/Java languages, or will it require that we learn totally new programming languages and techniques?

In some segments of the computer industry, servers, routers and switches, for example, it is literally true that "the network is a dataflow processor." In other segments, such as PCs and information appliances, the infrastructure and architectures will remain the same, but the way in which we use them and the software we use will change from processing information to mainly moving it in and out, from here to there.

While not fitting the specific definition of dataflow, we are making the change from using our personal computer as an isolated word or database processor with occasional connection to using it as a data mover. Now, on a PC, we spend a substantial part of our time sending e-mails (moving data out) and receiving e-mails and Web pages (moving data in). In the new breed of Internet-enabled information appliances, e-mail and Web access are all there is, except for an occasional game.

A data flow processor, according to one description I have read, generally consists of many processors operating as a single multiprocessor array, using a packet routing network to connect any processor to any other, and memory array units for holding large databases of information.

This definition is remarkably similar to how the new generation of embedded and highly deterministic network processors is deployed in many of the new switches and routers required by the 1-100 gigabit/s optical fiber networks. It is also similar to the server clusters and server area networks made possible by the gigabit/s plus data rates of switched fabric and point-to-point to interconnection schemes such as Infiniband and SCSI over IP (iSCSI). As the backbone of the Internet shifts to terabit/s bandwidths, it's likely that dataflow multiprocessors based on cooperating nodes on this high-bandwidth inter-network will become more common.

Computer system architects tell me that the emergence of the dataflow and other parallel computing architectures into the mainstream is apt to present problems to programmers trained on the concurrency models and languages used on the traditional Von Neumann-based CPUs.

Unlike the control flow environments of existing mainstream processors where the focus of execution is determined by instruction pointers that identify the operation to be performed next, the operations of a dataflow machine are determined by the availability of the data needed for these actions. Computations are expressed and executed in dataflow terms determined by the arrival of data.

The difficulty programmers will face has to do with the concurrency models used on most conventional processor architectures. Although the performance and architectural enhancements of embedded and desktop processors have advanced significantly over the past decade, the concurrency models used in most of their operating systems have not. The concurrency models were conceived when multitasking was expensive and programmers had to use threads sparingly. In virtually every OS I know about, threads are associated with one of two things: specific pieces of code, or with instances of large objects. The result is software with many threads that are interdependent and which spend a lot of time waiting on each other.

The problem for programmers is that the dataflow environments found in routers and switches using network processors are event driven, deterministic and real-time to a degree that would give most embedded developers nightmares, full of asynchronous and concurrent interactions.

However, the programming languages and techniques in common use now, and the code that results, are sequential. Developers writing in C and C++, for example, must take highly parallel operations and convert them all into a sequential series of statements: functions, call backs, control blocks, data structures, and linked lists. Not only is this process excruciatingly time consuming, the resulting code doesn't use computing resources efficiently, to the detriment of the overall throughput of the system.

The options open to developers in dataflow-based net-centric computing environment are to (1) accept inefficiencies and try to make up the difference in faster processors, memory and interconnect; or (2) switch to programming languages based on alternative concurrency models.

There are any number of specialized programming languages developed for specific dataflow and parallel computing architectures: the Value-oriented Algorithmic Language (VAL); the Streams and Iteration in a single Assignment Language (SISAL); and the Irvine Dataflow language (Id). A language that has received attention and seems to be architecture-independent is Linda, which allows the easy development of parallel code using a manager-worker model. Also, a number of data parallel extensions have been proposed for languages such as Fortran, Modula 2, and fortunately for all of us, C.

But all of these approaches require significant investment in developing the appropriate compiler technology. Two alternatives that seem likely possibilities and that would not require a difficult transition for developers are: (1) an approach called Single Program, Multiple Data (SPMD); and (2) a standard message-passing library called MPI developed in the early '90s. The first is a low-level approach based on message passing to generate parallel programs with processes that can be mapped to the CPUs of a single parallel computer, such as in an Infiniband-based server, or that maybe distributed across a network. The second is a library of more than 125 functions that can be called from C programs to execute parallel operations.

There may be other, much simpler alternatives I'm not familiar with. If so, I would like to hear about them.

Bernard Cole is site leader and editor of iApplianceweb and an independent high technology editorial services consultant. He welcomes your feedback. Call him at 602-288-7257 or send an email to bccole@acm.org.