Thanks.
src/mpi/pt2pt/waitall.c has both code and comments indicating that it
matters. The ideas for that code came from IBM
(14f8143312e0dfd5eafcaedda8a874f66b912d1a), which presumably means that it
helped on Blue Gene.
It is easy enough to measure message rate with and without an array of
status objects to understand this quantitatively.
Best,
Jeff
On Fri, May 27, 2016 at 6:40 AM, William Gropp <wgropp(a)illinois.edu> wrote:
>
> This was the motivation, more than avoiding declaring a variable that was
never read in the user’s program. There was evidence for this from Intel
in the early ‘90s, though I don’t know if anyone has looked into it
recently.
>
> Bill
>
> William Gropp
> Director, Parallel Computing Institute
> Thomas M. Siebel Chair in Computer Science
> Chief Scientist, NCSA
> University of Illinois Urbana-Champaign
>
>
>
>
>
> On May 26, 2016, at 6:30 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote:
>
> Is it correct to assume that it is cheaper to check for MPI_STATUS_IGNORE
and MPI_STATUSES_IGNORE than to fill in the status object, in the case
where the user does not need the status?
>
> Thanks,
>
> Jeff
>
> --
> Jeff Hammond
> jeff.science(a)gmail.com
> http://jeffhammond.github.io/
> _______________________________________________
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/devel
>
>
>
> _______________________________________________
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/devel
--
Jeff Hammond
jeff.science(a)gmail.com
http://jeffhammond.github.io/
This was the motivation, more than avoiding declaring a variable that was never read in the user’s program. There was evidence for this from Intel in the early ‘90s, though I don’t know if anyone has looked into it recently.
Bill
William Gropp
Director, Parallel Computing Institute
Thomas M. Siebel Chair in Computer Science
Chief Scientist, NCSA
University of Illinois Urbana-Champaign
On May 26, 2016, at 6:30 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote:
> Is it correct to assume that it is cheaper to check for MPI_STATUS_IGNORE and MPI_STATUSES_IGNORE than to fill in the status object, in the case where the user does not need the status?
>
> Thanks,
>
> Jeff
>
> --
> Jeff Hammond
> jeff.science(a)gmail.com
> http://jeffhammond.github.io/
> _______________________________________________
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/devel
Is it correct to assume that it is cheaper to check for MPI_STATUS_IGNORE
and MPI_STATUSES_IGNORE than to fill in the status object, in the case
where the user does not need the status?
Thanks,
Jeff
--
Jeff Hammond
jeff.science(a)gmail.com
http://jeffhammond.github.io/
On 05/15/2016 08:38 PM, Gilles Gouaillardet wrote:
> Folks,
>
> currently, mpich (master and previous releases) cannot be built on
> OpenBSD 5.7 and later.
> the root cause is 'struct statfs' has no f_type field.
>
> here is attached a patch that fixes that, and add some extra #ifdef
> protections
>
> this issue was initially reported at
> https://www.open-mpi.org/community/lists/devel/2015/05/17449.php and
> more recently at https://github.com/open-mpi/ompi/issues/1635
this has been committed to master. thanks for catching and reporting
the build error and making ROMIO's configure checks more robust.
==rob
Yes, TLB would be a concern, particularly because shared memory (mmap backed by a file) uses regular-sized pages, not large pages.
The shared memory pool is a bit messy because we have to remember how much memory in each page was already given away and deal with fragmentation, etc.
A simpler "optimization" might be to turn off noncontiguity after some number of window allocations.
-- Pavan
> On May 17, 2016, at 2:31 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote:
>
> I always ask for noncontig window allocations. I use as many RMA info keys as possible :-)
>
> I am not so worried about running out of VA bits, although 48 bits don't go as far as they used to, as I am about TLB slots.
>
> However, this problem can be solved above MPI, it just requires me to do it in every MPI-3 code I write.
>
> Jeff
>
> On Tue, May 17, 2016 at 12:20 PM, Balaji, Pavan <balaji(a)anl.gov> wrote:
>
> It does allocate from shared memory irrespective of the size. It's not page-aligned unless you ask for noncontig allocations. With respect to wasted VM space, you'll run out of window contexts much before you run out of VM space, so I'm not sure this is a worthwhile optimization.
>
> -- Pavan
>
> > On May 12, 2016, at 4:54 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote:
> >
> > If I call MPI_Win_allocate for e.g. 8 bytes, does it allocate shared memory every time, and thus potentially allocate with page alignment, which could cause a lot of empty VM space?
> >
> > Perhaps I do not understand POSIX shared memory well enough, but it strikes me that it might be a worthwhile optimization to have a memory pool for small-size MPI_Win_allocate(_shared) calls.
> >
> > Thanks,
> >
> > Jeff
> >
> > --
> > Jeff Hammond
> > jeff.science(a)gmail.com
> > http://jeffhammond.github.io/
> > _______________________________________________
> > To manage subscription options or unsubscribe:
> > https://lists.mpich.org/mailman/listinfo/devel
>
> _______________________________________________
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/devel
>
>
>
> --
> Jeff Hammond
> jeff.science(a)gmail.com
> http://jeffhammond.github.io/
> _______________________________________________
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/devel
I always ask for noncontig window allocations. I use as many RMA info keys
as possible :-)
I am not so worried about running out of VA bits, although 48 bits don't go
as far as they used to, as I am about TLB slots.
However, this problem can be solved above MPI, it just requires me to do it
in every MPI-3 code I write.
Jeff
On Tue, May 17, 2016 at 12:20 PM, Balaji, Pavan <balaji(a)anl.gov> wrote:
>
> It does allocate from shared memory irrespective of the size. It's not
> page-aligned unless you ask for noncontig allocations. With respect to
> wasted VM space, you'll run out of window contexts much before you run out
> of VM space, so I'm not sure this is a worthwhile optimization.
>
> -- Pavan
>
> > On May 12, 2016, at 4:54 PM, Jeff Hammond <jeff.science(a)gmail.com>
> wrote:
> >
> > If I call MPI_Win_allocate for e.g. 8 bytes, does it allocate shared
> memory every time, and thus potentially allocate with page alignment, which
> could cause a lot of empty VM space?
> >
> > Perhaps I do not understand POSIX shared memory well enough, but it
> strikes me that it might be a worthwhile optimization to have a memory pool
> for small-size MPI_Win_allocate(_shared) calls.
> >
> > Thanks,
> >
> > Jeff
> >
> > --
> > Jeff Hammond
> > jeff.science(a)gmail.com
> > http://jeffhammond.github.io/
> > _______________________________________________
> > To manage subscription options or unsubscribe:
> > https://lists.mpich.org/mailman/listinfo/devel
>
> _______________________________________________
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/devel
>
--
Jeff Hammond
jeff.science(a)gmail.com
http://jeffhammond.github.io/
It does allocate from shared memory irrespective of the size. It's not page-aligned unless you ask for noncontig allocations. With respect to wasted VM space, you'll run out of window contexts much before you run out of VM space, so I'm not sure this is a worthwhile optimization.
-- Pavan
> On May 12, 2016, at 4:54 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote:
>
> If I call MPI_Win_allocate for e.g. 8 bytes, does it allocate shared memory every time, and thus potentially allocate with page alignment, which could cause a lot of empty VM space?
>
> Perhaps I do not understand POSIX shared memory well enough, but it strikes me that it might be a worthwhile optimization to have a memory pool for small-size MPI_Win_allocate(_shared) calls.
>
> Thanks,
>
> Jeff
>
> --
> Jeff Hammond
> jeff.science(a)gmail.com
> http://jeffhammond.github.io/
> _______________________________________________
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/devel
If I call MPI_Win_allocate for e.g. 8 bytes, does it allocate shared memory
every time, and thus potentially allocate with page alignment, which could
cause a lot of empty VM space?
Perhaps I do not understand POSIX shared memory well enough, but it strikes
me that it might be a worthwhile optimization to have a memory pool for
small-size MPI_Win_allocate(_shared) calls.
Thanks,
Jeff
--
Jeff Hammond
jeff.science(a)gmail.com
http://jeffhammond.github.io/
