Why should you consider using occam?
Roger Peel
A recent item asked whether anyone still used occam to program
transputers. My response is a definite YES! Perhaps I should also retort
by asking why anyone should wish to program these exciting processors in
an insecure sequential language such as C - but I am not that brave.
I have programmed in occam for 7 or 8 years now, and have no plans to
switch. Apart from personal use, I teach it as a vehicle for parallel
programming, and I supervise many project students (from undergraduate to
research levels) who use occam, typically, to control transputer-based
hardware. In appropriate circumstances, of course, I also use a number of
other languages. I suggest that my occam program design experience, in
particular, has made me a better sequential programmer. Why?
Occam is a small(ish) language with well-defined semantics. It
incorporates many features not found in other mainstream languages,
especially its built-in timer. Being a fully-typed language, the compiler
checks that expressions are consistent (like many other modern languages -
but not C). The need for explicit type conversion is irritating at times,
but is catching on elsewhere because it allows one to reason about how
expressions are evaluated without having to memorise complicated automatic
coercion rules. Remember that addition and multiplication are not
strictly associative or commutative if their results are only finite-width
binary words. In occam, functions are guaranteed to have no side-effects,
and therefore (for any set of operands) will ALWAYS return the same
result.
OK - so much for sequential safety features. But what makes occam unique
is that the concept of proper support for multiple parallel processes and
inter-process communication is built in, and is very easily accessible by
the programmer. For any task which involves real-time activity, I/O
buffering, interfacing with peripheral devices or just plain parallel
processing, this is really profitable. It means that we can keep the
separate elements of our task apart - with processes which supervise the
slow peripherals, FIFO buffers to keep them fed, and processes for the
separate computational activities which drive them. A big fuss is being
made about object-oriented methods these days, but message-passing
parallelism is an even more powerful concept - not only cannot processes
interfere with each other unless invited to communicate, but they can also
run in parallel on appropriate hardware! All this is achieved by the
strict type-checking of what is communicated along the channels between
processes, as well as stored within. Hence any message-passing parallel
language without an equivalent of the occam channel PROTOCOLs does not
provide this necessary security.
So why is occam not liked by so many programmers? Well, some write
sequential code for which occam only provides a few extra benefits. Fine
- they can justifiably continue to use a sequential language provided they
only attempt to run their code on a single transputer. Parallel
enhancements to a sequential language might be acceptable for particularly
large-grained parallel tasks, too, but this is not where occam stands out,
either. Some objectors - rightly - object to occam's lack of standard
facilities such as structures or records (although these will become
available in occam 3). Others may be worried that they will suffer
withdrawal symptoms if they are unable to use untyped pointers. A few
maybe even enjoy wasting time wading between breakpoints inside a
debugger, rather than picking up their mis-conceptions and typos in a
compiler. Instead, I prefer the world of dozens of lightweight parallel
processes, buffers, multiplexers, FIFOs, PROTOCOLs, ALTs and a simple,
clean syntax to describe them. But I suggest that the majority of
objectors have not been able to re-organise their thought processes
sufficiently to see how to exploit the novel features occam provides, and
in particular they do not see the need for fine-grained parallelism and
data management. Many are still struggling to manage their real-time task
using polling inside their main program loop, with semaphores, shared
memory buffers and interrupts for added entertainment.
So how should one learn about occam? My experience is that it only takes
about 4 hours to teach the whole of the occam _syntax_ to competent Pascal
or C programmers, so an evening reading the Occam Reference Manual is a
good start. However, just this is likely to create the doubters who
voiced the original question. It is then necessary to spend a couple of
days looking at the applications side of the language - the occam idioms -
with an experienced occamist. Sequential programming courses have their
sorting, searching, pointer manipulation and data organisation elements,
and one should not expect to understand occam until aspects of buffering,
real-time response, deadlock and so on have been clearly demonstrated.
Many such courses are available, perhaps especially in the U.K. Even
better, go to a technical meeting or workshop run by NATUG, WoTUG or your
own national transputer user group, and take the opportunity to talk with
the tutors, speakers and delegates about their occam experiences.
And what of the future of occam? Occam 3 will provide more of the
facilities which are found in the larger sequential languages, but
provided in a secure, type-checked fashion. More importantly, it will
include a sophisticated scheme for modularising programs, enabling very
large occam programs to be created by teams of programmers in a controlled
fashion. Think of this as the provision of library modules which can call
the user's program as well as be called by other programs (and remember
that this has to work in a parallel environment) and you will get a feel
for the ideas in the pipeline. Occam 3 will also have new facilities for
shared channels, which not only maps onto the new fast ALT mechanism
provided by the T9000, but also means that a process can monitor such a
channel without having to know how many processes may send messages along
it, which will make such processes more general-purpose and easier to
design for re-use in a module.
It would be nice to see future occam compilers which generate code to run
on processors other than the transputer. I would love to be able to
program DSP chips or single-chip microprocessors in occam, rather than in
C or assembler. In order to facilitate this, WoTUG (with considerable
support from INMOS) will be running an Occam Re-targeting Workshop at the
University of Kent, England, on 15th-16th September 1992. This will
provide a complete insight into the occam compiler front-end which is
available from INMOS and provides a framework for code generation onto the
processor of your choice. There will, of course, be the opportunity to
discuss a joint strategy for such re-targeting exercises.
Immediately before the Occam Workshop, on 14th-15th September, WoTUG will
be running a T9000 Systems Workshop in which yet more INMOS staff will be
presenting a comprehensive guide to how best to utilise the new facilities
found on the T9000.
For details of both workshops, contact : Judith Farmer, Computing
Laboratory, University of Kent, CANTERBURY, Kent CT2 7NF, U.K., or email
j...@ukc.ac.uk.
Roger M.A. Peel
Department of Electronic and Phone : +44 483 509284 (0483 from UK)
Electrical Engineering Fax : +44 483 34139
University of Surrey Telex : 859331
Guildford JANET : R.P...@uk.ac.surrey.ee
Surrey GU2 5XH UUCP : ...mcsun!ukc!ee.surrey.ac.uk!R.Peel
United Kingdom
Rob Kurver
>So why is occam not liked by so many programmers? Well, some write
>sequential code for which occam only provides a few extra benefits. Fine
>- they can justifiably continue to use a sequential language provided they
>only attempt to run their code on a single transputer. Parallel
>enhancements to a sequential language might be acceptable for particularly
>large-grained parallel tasks, too, but this is not where occam stands out,
>either.
I tend to agree insofar as Roger is referring to sequential languages with
library support for parallel processing added. Such function calls don't
provide the necessary level of abstraction for fine-grain parallelism,
and often cause an unacceptable overhead.
Now, without wishing to get dragged into yet another religious discussion
about programming languages or editors, I feel that I must point out
that the PACT Parallel C compiler has language extensions very similar
to those found in Occam (par, alt, channel) folded into ANSI Standard C
in a natural manner. This allows fine-grain parallelism to be expressed
just as easily as in Occam.
I agree with Roger that many communicating lightweight threads, buffers,
multiplexers etc., combined with a clean and powerful syntax to describe
them makes for a very nice programming model indeed. This model is now
accessible to both Occam and C programmers alike.
Best,
Rob
--
PACT Rob Kurver
Foulkeslaan 87 r...@pact.nl
2625 RB Delft ph: +31 15 616864
The Netherlands fax: +31 15 610032
Rob Kurver
>This article is in two parts, both are questions, the former being more of
>a discussion.
>In <1992Aug14....@EE.Surrey.Ac.UK> Roger Peel writes:
>Parallel
>enhancements to a sequential language might be acceptable for particularly
>large-grained parallel tasks, too, but this is not where occam stands out,
>either.
>In article <rob.714140217@dutncp8> r...@pact.nl (Rob Kurver) writes:
>Such function calls don't
>provide the necessary level of abstraction for fine-grain parallelism,
>and often cause an unacceptable overhead.
>In what way isn't occam good at large-grained parallelism?
I don't think either Roger or I were implying that Occam isn't good at
large-grain parallelism, but rather than sequential languages with a
library of parallel support functions hacked on to it aren't very good
at fine-grain parallelism. For fine-grain parallelism you want to be
able to say something like
/* PACT Parallel C */ /* Occam [sorry for any typos] */
par { PAR
a = b + c; a := b + c
f(); or f ()
x = 3; x := 3
}
instead of
/* C with library support */
void fn1 (void) { a = b + c; }
void fn3 (void) { x = 3; }
...
Process *p1, *p2, *p3;
p1 = ProcAlloc (fn1, ...);
p2 = ProcAlloc (f, ...);
p3 = ProcAlloc (fn3, ...);
ProcPar (p1, p2, p3, NULL);
I think the function approach is OK for large-grain parallelism, where a
program starts but a few threads at the start. Although a good network
configuration language that allows tasks to be placed and connected seems
a whole lot easier to use even then...
>Rob again:
>This allows fine-grain parallelism to be expressed just as easily as in Occam.
>Does it have the compilation checks too?
It has the normal C compilation checks (channel type etc.), but not
nearly as much as languages like Occam or Pascal. Many of these checks
become quite impossible in a language that allows modules to be compiled
separately and linked with libraries, and has pointers and the like.
Some checks are done at runtime (stack expansion), and others must be
coded explicitly by the programmer if s/he wants them. This is all in
the spirit of C, of course, and is considered an advantage by some and
a disadvantage to others. Just as one chooses between Pascal and C for
sequential programming, one must also decide between Occam and
PACT Parallel C for parallel programming.
As I stated in an earlier message, I don't want to get dragged into a
religious debate about languages, but merely want to point out that
there does exist a Parallel C compiler that provides more than a library
of functions, and allows parallel programs to be written as legibly and
efficiently as Occam. It does not provide the same level of compile-
time checking as Occam, but does give you structures, recursion, free
format source files and all those other things a lot of people have
got used to since the days of punch-cards.
W.G.Day
a discussion.
In <1992Aug14....@EE.Surrey.Ac.UK> Roger Peel writes:
Parallel
enhancements to a sequential language might be acceptable for particularly
large-grained parallel tasks, too, but this is not where occam stands out,
either.
In article <rob.714140217@dutncp8> r...@pact.nl (Rob Kurver) writes:
Such function calls don't
provide the necessary level of abstraction for fine-grain parallelism,
and often cause an unacceptable overhead.
In what way isn't occam good at large-grained parallelism?
Is the due to the machinery that has to be built to set up a pipeline,
geometric distribution or a processor farm?
The first two can be built simply, though without a great deal of efficiency.
Though there is an equivalent weakness in the data structure side of
programming languages. Linked lists and binary trees are effectively large
grain data structures and we have to continually build and re-build those.
Rob again:
This allows fine-grain parallelism to be expressed just as easily as in Occam.
Does it have the compilation checks too?
>Best,
>Rob
Warren