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