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
> http://opensolaris.org/os/community/performance/mpo_overview.pdf

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.


Reply via email to