Fawzi Mohamed, le Tue 29 Sep 2009 17:39:17 +0200, a écrit :
> so that in the future one could avoid storing it at least in the
> deepest levels where it is easy and relatively cheap to generate (and
> where one would have the largest savings).
Even the deepest levels would have a L1 cache level on top of maybe just
at most 4 threads. Here we only save the "children" pointers, which is
not so many, compared to the siblings & cousins pointers, I'm not sure
it is really worth the pain of defining a long series of functions.
> I would say that for most operations (cpuset, next_sibling,...) using
> functions that get a hwloc_obj_t (and if needed also a topology) and
> return what requested is the way to go.
That means a long series of functions, I'm not sure it's really clearer
for the user. obj->father looks to me easier to read than
hwloc_obj_father(obj), particularly in complex expressions.
> I suppose that most of these operations are not performance critical.
I wouldn't suppose this actually. Detection time is probably not
performance critical, but it could be useful to make browsing the
topology very efficient.
> ok, I was thinking that maybe you did/would like to provide in the
> future something akin to what opensolaris does with locality groups
Yes, we intend to provide something similar.
> In fact what I "need" (or at least I think I need ;) is just the next
> neighbors, basically I go up the hierarchy, and look which new
> neighbors I have, so some hierarchy like the lgroups is close to what
> I need, and simpler to handle than the full graph.
That's what future heuristics would build for you, yes.