Open MPI logo

Hardware Locality 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.

Subject: [hwloc-devel] structure assumptions, duplication
From: Fawzi Mohamed (fawzi_at_[hidden])
Date: 2009-09-29 10:39:47

I have began to use hwloc, and I found it quite nice to use, but I do
have some comments and questions:

1) redundancy: for several operations, looping there are several ways
to to the same thing.
it is nice support several paradigms, but these occupy space and will
be very difficult to remove once used by user (in particular I don't
want that my code breaks ;).
Maybe I worry too much, but with machines with 1'000 of processor
coming, and maybe wanting local restricted copies to know the topology
of the whole machine (to communicate with others) I worry also about
few pointers here an there.

In particular I think about
arity+childrens vs first_child last_child
even cousins and siblings could probably share their pointers (at the
cost of needing a different check for the end), one could even link
them in a circular way (again stop for al loop would need to be
different then).

So are these things likely to change in the future, and if yes what is
the best way to code in a future proof way? Use hwloc_get_obj_by_depth
as much as possible?

2) assumption on the structure

 From the documentation and some functions/ single father, seems
that the structure returned is always strictly hierarchic, and that
starting from the leaf going up one goes through all possible levels,
and that each level is a partition.
Is that really so? At least the Misc object would seem to not fit in
this clean hierarchical picture.
Also a ring like topology cannot be cleanly represented with a
partition if one wants to have objects for groups with uniform latency.

So I wanted to know how you cope with those things, and also if
something will probably change in the future, as some assumptions will
inevitably creep in my code... and I would prefer to make the good
ones :)

thank you very much