>At Thu, 21 Oct 2010 14:25:38 -0500,
>Brian Wood wrote:
>>
>> David Abrahams:
>> > Which yields huge performance benefits and makes practical some
>> > computations that might otherwise not be, due to resource constraints
>>
>> I've been exploring this further here -
>> http://www.gamedev.net/community/forums/topic.asp?topic_id=585405
>>
>> Also, from what I can tell, MPI messages are composed of one
>> data type or an array of one type.
>
> Maybe, but the library lets you easily make arbitrarily complex data
> types (described to MPI as MPI type maps).

Right, I don't deny that.

>
>> If that's the case, I'd argue there's room for more coolness.
>
>What more do you want?


Here's an example from my work.  I have a three-tier architecture:

C++ Middleware Writer  (server)
              |
C++ Middleware Writer Ambassador (server)
              |
command line program that exits


I'll introduce a struct that I don't currently use, but that might make
this easier to follow.

struct  RequestData
{
  uint32_t                   accountNumber;
  uint32_t                   transactionNumber;
  std::vector<File>      includeFiles;
  std::auto_ptr<File>   middleFile;
  uint32_t                   userOptions;
};


I could use that to send a message, but being forced
to receive those fields as a unit would be detrimental
to the implementation of the C++ Middelware Writer.
The account number is used to determine how the
files are received.  A directory is associated with each
account.  If I couldn't break the account number out of
there, I'd have to receive the files into a temporary
directory and then move them into the right directory
later and get rid of the temporary directory.

So I do it something like this:

struct  TransactionData
{
  uint32_t                   transactionNumber;
  std::vector<File>      includeFiles;
  std::auto_ptr<File>   middleFile;
  uint32_t                   userOptions;
};

That's the same as RequestData, but the account number
field has been removed.  This middle code describes
how the message is sent (@out) and received (@in):

(uint32_t, TransactionData) @out @msg_id_direct
(uint32_t) @in
(TransactionData) @in


The sending process sends 2 items as one message.  The receiving
process receives the message in two steps.  First it gets the
account number as a uint32_t which it uses to receive the balance
of the message.

I believe accomplishing the same thing with MPI would involve
two message ids (tags) and would require more work to be
certain that the messages are sent and received in the correct
order.  There's needless overhead associated with the additional
message id and the programming is more involved to make
sure everything is kosher.


--
Brian Wood
Ebenezer Enterprises
http://webEbenezer.net
(651) 251-9384