The good news is that the ``standard'' beowulf recipe, as simple as it is, is very likely to result in a beowulf that can accomplish certain kinds of work much faster than a single computer working alone. For that matter, so is any OLD network - for some problems (examples will be given later) the entire Internet can be put to work in parallel on parts of the problem with tremendous increases in the amount of work accomplished per unit time.
The bad news is that the phrase ``certain kinds of work'' fails to encompass all sorts of common tasks. I really mean it. Only certain kinds of work can be run profitably (that is, faster) on a parallel processing supercomputer (of any design).
Even worse, as a general rule a task that can be run profitably on a parallel supercomputer will generally not run any faster on one unless it is specially designed and written to take advantage of the parallel environment. Very little commercial software has yet been written that is designed a priori to run in a parallel environment and that which exists is intended for very narrow and specialized applications.
Writing parallel software is not particularly difficult, but neither is it particularly easy. Of course, some people would say that writing serial software isn't particularly easy, and parallel is definitely harder. Well, OK, for many people maybe writing parallel software is particularly difficult. For one thing, any kind of parallel environment is a lot more complex than the already complex serial environment (which these days has lots of parallel features) and this complexity can interact with your software in odd and unexpected ways.
From this might guess that the design of the software to be run on your beowulf-style cluster is likely to be at least as important to the success of your beowulf effort as the design of the beowulf itself. Actually, it is probably more important. As this work will explore in great detail, a cost-benefit optimal design for a beowulf can only be determined after many of the characteristics of the software to be run on it are known quantitatively and an effective parallel software design matched to the quantitatively known low-level hardware capabilities.
Although this is a warning, it is not intended to be a discouraging warning. On the contrary, the design above (augmented with a few more choices and possibilities) is remarkably robust. That is, if one has a ``big'' computing job (the sort that takes a long time to run and hence would benefit from a significant speedup) it is quite likely1.15 that it can be rewritten to run (optimally) profitably in parallel on a beowulf built according to the recipe or on a possibly even cheaper and simpler NOW. The remainder of this book is intended to give prospective beowulf builders and users a great deal of the knowledge and design experience needed to permit them to realize this possibility.
With that said, there are most definitely some limitations on this work - there are things it isn't intended to do and won't help you with. At least not yet. Perhaps as the book evolves chapters will be added (by me or other volunteers) to address these topics.
In the meantime, for example, it will say very little about the details of using e.g. PVM1.16 or MPI1.17 (or any other parallel support library set or raw sockets themselves) to write a network-parallel program. It presumes that if you are going to write parallel software that you either know how to write it or are prepared to learn how from other resources (some resources will be suggested). Similarly, it isn't intended to be a guide to MOSIX1.18 or Condor1.19 or any of a number of other parallel computer or cluster management tools.
The one thing it is intended to do is to make the reader aware of some of the fundamental issues and tradeoffs involved in beowulf design so that they can do very practical things like write a sane grant proposal for a beowulf or build a beowulf for their corporation (or convince their boss to LET them build a beowulf for their corporation) or build a tiny (but useful) beowulf-style cluster in their homes or offices or out of their existing OLD network.
This latter case is a very important, concrete example of how Linux-based cluster computing can provide near-instant benefits in a corporate or educational environment. Consider the following: One very powerful feature of the Linux operating system is that it multitasks flawlessly as long as the system(s) in question are not constrained by memory. Its scheduler has been deliberately tuned to favor interactive usage1.20. As a consequence, certain beowulf-style cluster designs will allow you to recover the benefit of all those cycles currently being wasted on desktop systems (in between keystrokes while people read their mail or edit some document, or worse, running silly screen savers when the users of the systems aren't even sitting at their desks) without impacting the user of the console interface in any perceptible way.
This has to appeal to a small business owner with a big computing job to do and a dozen desktop computers on a network currently twiddling their thumbs (figuratively speaking). It can similarly benefit a university physics or chemistry or math department, where there is a need to cover faculty, staff and graduate student desks with SOME sort of desktop with a web interface and editing/mail tools and there are also significant needs for real computation. If those desktops are Windows-based systems or Macintoshes, their load average is likely to be almost zero - nothing they do on a regular basis requires much CPU - but the unused cycles are wasted as the systems are utterly inaccessible from the network side. If they are running Linux, one can easily run background computations - the whole department can become a readily accessible (transparent to the user) multiprocessor compute cluster managed by e.g. MOSIX or can be running a real parallel (PVM or MPI based) calculation - without the GUI performance of the desktops being noticeably impacted1.21.
From this simple example it should be apparent that beowulf-style cluster computing isn't really just for computer scientists or physicists like myself. It can provide real and immediate benefits to just about anyone with a need for computation (in the sense of lots of compute cycles doing real calculations) as opposed to an interface. Nearly everybody needs to do local computations on local data at least some of the time1.22 - beowulfery simply provides an organization with the means to harvest the vast number of wasted cycles that accrue when they aren't doing computations locally.