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. Samuel
