Subject: compiler target (was Be brave. Be sure.)

From: [email-masked] (Harry Berryman)
Date: Fri, 5 Feb 1993 22:04:16 -0500

Tony says:
  To follow up on Stephen's comment, I do not believe that compilers would
  make good use of this standard.  Active-message-level programming seems
  a much better level for standardizing compiler interfaces.

There are some compiler folks who might disagree with you. The 
group at Rice is working on generating message-passing, as well as the
group at Syracuse, U. Maryland, and a few other places. Perhaps 
you could be more specific as to why you think that compilers cannot
make good use of this standard?

-scott berryman

---

From: Tony Skjellum <[email-masked]>
Date: Fri, 5 Feb 93 22:20:29 CST

Yes Scott, I can be more specific.  I think that MPI[1] is not interesting
for compiler writers.  Active messages are finer grain message
passing, which have lower overhead.  There is naturally a larger overhead
in a full system call like a send()/recv() pair.  If the compiler knows
it wants to drop a single real number on a process, it could use a finer
grain mechanism.    

Compilers would be good at cacheing limited open channel resources, such as
supported at the low-level by CMMD.  Thus, they could take advantage of
not having to build up and tear down connections between processes, as 
is needed for send()/recv().  A good example of this is neighbor communication
for boundary sharing in domain decomposition.  They could take advantage
of special properties of the network(s) of a system, that are lost when
a robust send()/recv() mechanism is provided, each of which implies a
library [if not system] call.  The overhead of a subroutine call send()/recv()
implies a minimal granularity, because stack frames must be assembled, etc.

The compiler itself could be responsible for the non-deadlock properties
of the communication, rather than insisting that the messaging calls provide
this capability.  Furthermore, compilers could make use of the "force
semantics" per Intel, but still provide the user with a guarantee of 
correctness (ie, use the cheapest calls, but build their own appropriate
protocols, but as weak as possible).  

Mixing communication and computation is another example of where the
messaging libraries with send/recv semantics are too heavy duty, compared
to active messages.  A compiler might want to add two values and store
them remotely.  It does not need a full stack of messages, with rendezvous
to accomplish this.  

I think the people who are building compilers to generate straight
message- passing code should read the work from Berkeley and TMC on
active messages (Culler et al).  and build compilers that generate code
using these excellent ideas.  Performance will be superior.
Message-passing libraries are for people who write explicit
message-passing code without the benefit of compiler support.  They
need guarantees like non deadlock of messages, they need queues so
messages are there when you look for them, and so on.  Compilers can
manage these things, and avoid the necessary compromises made to
present robust message passing to users through send/recv.

It is difficult to cope with the many sequential calls that occur in
message passing code, without the need to build things like send+recv,
in order to reduce overhead.  Compilers could optimize away such overheads
if they controlled the messaging resource directly (ie, stamp out
unneeded overheads).  Also, they could
inline conversions for heterogeneity, and reduce the number of copies
of messages by driving the network as they convert data (or just drive
the network as they build parts of a message).  Furthermore, they could
balance the work done by sender and receiver based on the relative power
of the sender and receiver to do conversions.  This gets quite complex
for hand-written message passing code.

Active messaging can also be standardized  (eg, create MPI-AM)
to provide portable code to
machines which are message passing, and which are hierarchically shared
memory.  So, one could build a model that unifies machines like the
Paragon, CM-5, and Cray Tera, for the purpose of compiler code generation,
though these are different machines, to be sure.

- Tony