>>>  MPI_File_open( MPI_COMM_WORLD, "foo.txt",
>>>             MPI_MODE_CREATE | MPI_MODE_WRONLY,
>>>             MPI_INFO_NULL, &fh );
>
>
> Since the file was opened with MPI_MODE_CREATE, shouldn't it have been
> truncated so the prior contents were removed? I think that's the root
> of the confusion here. It appears that MPI_MODE_CREATE doesn't cause
> the opened file to be truncated, but instead just leaves it "as-is".
>
> Is that correct?

I don't know whether this is the correct behavior, but it is the
correct origin of my confusion.
I suspected this would be attributed to the standard, but it is
contrary to what I'm used to with C's fopen:
I expected MPI_File_open( CREATE | WRONLY ) to act like fopen("w").

> Now if I may provide a word of caution:  please think extra-hard if
> you want to use shared file pointers.  They are implemented for
> correctness, but not for performance.  You will likely see much better
> performance if you use MPI_EXSCAN to compute every MPI process's
> offset
> into the file (I presume each process is writing a variable number of
> bytes, or you wouldn't consider ordered mode in the first place,
> right?) and then do an MPI_FILE_WRITE_AT_ALL to carry out the
> I/O collectively.
>
> Follow up if that didn't make any sense to you.  I can provide
> examples if need be.
>
> ==rob

Thanks, Rob, for the tip. I don't have enough experience to know which
functions are fastest. The shared pointer just looked like the easiest
thing for me to code. This should be pretty easy for me to change.

-Brian

Reply via email to