Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

From: Craig Rasmussen (crasmussen_at_[hidden])
Date: 2005-12-07 11:53:25


Begin forwarded message:

> From: Aleksandar Donev <adonev_at_[hidden]>
> Date: November 21, 2005 9:30:18 AM MST
> To: J3 <j3_at_[hidden]>
> Subject: (j3.2005) Re: Derived types according to MPI2
>
> Hello,
>
> Malcolm Cohen wrote:
>> Which just goes to show that the authors of MPI2 didn't understand
>> Fortran, since that is completely and utterly false in every sense
>> that matters.
> Yes, but the interesting thing is neither me nor Van were aware of
> what
> the standard actually allows in terms of derived types and the storage
> for the components, and presumably we know Fortran better. Can storage
> for the components be separated from the scalar derived type itself?
> This probably makes no visible difference for scalars, but for arrays
> it does. Again, I am asking about what STORAGE_SIZE for derived types
> should mean.
>
> Dan Nagle wrote:
>> Please be aware that the "external world" of the MPI standard
>> is really the virtual machine of the C standard.
> Yes, of course, I am certainly not proposing binding to hardware.
>
>> When defining a programming language, the "needless abstraction"
> I should have qualified with "some needless abstractions". Of course
> abstractions are good, especially when it does not matter to the user
> how something is done as long as it is done well. But if you want to
> pass an array of derived types to a parallel IO routine that is not
> compiled by your super-smart Fortran compiler that chooses to scatter
> the components across virtual-address space (yes, I mean virtual),
> then
> you do NOT want that abstraction.
>
> It is about choice. Leave preaching to the preachers. Programming is a
> profession for a reason---programmers are experienced and educated and
> understand the issues and don't need lectures on abstractions.
>
> Aleks