What to use FM for

FM's primary purpose is to deliver as much of the underlying network hardware's performance as possible to applications, even with one or more higher-level messaging layers in between.

The aim is for FM's performance to be comparable to that of the network hardware, and for messaging layers built atop FM to have comparable performance to FM. As a result, it is generally unnecessary to write directly to the FM interface (or modify FM) to get better performance.

However, there are still times when a programmer may need to use the FM interface directly:

higher-level messaging layers

While one could certainly layer new functionality atop the APIs provided with HPVM, FM is generally a better choice for implementing high-performance higher-level messaging layers than most interfaces. FM's streaming interface facilitates adding/removing message headers and trailers; FM can send (almost) arbitrarily large messages--even larger than available memory--without requiring higher layers to segment data; and FM provides flow control and buffer management, saving higher-level layers from that responsibility.

dynamic programs

As of this writing, FM is the only HPVM interface that supports dynamic programs (i.e. programs in which processes come and go during the course of the computation). So programs that require a dynamic process model (e.g. a client-server application) must currently be written to the FM interface.

special-purpose communication structures

Programs that communicate complex pointer-based data structures without marshalling and unmarshalling them may be more conveniently expressed with FM's streaming interface than with, say, MPI datatypes or a series of SHMEM puts and gets. Of course, the most "natural" interface is application-specific, which is why HPVM supports a variety of APIs.

Go to the first, previous, next, last section, table of contents.