Think parallel

7.6 Think parallel

There is an old joke in the computer world that goes something like this: If one woman can have a baby in nine months, does that mean that nine women can have a baby in one month? The obvious implication here is that certain tasks must be performed serially due to nature. No attempts to make the process run in parallel will make the result appear any faster.

Motherhood aside, there are many processes in the world today that can be and are done in parallel. Construction work crews, television production teams, and professional basketball teams are all examples of entities that must operate in parallel. To meet their goals, they function as a collection of serial operatives taking place simultaneously, each member of which performs a part of the total task. They meet at certain points to ensure their progress toward their goal, not unlike the way semaphores and other interprocess mechanisms used in computer applications keep themselves synchronized.

In a Unix sense, thinking parallel usually means that you try to keep the central processing unit busy. Most of today's CPUs far outdistance the ability of mass storage devices such as hard drives, floppy disks, and even memory chips to keep up with them. To get the most out of a system, you must keep the processor busy so that it doesn't have to wait for the peripherals to catch up.

The Unix approach is to run multiple processes simultaneously, with each process scheduled to do part of the overall task. That way when any process becomes blocked while waiting for the peripheral devices, several other processes can still function. This results in enormous efficiencies. Consequently, Unix often outperforms other operating systems on the same hardware platform in terms of the total work being done.

Parallelism also greatly affects how users perceive your application. Unix users have long enjoyed "net news," a large collection of articles (files) distributed throughout the world via the Internet network and the Unix-to-Unix copy program uucp. The files cover an incredibly broad range of topics, and thousands of new files appear daily. Net news and other similar forums are the ultimate electronic town meetings.

One problem with net news is that some news groups, as they are called, will often occupy directories on a system containing thousands of files. Such directories are slow and cumbersome to open to obtain a list of files and their headers. Software in the past often required several minutes to open a single large news directory. This frustrated users immensely. It made it extremely difficult when one wanted to hop quickly from news group to news group.

Along came a program written by Larry Wall called rn. It read news group directories the same as any other program with one small catch: It obtained directory listings "in the background" while the user was reading messages. It quietly did this action unbeknownst to the user. The key difference is that when the user decided he or she would like to switch to a different news group, rn had likely already "prefetched" its contents so it could immediately display them. It's like calling ahead for pizza so it will be ready when you get there.

While thinking in parallel has obvious advantages for the rn user interface, it can have equally dramatic effects in other kinds of software as well. For example, Unix allows a command to be run in the background by appending "&" to the command line. Commands invoked this way start a process running in parallel to the command interpreter or shell. It is possible to run several tasks simultaneously this way. This improves efficiency by keeping the CPU busy most of the time instead of idling while waiting for peripherals to complete their I/O requests.

A final point to keep in mind about thinking in parallel is this: No matter how fast a machine may be, you can always create a faster one by stringing several of them together. As the prices of CPU chips continue to plummet, it will become more desirable in the future to run systems having hundreds, thousands, or even millions of processors. By devoting a small unifunctional program to each processor, it will be possible to accomplish tasks that most people consider impossible today. Unix has already established itself as a leader in such environments. Linux is expected to dominate there as well.