Beowulf HOWTO
Jacek Radajewski and Douglas Eadline
v1.1.1, 22 November 1998
This document introduces the Beowulf Supercomputer architecture and
provides background information on parallel programming, including
links to other more specific documents, and web pages.
Table of Contents
1. Preamble
1.1 Disclaimer
1.2 Copyright
1.3 About this HOWTO
1.4 About the authors
1.5 Acknowledgements
2. Introduction
2.1 Who should read this HOWTO ?
2.2 What is a Beowulf ?
2.3 Classification
3. Architecture Overview
3.1 What does it look like ?
3.2 How to utilise the other nodes ?
3.3 How does Beowulf differ from a COW ?
4. System Design
4.1 A brief background on parallel computing.
4.2 The methods of parallel computing
4.2.1 Why more than one CPU?
4.2.2 The Parallel Computing Store
4.2.2.1 Single-tasking Operating System
4.2.2.2 Multi-tasking Operating System:
4.2.2.3 Multitasking Operating Systems with Multiple CPUs:
4.2.2.4 Threads on a Multitasking Operating Systems extra CPUs
4.2.2.5 Sending Messages on Multitasking Operating Systems with extra CPUs:
4.3 Architectures for parallel computing
4.3.1 Hardware Architectures
4.3.2 Software API Architectures
4.3.2.1 Messages
4.3.2.2 Threads
4.3.3 Application Architecture
4.4 Suitability
4.5 Writing and porting parallel software
4.5.1 Determine concurrent parts of your program
4.5.2 Estimate parallel efficiency
4.5.3 Describing the concurrent parts of your program
4.5.3.1 Explicit Methods
4.5.3.2 Implicit Methods
5. Beowulf Resources
5.1 Starting Points
5.2 Documentation
5.3 Papers
5.4 Software
5.5 Beowulf Machines
5.6 Other Interesting Sites
5.7 History
6. Source code
6.1 sum.c
6.2 sigmasqrt.c
6.3 prun.sh
1. Preamble
1.1. Disclaimer
We will not accept any responsibility for any incorrect information
within this document, nor for any damage it might cause when applied.
1.2. Copyright
Copyright (C) 1997 - 1998 Jacek Radajewski and Douglas Eadline.
Permission to distribute and modify this document is granted under the
GNU General Public Licence.
1.3. About this HOWTO
Jacek Radajewski started work on this document in November 1997 and
was soon joined by Douglas Eadline. Over a few months the Beowulf
HOWTO grew into a large document, and in August 1998 it was split into
three documents: Beowulf HOWTO, Beowulf Architecture Design HOWTO, and
the Beowulf Installation and Administration HOWTO. Version 1.0.0 of
the Beowulf HOWTO was released to the Linux Documentation Project on
11 November 1998. We hope that this is only the beginning of what
will become a complete Beowulf Documentation Project.
1.4. About the authors
o Jacek Radajewski works as a Network Manager, and is studying for an
honors degree in computer science at the University of Southern
Queensland, Australia. Jacek's first contact with Linux was in
1995 and it was love at first sight. Jacek built his first Beowulf
cluster in May 1997 and has been playing with the technology ever
since, always trying to find new and better ways of setting things
up. You can contact Jacek by sending e-mail to jacek@usq.edu.au
o Douglas Eadline, Ph.D. is President and Principal Scientist at
Paralogic, Inc., Bethlehem, PA, USA. Trained as
Physical/Analytical? Chemist, he has been involved with computers
since 1978 when he built his first single board computer for use
with chemical instrumentation. Dr. Eadline's interests now include
Linux, Beowulf clusters, and parallel algorithms. Dr. Eadline can
be contacted by sending email to deadline@plogic.com
1.5. Acknowledgements
The writing of the Beowulf HOWTO was a long proces and is finally
complete, thanks to many individuals. I would like to thank the
following people for their help and contribution to this HOWTO.
o Becky for her love, support, and understanding.
o Tom Sterling, Don Becker, and other people at NASA who started the
Beowulf project.
o Thanh Tran-Cong and the Faculty of Engineering and Surveying for
making the topcat Beowulf machine available for experiments.
o My supervisor Christopher Vance for many great ideas.
o My friend Russell Waldron for great programming ideas, his general
interest in the project, and support.
o My friend David Smith for proof reading this document.
o Many other people on the Beowulf mailing list who provided me with
feedback and ideas.
o All the people who are responsible for the Linux operating system
and all the other free software packages used on topcat and other
Beowulf machines.
2. Introduction
As the performance of commodity computer and network hardware
increase, and their prices decrease, it becomes more and more
practical to build parallel computational systems from off-the-shelf
components, rather than buying CPU time on very expensive
Supercomputers. In fact, the price per performance ratio of a Beowulf
type machine is between three to ten times better than that for
traditional supercomputers. Beowulf architecture scales well, it is
easy to construct and you only pay for the hardware as most of the
software is free.
2.1. Who should read this HOWTO ?
This HOWTO is designed for a person with at least some exposure to the
Linux operating system. Knowledge of Beowulf technology or
understanding of more complex operating system and networking concepts
is not essential, but some exposure to parallel computing would be
advantageous (after all you must have some reason to read this
document). This HOWTO will not answer all possible questions you
might have about Beowulf, but hopefully will give you ideas and guide
you in the right direction. The purpose of this HOWTO is to provide
background information, links and references to more advanced
documents.
2.2. What is a Beowulf ?
Famed was this Beowulf: far flew the boast of him, son of Scyld, in
the Scandian lands. So becomes it a youth to quit him well with his
father's friends, by fee and gift, that to aid him, aged, in after
days, come warriors willing, should war draw nigh, liegemen loyal: by
lauded deeds shall an earl have honor in every clan. Beowulf is the
earliest surviving epic poem written in English. It is a story about
a hero of great strength and courage who defeted a monster called
Grendel. See ``History'' to find out more about the Beowulf hero.
There are probably as many Beowulf definitions as there are people who
build or use Beowulf Supercomputer facilities. Some claim that one
can call their system Beowulf only if it is built in the same way as
the NASA's original machine. Others go to the other extreme and call
Beowulf any system of workstations running parallel code. My
definition of Beowulf fits somewhere between the two views described
above, and is based on many postings to the Beowulf mailing list:
Beowulf is a multi computer architecture which can be used for
parallel computations. It is a system which usually consists of one
server node, and one or more client nodes connected together via
Ethernet or some other network. It is a system built using commodity
hardware components, like any PC capable of running Linux, standard
Ethernet adapters, and switches. It does not contain any custom
hardware components and is trivially reproducible. Beowulf also uses
commodity software like the Linux operating system, Parallel Virtual
Machine (PVM) and Message Passing Interface (MPI). The server node
controls the whole cluster and serves files to the client nodes. It
is also the cluster's console and gateway to the outside world. Large
Beowulf machines might have more than one server node, and possibly
other nodes dedicated to particular tasks, for example consoles or
monitoring stations. In most cases client nodes in a Beowulf system
are dumb, the dumber the better. Nodes are configured and controlled
by the server node, and do only what they are told to do. In a disk-
less client configuration, client nodes don't even know their IP
address or name until the server tells them what it is. One of the
main differences between Beowulf and a Cluster of Workstations (COW)
is the fact that Beowulf behaves more like a single machine rather
than many workstations. In most cases client nodes do not have
keyboards or monitors, and are accessed only via remote login or
possibly serial terminal. Beowulf nodes can be thought of as a CPU +
memory package which can be plugged in to the cluster, just like a CPU
or memory module can be plugged into a motherboard.
Beowulf is not a special software package, new network topology or the
latest kernel hack. Beowulf is a technology of clustering Linux
computers to form a parallel, virtual supercomputer. Although there
are many software packages such as kernel modifications, PVM and MPI
libraries, and configuration tools which make the Beowulf architecture
faster, easier to configure, and much more usable, one can build a
Beowulf class machine using standard Linux distribution without any
additional software. If you have two networked Linux computers which
share at least the /home file system via NFS, and trust each other to
execute remote shells (rsh), then it could be argued that you have a
simple, two node Beowulf machine.
2.3. Classification
Beowulf systems have been constructed from a variety of parts. For
the sake of performance some non-commodity components (i.e. produced
by a single manufacturer) have been employed. In order to account
for the different types of systems and to make discussions about
machines a bit easier, we propose the following simple classification
scheme:
CLASS I BEOWULF:
This class of machines built entirely from commodity "off-the-shelf"
parts. We shall use the "Computer Shopper" certification test to
define commodity "off-the-shelf" parts. (Computer Shopper is a 1 inch
thick monthly magazine/catalog of PC systems and components.) The test
is as follows:
A CLASS I Beowulf is a machine that can be assembled from parts found
in at least 3 nationally/globally circulated advertising catalogs.
The advantages of a CLASS I system are:
o hardware is available form multiple sources (low prices, easy
maintenance)
o no reliance on a single hardware vendor
o driver support from Linux commodity
o usually based on standards (SCSI, Ethernet, etc.)
The disadvantages of a CLASS I system are:
o best performance may require CLASS II hardware
CLASS II BEOWULF
A CLASS II Beowulf is simply any machine that does not pass the
Computer Shopper certification test. This is not a bad thing.
Indeed, it is merely a classification of the machine.
The advantages of a CLASS II system are:
o Performance can be quite good!
The disadvantages of a CLASS II system are:
o driver support may vary
o reliance on single hardware vendor
o may be more expensive than CLASS I systems.
One CLASS is not necessarily better than the other. It all depends on
your needs and budget. This classification system is only intended to
make discussions about Beowulf systems a bit more succinct. The
"System Design" section may help determine what kind of system is best
suited for your needs.
3. Architecture Overview
3.1. What does it look like ?
I think that the best way of describing the Beowulf supercomputer
architecture is to use an example which is very similar to the actual
Beowulf, but familiar to most system administrators. The example that
is closest to a Beowulf machine is a Unix computer laboratory with a
server and a number of clients. To be more specific I'll use the DEC
Alpha undergraduate computer laboratory at the Faculty of Sciences,
USQ as the example. The server computer is called beldin and the
client machines are called scilab01, scilab02, scilab03, up to
scilab20. All clients have a local copy of the Digital Unix 4.0
operating system installed, but get the user file space (/home) and
/usr/local from the server via NFS (Network File System). Each client
has an entry for the server and all the other clients in its
/etc/hosts.equiv file, so all clients can execute a remote shell (rsh)
to all others. The server machine is a NIS server for the whole
laboratory, so account information is the same across all the
machines. A person can sit at the scilab02 console, login, and have
the same environment as if he logged onto the server or scilab15. The
reason all the clients have the same look and feel is that the
operating system is installed and configured in the same way on all
machines, and both the user's /home and /usr/local areas are
physically on the server and accessed by the clients via NFS. For
more information on NIS and NFS please read the NIS and NFS HOWTOs.
3.2. How to utilise the other nodes ?
Now that we have some idea about the system architecture, let us take
a look at how we can utilise the available CPU cycles of the machines
in the computer laboratory. Any person can logon to any of the
machines, and run a program in their home directory, but they can also
spawn the same job on a different machine simply by executing remote
shell. For example, assume that we want to calculate the sum of the
square roots of all integers between 1 and 10 inclusive. We write a
simple program called sigmasqrt (please see ``source code'') which
does exactly that. To calculate the sum of the square roots of
numbers from 1 to 10 we execute :
[jacek@beldin sigmasqrt]$ time ./sigmasqrt 1 10
22.468278
real 0m0.029s
user 0m0.001s
sys 0m0.024s
The time command allows us to check the wall-clock (the elapsed time)
of running this job. As we can see, this example took only a small
fraction of a second (0.029 sec) to execute, but what if I want to add
the square root of integers from 1 to 1 000 000 000 ? Let us try
this, and again calculate the wall-clock time.
[jacek@beldin sigmasqrt]$ time ./sigmasqrt 1 1000000000
21081851083600.559000
real 16m45.937s
user 16m43.527s
sys 0m0.108s
This time, the execution time of the program is considerably longer.
The obvious question to ask is what can we do to speed up the
execution time of the job? How can we change the way the job is
running to minimize the wall-clock time of running this job? The
obvious answer is to split the job into a number of sub-jobs and to
run these sub-jobs in parallel on all computers. We could split one
big addition task into 20 parts, calculating one range of square roots
and adding them on each node. When all nodes finish the calculation
and return their results, the 20 numbers could be added together to
obtain the final solution. Before we run this job we will make a
named pipe which will be used by all processes to write their results.
[jacek@beldin sigmasqrt]$ mkfifo output
[jacek@beldin sigmasqrt]$ ./prun.sh & time cat output | ./sum
[1] 5085
21081851083600.941000
[1]+ Done ./prun.sh
real 0m58.539s
user 0m0.061s
sys 0m0.206s
This time we get about 58.5 seconds. This is the time from starting
the job until all the nodes have finished their computations and
written their results into the pipe. The time does not include the
final addition of the twenty numbers, but this time is a very small
fraction of a second and can be ignored. We can see that there is a
significant improvement in running this job in parallel. In fact the
parallel job ran about 17 times faster, which is very reasonable for a
20 fold increase in the number of CPUs. The purpose of the above
example is to illustrate the simplest method of parallelising
concurrent code. In practice such simple examples are rare and
different techniques (PVM and PMI APIs) are used to achieve the
parallelism.
3.3. How does Beowulf differ from a COW ?
The computer laboratory described above is a perfect example of a
Cluster of Workstations (COW). So what is so special about Beowulf,
and how is it different from a COW? The truth is that there is not
much difference, but Beowulf does have few unique characteristics.
First of all, in most cases client nodes in a Beowulf cluster do not
have keyboards, mice, video cards nor monitors. All access to the
client nodes is done via remote connections from the server node,
dedicated console node, or a serial console. Because there is no need
for client nodes to access machines outside the cluster, nor for
machines outside the cluster to access client nodes directly, it is a
common practice for the client nodes to use private IP addresses like
the 10.0.0.0/8 or 192.168.0.0/16 address ranges (RFC 1918
http://www.alternic.net/rfcs/1900/rfc1918.txt.html). Usually the only
machine that is also connected to the outside world using a second
network card is the server node. The most common ways of using the
system is to access the server's console directly, or either telnet or
remote login to the server node from personal workstation. Once on
the server node, users can edit and compile their code, and also spawn
jobs on all nodes in the cluster. In most cases COWs are used for
parallel computations at night, and over weekends when people do not
actually use the workstations for every day work, thus utilising idle
CPU cycles. Beowulf on the other hand is a machine usually dedicated
to parallel computing, and optimised for this purpose. Beowulf also
gives better price/performance ratio as it is built from off-the-shelf
components and runs mainly free software. Beowulf has also more
single system image features which help the users to see the Beowulf
cluster as a single computing workstation.
4. System Design
Before you purchase any hardware, it may be a good idea to consider
the design of your system. There are basically two hardware issues
involved with design of a Beowulf system: the type of nodes or
computers you are going to use; and way you connect the computer
nodes. There is one software issue that may effect your hardware
decisions; the communication library or API. A more detailed
discussion of hardware and communication software is provided later in
this document.
While the number of choices is not large, there are some important
design decisions that must be made when constructing a Beowulf
systems. Because the science (or art) of "parallel computing" has
many different interpretations, an introduction is provided below. If
you do not like to read background material, you may skip this
section, but it is advised that you read section ``Suitability''
before you make you final hardware decisions.
4.1. A brief background on parallel computing.
This section provides background on parallel computing concepts. It
is NOT an exhaustive or complete description of parallel computing
science and technology. It is a brief description of the issues that
may be important to a Beowulf designer and user.
As you design and build your Beowulf, many of these issues described
below will become important in your decision process. Due to its
component nature, a Beowulf Supercomputer requires that we consider
many factors carefully because they are now under our control. In
general, it is not all that difficult to understand the issues
involved with parallel computing. Indeed, once the issues are
understood, your expectations will be more realistic and success will
be more likely. Unlike the "sequential world" where processor speed is
considered the single most important factor, processor speed in the
"parallel world" is just one of several factors that will determine
overall system performance and efficiency.
4.2. The methods of parallel computing
Parallel computing can take many forms. From a user's perspective, it
is important to consider the advantages and disadvantages of each
methodology. The following section attempts to provide some
perspective on the methods of parallel computing and indicate where
the Beowulf machine falls on this continuum.
4.2.1. Why more than one CPU?
Answering this question is important. Using 8 CPUs to run your word
processor sounds a little like "over-kill" -- and it is. What about a
web server, a database, a rendering program, or a project scheduler?
Maybe extra CPUs would help. What about a complex simulation, a fluid
dynamics code, or a data mining application. Extra CPUs definitely
help in these situations. Indeed, multiple CPUs are being used to
solve more and more problems.
The next question usually is: "Why do I need two or four CPUs, I will
just wait for the 986 turbo-hyper chip." There are several reasons:
1. Due to the use of multi-tasking Operating Systems, it is possible
to do several things at once. This is a natural "parallelism" that
is easily exploited by more than one low cost CPU.
2. Processor speeds have been doubling every 18 months, but what about
RAM speeds or hard disk speeds? Unfortunately, these speeds are not
increasing as fast as the CPU speeds. Keep in mind most
applications require "out of cache memory access" and hard disk
access. Doing things in parallel is one way to get around some of
these limitations.
3. Predictions indicate that processor speeds will not continue to
double every 18 months after the year 2005. There are some very
serious obstacles to overcome in order to maintain this trend.
4. Depending on the application, parallel computing can speed things
up by any where from 2 to 500 times faster (in some cases even
faster). Such performance is not available using a single
processor. Even supercomputers that at one time used very fast
custom processors are now built from multiple "commodity- off-the-
shelf" CPUs.
If you need speed - either due to a compute bound problem and/or an
I/O bound problem, parallel is worth considering. Because parallel
computing is implemented in a variety of ways, solving your problem in
parallel will require some very important decisions to be made. These
decisions may dramatically effect portability, performance, and cost
of your application.
Before we get technical, let's look take a look at a real "parallel
computing problem" using an example with which we are familiar -
waiting in long lines at a store.
4.2.2. The Parallel Computing Store
Consider a big store with 8 cash registers grouped together in the
front of the store. Assume each cash register/cashier is a CPU and
each customer is a computer program. The size of the computer program
(amount of work) is the size of each customer's order. The following
analogies can be used to illustrate parallel computing concepts.
4.2.2.1. Single-tasking Operating System
One cash register open (is in use) and must process each customer one
at a time.
Computer Example: MS DOS
4.2.2.2. Multi-tasking Operating System:
One cash register open, but now we process only a part of each order
at a time, move to the next person and process some of their order.
Everyone "seems" to be moving through the line together, but if no one
else is in the line, you will get through the line faster.
Computer Example: UNIX, NT using a single CPU
4.2.2.3. Multitasking Operating Systems with Multiple CPUs:
Now we open several cash registers in the store. Each order can be
processed by a separate cash register and the line can move much
faster. This is called SMP - Symmetric Multi-processing. Although
there are extra cash registers open, you will still never get through
the line any faster than just you and a single cash register.
Computer Example: UNIX and NT with multiple CPUs
4.2.2.4. Threads on a Multitasking Operating Systems extra CPUs
If you "break-up" the items in your order, you might be able to move
through the line faster by using several cash registers at one time.
First, we must assume you have a large amount of goods, because the
time you invest "breaking up your order" must be regained by using
multiple cash registers. In theory, you should be able to move
through the line "n" times faster than before*; where "n" is the
number of cash registers. When the cashiers need to get sub- totals,
they can exchange information quickly by looking and talking to all
the other "local" cash registers. They can even snoop around the other
cash registers to find information they need to work faster. There is
a limit, however, as to how many cash registers the store can
effectively locate in any one place.
Amdals law will also limit the application speed-up to the slowest
sequential portion of the program.
Computer Example: UNIX or NT with extra CPU on the same motherboard
running multi-threaded programs.
4.2.2.5. Sending Messages on Multitasking Operating Systems with
extra CPUs:
In order to improve performance, the store adds 8 cash registers at
the back of the store. Because the new cash registers are far away
from the front cash registers, the cashiers must call on the phone to
send their sub-totals to the front of the store. This distance adds
extra overhead (time) to communication between cashiers, but if
communication is minimized, it is not a problem. If you have a
really big order, one that requires all the cash registers, then as
before your speed can be improved by using all cash registers at the
same time, the extra overhead must be considered. In some cases, the
store may have single cash registers (or islands of cash registers)
located all over the store - each cash register (or island) must
communicate by phone. Since all the cashiers working the cash
registers can talk to each other by phone, it does not matter too much
where they are.
Computer Example: One or several copies of UNIX or NT with extra CPUs
on the same or different motherboard communicating through messages.
The above scenarios, although not exact, are a good representation of
constraints placed on parallel systems. Unlike a single CPU (or cash
register) communication is an issue.
4.3. Architectures for parallel computing
The common methods and architectures of parallel computing are
presented below. While this description is by no means exhaustive, it
is enough to understand the basic issues involved with Beowulf design.
4.3.1. Hardware Architectures
There are basically two ways parallel computer hardware is put
together:
1. Local memory machines that communicate by messages (Beowulf
Clusters)
2. Shared memory machines that communicate through memory (SMP
machines)
A typical Beowulf is a collection of single CPU machines connected
using fast Ethernet and is, therefore, a local memory machine. A 4
way SMP box is a shared memory machine and can be used for parallel
computing - parallel applications communicate using shared memory.
Just as in the computer store analogy, local memory machines
(individual cash registers) can be scaled up to large numbers of CPUs,
while the number of CPUs shared memory machines (the number of cash
registers you can place in one spot) can have is limited due to memory
contention.
It is possible, however, to connect many shared memory machines to
create a "hybrid" shared memory machine. These hybrid machines "look"
like a single large SMP machine to the user and are often called NUMA
(non uniform memory access) machines because the global memory seen by
the programmer and shared by all the CPUs can have different
latencies. At some level, however, a NUMA machine must "pass
messages" between local shared memory pools.
It is also possible to connect SMP machines as local memory compute
nodes. Typical CLASS I motherboards have either 2 or 4 CPUs and are
often used as a means to reduce the overall system cost. The Linux
internal scheduler determines how these CPUs get shared. The user
cannot (at this point) assign a specific task to a specific SMP
processor. The user can however, start two independent processes or a
threaded processes and expect to see a performance increase over a
single CPU system.
4.3.2. Software API Architectures
There basically two ways to "express" concurrency in a program:
1. Using Messages sent between processors
2. Using operating system Threads
Other methods do exist, but these are the two most widely used. It is
important to remember that the expression of concurrency is not
necessary controlled by the underlying hardware. Both Messages and
Threads can be implemented on SMP, NUMA-SMP, and clusters - although
as explained below efficiently and portability are important issues.
4.3.2.1. Messages
Historically, messages passing technology reflected the design of
early local memory parallel computers. Messages require copying data
while Threads use data in place. The latency and speed at which
messages can be copied are the limiting factor with message passing
models. A Message is quite simple: some data and a destination
processor. Common message passing APIs are PVM or MPI. Message
passing can be efficiently implemented using Threads and Messages work
well both on SMP machine and between clusters of machines. The
advantage to using messages on an SMP machine, as opposed to Threads,
is that if you decided to use clusters in the future it is easy to add
machines or scale your application.
4.3.2.2. Threads
Operating system Threads were developed because shared memory SMP
(symmetrical multiprocessing) designs allowed very fast shared memory
communication and synchronization between concurrent parts of a
program. Threads work well on SMP systems because communication is
through shared memory. For this reason the user must isolate local
data from global data, otherwise programs will not work properly. In
contrast to messages, a large amount of copying can be eliminated with
threads because the data is shared between processes (threads). Linux
supports POSIX threads. The problem with threads is that it is
difficult to extend them beyond one SMP machine and because data is
shared between CPUs, cache coherence issues can contribute to
overhead. Extending threads beyond the SMP boundary efficiently
requires NUMA technology which is expensive and not natively supported
by Linux. Implementing threads on top of messages has been done
((http://syntron.com/ptools/ptools_pg.htm)), but Threads are often
inefficient when implemented using messages.
The following can be stated about performance:
SMP machine cluster of machines scalability
performance performance
messages good best best
threads best poor* poor*
* requires expensive NUMA technology.
4.3.3. Application Architecture
In order to run an application in parallel on multiple CPUs, it must
be explicitly broken in to concurrent parts. A standard single CPU
application will run no faster than a single CPU application on
multiple processors. There are some tools and compilers that can
break up programs, but parallelizing codes is not a "plug and play"
operation. Depending on the application, parallelizing code can be
easy, extremely difficult, or in some cases impossible due to
algorithm dependencies.
Before the software issues can be addressed the concept of Suitability
needs to be introduced.
4.4. Suitability
Most questions about parallel computing have the same answer:
"It all depends upon the application."
Before we jump into the issues, there is one very important
distinction that needs to be made - the difference between CONCURRENT
and PARALLEL. For the sake of this discussion we will define these
two concepts as follows:
CONCURRENT parts of a program are those that can be computed
independently.
PARALLEL parts of a program are those CONCURRENT parts that are
executed on separate processing elements at the same time.
The distinction is very important, because CONCURRENCY is a property
of the program and efficient PARALLELISM is a property of the machine.
Ideally, PARALLEL execution should result in faster performance. The
limiting factor in parallel performance is the communication speed and
latency between compute nodes. (Latency also exists with threaded SMP
applications due to cache coherency.) Many of the common parallel
benchmarks are highly parallel and communication and latency are not
the bottle neck. This type of problem can be called "obviously
parallel". Other applications are not so simple and executing
CONCURRENT parts of the program in PARALLEL may actually cause the
program to run slower, thus offsetting any performance gains in other
CONCURRENT parts of the program. In simple terms, the cost of
communication time must pay for the savings in computation time,
otherwise the PARALLEL execution of the CONCURRENT part is
inefficient.
The task of the programmer is to determining what CONCURRENT parts of
the program SHOULD be executed in PARALLEL and what parts SHOULD NOT.
The answer to this will determine the EFFICIENCY of application. The
following graph summarizes the situation for the programmer:
| *
| *
| *
% of | *
appli- | *
cations | *
| *
| *
| *
| *
| *
| ****
| ****
| ********************
+
communication time/processing time
In a perfect parallel computer, the ratio of communication/processing
would be equal and anything that is CONCURRENT could be implemented in
PARALLEL. Unfortunately, Real parallel computers, including shared
memory machines, are subject to the effects described in this graph.
When designing a Beowulf, the user may want to keep this graph in mind
because parallel efficiency depends upon ratio of communication time
and processing time for A SPECIFIC PARALLEL COMPUTER. Applications
may be portable between parallel computers, but there is no guarantee
they will be efficient on a different platform.
IN GENERAL, THERE IS NO SUCH THING AS A PORTABLE AND EFFICIENT
PARALLEL PROGRAM
There is yet another consequence to the above graph. Since efficiency
depends upon the comm./process. ratio, just changing one component of
the ratio does not necessary mean a specific application will perform
faster. A change in processor speed, while keeping the communication
speed that same may have non- intuitive effects on your program. For
example, doubling or tripling the CPU speed, while keeping the
communication speed the same, may now make some previously efficient
PARALLEL portions of your program, more efficient if they were
executed SEQUENTIALLY. That is, it may now be faster to run the
previously PARALLEL parts as SEQUENTIAL. Furthermore, running
inefficient parts in parallel will actually keep your application from
reaching its maximum speed. Thus, by adding faster processor, you may
actually slowed down your application (you are keeping the new CPU
from running at its maximum speed for that application)
UPGRADING TO A FASTER CPU MAY ACTUALLY SLOW DOWN YOUR APPLICATION
So, in conclusion, to know whether or not you can use a parallel
hardware environment, you need to have some insight into the
suitability of a particular machine to your application. You need to
look at a lot of issues including CPU speeds, compiler, message
passing API, network, etc. Please note, just profiling an
application, does not give the whole story. You may identify a
computationally heavy portion of your program, but you do not know the
communication cost for this portion. It may be that for a given
system, the communication cost as do not make parallelizing this code
efficient.
A final note about a common misconception. It is often stated that "a
program is PARALLELIZED", but in reality only the CONCURRENT parts of
the program have been located. For all the reasons given above, the
program is not PARALLELIZED. Efficient PARALLELIZATION is a property
of the machine.
4.5. Writing and porting parallel software
Once you decide that you need parallel computing and would like to
design and build a Beowulf, a few moments considering your application
with respect to the previous discussion may be a good idea.
In general there are two things you can do:
1. Go ahead and construct a CLASS I Beowulf and then "fit" your
application to it. Or run existing parallel applications that you
know work on your Beowulf (but beware of the portability and
efficiently issues mentioned above)
2. Look at the applications you need to run on your Beowulf and make
some estimations as to the type of hardware and software you need.
In either case, at some point you will need to look at the efficiency
issues. In general, there are three things you need to do:
1. Determine concurrent parts of your program
2. Estimate parallel efficiently
3. Describing the concurrent parts of your program
Let's look at these one at a time.
4.5.1. Determine concurrent parts of your program
This step is often considered "parallelizing your program".
Parallelization decisions will be made in step 2. In this step, you
need to determine data dependencies.
>From a practical standpoint, applications may exhibit two types of
concurrency: compute (number crunching) and I/O (database). Although
in many cases compute and I/O concurrency are orthogonal, there are
application that require both. There are tools available that can
perform concurrency analysis on existing applications. Most of these
tools are designed for FORTRAN. There are two reasons FORTRAN is
used: historically most number crunching applications were written in
FORTRAN and it is easier to analyze. If no tools are available, then
this step can be some what difficult for existing applications.
4.5.2. Estimate parallel efficiency
Without the help of tools, this step may require trial and error tests
or just a plain old educated guess. If you have a specific
application in mind, try to determine if it is CPU limited (compute
bound) or hard disk limited (I/O bound). The requirements of your
Beowulf may be quite different depending upon your needs. For
example, a compute bound problem may need a few very fast CPUs and
high speed low latency network, while an I/O bound problem may work
better with more slower CPUs and fast Ethernet.
This recommendation often comes as a surprise to most people because,
the standard assumption is that faster processor are always better.
While this is true if your have an unlimited budget, real systems may
have cost constraints that should be maximized. For I/O bound
problems, there is a little known rule (called the Eadline-Dedkov Law)
that is quite helpful:
For two given parallel computers with the same cumulative CPU
performance index, the one which has slower processors (and a probably
correspondingly slower interprocessor communication network) will have
better performance for I/O-dominant applications.
While the proof of this rule is beyond the scope of this document, you
find it interesting to download the paper Performance Considerations
for I/O-Dominant Applications on Parallel Computers (Postscript format
109K ) (ftp://www.plogic.com/pub/papers/exs-pap6.ps)
Once you have determined what type of concurrency you have in your
application, you will need to estimate how efficient it will be in
parallel. See Section ``Software'' for a description of Software
tools.
In the absence of tools, you may try to guess your way through this
step. If a compute bound loop measured in minutes and the data can be
transferred in seconds, then it might be a good candidate for
parallelization. But remember, if you take a 16 minute loop and break
it into 32 parts, and your data transfers require several seconds per
part, then things are going to get tight. You will reach a point of
diminishing returns.
4.5.3. Describing the concurrent parts of your program
There are several ways to describe concurrent parts of your program:
1. Explicit parallel execution
2. Implicit parallel execution
The major difference between the two is that explicit parallelism is
determined by the user where implicit parallelism is determined by the
compiler.
4.5.3.1. Explicit Methods
These are basically method where the user must modify source code
specifically for a parallel computer. The user must either add
messages using PVM or MPI or add threads using POSIX threads. (Keep in
mind however, threads can not move between SMP motherboards).
Explicit methods tend to be the most difficult to implement and debug.
Users typically embed explicit function calls in standard FORTRAN 77
or C/C++ source code. The MPI library has added some functions to
make some standard parallel methods easier to implement (i.e.
scatter/gather functions). In addition, it is also possible to use
standard libraries that have been written for parallel computers.
Keep in mind, however, the portability vs. efficiently trade-off)
For historical reasons, most number crunching codes are written in
FORTRAN. For this reasons, FORTRAN has the largest amount of support
(tools, libraries, etc.) for parallel computing. Many programmers now
use C or re- write existing FORTRAN applications in C with the notion
the C will allow faster execution. While this may be true as C is the
closest thing to a universal machine code, it has some major
drawbacks. The use of pointers in C makes determining data
dependencies extremely difficult. Automatic analysis of pointers is
extremely difficult. If you have an existing FORTRAN program and think
that you might want to parallelize it in the future - DO NOT CONVERT
IT TO C!
4.5.3.2. Implicit Methods
Implicit methods are those where the user gives up some (or all) of
the parallelization decisions to the compiler. Examples are FORTRAN
90, High Performance FORTRAN (HPF), Bulk Synchronous Parallel (BSP),
and a whole collection of other methods that are under development.
Implicit methods require the user to provide some information about
the concurrent nature of their application, but the compiler will then
make many decisions about how to execute this concurrency in parallel.
These methods provide some level of portability and efficiency, but
there is still no "best way" to describe a concurrent problem for a
parallel computer.
5. Beowulf Resources
5.1. Starting Points
o Beowulf mailing list. To subscribe send mail to beowulf-
request@cesdis.gsfc.nasa.gov with the word subscribe in the message
body.
o Beowulf Homepage http://www.beowulf.org
o Extreme Linux http://www.extremelinux.org
o Extreme Linux Software from Red Hat http://www.redhat.com/extreme
5.2. Documentation
o The latest version of the Beowulf HOWTO
http://www.sci.usq.edu.au/staff/jacek/beowulf.
o Building a Beowulf System
http://www.cacr.caltech.edu/beowulf/tutorial/building.html
o Jacek's Beowulf Links
http://www.sci.usq.edu.au/staff/jacek/beowulf.
o Beowulf Installation and Administration HOWTO (DRAFT)
http://www.sci.usq.edu.au/staff/jacek/beowulf.
o Linux Parallel Processing HOWTO
http://yara.ecn.purdue.edu/~pplinux/PPHOWTO/pphowto.html
5.3. Papers
o Chance Reschke, Thomas Sterling, Daniel Ridge, Daniel Savarese,
Donald Becker, and Phillip Merkey A Design Study of Alternative
Network Topologies for the Beowulf Parallel Workstation.
Proceedings Fifth IEEE International Symposium on High Performance
Distributed Computing, 1996.
http://www.beowulf.org/papers/HPDC96/hpdc96.html
o Daniel Ridge, Donald Becker, Phillip Merkey, Thomas Sterling
Becker, and Phillip Merkey. Harnessing the Power of Parallelism in
a Pile-of-PCs. Proceedings, IEEE Aerospace, 1997.
http://www.beowulf.org/papers/AA97/aa97.ps
o Thomas Sterling, Donald J. Becker, Daniel Savarese, Michael R.
Berry, and Chance Res. Achieving a Balanced Low-Cost Architecture
for Mass Storage Management through Multiple Fast Ethernet Channels
on the Beowulf Parallel Workstation. Proceedings, International
Parallel Processing Symposium, 1996.
http://www.beowulf.org/papers/IPPS96/ipps96.html
o Donald J. Becker, Thomas Sterling, Daniel Savarese, Bruce Fryxell,
Kevin Olson. Communication Overhead for Space Science Applications
on the Beowulf Parallel Workstation. Proceedings,High Performance
and Distributed Computing, 1995.
http://www.beowulf.org/papers/HPDC95/hpdc95.html
o Donald J. Becker, Thomas Sterling, Daniel Savarese, John E.
Dorband, Udaya A. Ranawak, Charles V. Packer. BEOWULF: A PARALLEL
WORKSTATION FOR SCIENTIFIC COMPUTATION. Proceedings, International
Conference on Parallel Processing, 95.
http://www.beowulf.org/papers/ICPP95/icpp95.html
o Papers at the Beowulf site
http://www.beowulf.org/papers/papers.html
5.4. Software
o PVM - Parallel Virtual Machine
http://www.epm.ornl.gov/pvm/pvm_home.html
o LAM/MPI (Local Area Multicomputer / Message Passing Interface
http://www.mpi.nd.edu/lam
o BERT77 - FORTRAN conversion tool http://www.plogic.com/bert.html
o Beowulf software from Beowulf Project Page
http://beowulf.gsfc.nasa.gov/software/software.html
o Jacek's Beowulf-utils ftp://ftp.sci.usq.edu.au/pub/jacek/beowulf-
utils
o bWatch - cluster monitoring tool
http://www.sci.usq.edu.au/staff/jacek/bWatch
5.5. Beowulf Machines
o Avalon consists of 140 Alpha processors, 36 GB of RAM, and is
probably the fastest Beowulf machine, cruising at 47.7 Gflops and
ranking 114th on the Top 500 list. http://swift.lanl.gov/avalon/
o Megalon-A Massively PArallel CompuTer? Resource (MPACTR) consists of
14, quad CPU Pentium Pro 200 nodes, and 14 GB of RAM.
http://megalon.ca.sandia.gov/description.html
o theHIVE - Highly-parallel Integrated Virtual Environment is another
fast Beowulf Supercomputer. theHIVE is a 64 node, 128 CPU machine
with the total of 4 GB RAM. http://newton.gsfc.nasa.gov/thehive/
o Topcat is a much smaller machine and consists of 16 CPUs and 1.2 GB
RAM. http://www.sci.usq.edu.au/staff/jacek/topcat
o MAGI cluster - this is a very interesting site with many good
links. http://noel.feld.cvut.cz/magi/
5.6. Other Interesting Sites
o SMP Linux http://www.linux.org.uk/SMP/title.html
o Paralogic - Buy a Beowulf http://www.plogic.com
5.7. History
o Legends - Beowulf http://legends.dm.net/beowulf/index.html
o The Adventures of Beowulf
http://www.lnstar.com/literature/beowulf/beowulf.html
6. Source code
6.1. sum.c
/* Jacek Radajewski jacek@usq.edu.au */
/* 21/08/1998 */
#include <stdio.h>
#include <math.h>
int main (void) {
double result = 0.0;
double number = 0.0;
char string[80];
while (scanf("%s", string) != EOF) {
number = atof(string);
result = result + number;
}
printf("%lf\n", result);
return 0;
}
6.2. sigmasqrt.c
/* Jacek Radajewski jacek@usq.edu.au */
/* 21/08/1998 */
#include <stdio.h>
#include <math.h>
int main (int argc, char** argv) {
long number1, number2, counter;
double result;
if (argc < 3) {
printf ("usage : %s number1 number2\n",argv[0]);
exit(1);
} else {
number1 = atol (argv[1]);
number2 = atol (argv[2]);
result = 0.0;
}
for (counter = number1; counter <= number2; counter++) {
result = result + sqrt((double)counter);
}
printf("%lf\n", result);
return 0;
}
6.3. prun.sh
#!/bin/bash
# Jacek Radajewski jacek@usq.edu.au
# 21/08/1998
export SIGMASQRT=/home/staff/jacek/beowulf/HOWTO/example1/sigmasqrt
# $OUTPUT must be a named pipe
# mkfifo output
export OUTPUT=/home/staff/jacek/beowulf/HOWTO/example1/output
rsh scilab01 $SIGMASQRT 1 50000000 > $OUTPUT < /dev/null&
rsh scilab02 $SIGMASQRT 50000001 100000000 > $OUTPUT < /dev/null&
rsh scilab03 $SIGMASQRT 100000001 150000000 > $OUTPUT < /dev/null&
rsh scilab04 $SIGMASQRT 150000001 200000000 > $OUTPUT < /dev/null&
rsh scilab05 $SIGMASQRT 200000001 250000000 > $OUTPUT < /dev/null&
rsh scilab06 $SIGMASQRT 250000001 300000000 > $OUTPUT < /dev/null&
rsh scilab07 $SIGMASQRT 300000001 350000000 > $OUTPUT < /dev/null&
rsh scilab08 $SIGMASQRT 350000001 400000000 > $OUTPUT < /dev/null&
rsh scilab09 $SIGMASQRT 400000001 450000000 > $OUTPUT < /dev/null&
rsh scilab10 $SIGMASQRT 450000001 500000000 > $OUTPUT < /dev/null&
rsh scilab11 $SIGMASQRT 500000001 550000000 > $OUTPUT < /dev/null&
rsh scilab12 $SIGMASQRT 550000001 600000000 > $OUTPUT < /dev/null&
rsh scilab13 $SIGMASQRT 600000001 650000000 > $OUTPUT < /dev/null&
rsh scilab14 $SIGMASQRT 650000001 700000000 > $OUTPUT < /dev/null&
rsh scilab15 $SIGMASQRT 700000001 750000000 > $OUTPUT < /dev/null&
rsh scilab16 $SIGMASQRT 750000001 800000000 > $OUTPUT < /dev/null&
rsh scilab17 $SIGMASQRT 800000001 850000000 > $OUTPUT < /dev/null&
rsh scilab18 $SIGMASQRT 850000001 900000000 > $OUTPUT < /dev/null&
rsh scilab19 $SIGMASQRT 900000001 950000000 > $OUTPUT < /dev/null&
rsh scilab20 $SIGMASQRT 950000001 1000000000 > $OUTPUT < /dev/null&
![[Home]](wikipedia.png)
Linux Documentation Project/Beowulf HOWTO