Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Hardware Locality Development mailing list

Subject: Re: [hwloc-devel] distances branch
From: Samuel Thibault (samuel.thibault_at_[hidden])
Date: 2011-01-17 12:53:00


Hello,

Brice Goglin, le Mon 17 Jan 2011 10:12:21 +0100, a écrit :
> Le 12/01/2011 13:16, Samuel Thibault a écrit :
> > Brice Goglin, le Tue 11 Jan 2011 17:38:00 +0100, a écrit :
> >> More thinking needed here, and it may make us revise the
> >> "latency" names in the above "struct hwloc_distances_s".
> >>
> > Why?
>
> 2) the distance structure contains float fields, integer fields, ...
> whatever we ever need to add... probably not a very long list. if we
> ever get latency + bandwidth at the same time for the same objects, we'd
> need two distance structures for the same objects (already supported).
> if ever get latency + interconnect graph at the same time, we can store
> them in the same distance structure...

Looks hairy, yes :)

> 1) the distance structure contains latency fields, bandwidth fields, ...
> whatever we ever need to add... possibly making a very long list of
> distance information.

> 3) the distance structure contains a union instead of the list in (1).
> and we have one distance structure per type of distance info.
>
> I think I woudl vote for (3). We would to replace the current
> obj->distances[X]->latency{,_max,_base}
> with
> obj->distances[X]->type = LATENCY
> obj->distances[X]->values.latency.{matrix,max,base}
> (better names for "values" and "matrix" are welcome).

Mmm, in the end they are not so far apart: in 1) distances_s enumerates
the kind of measures you may have, and in 3) distances_s contains a
union which enumerates the kind of measures you may have. The difference
would mostly be in the way to obtain the information:

- with 1) once you get to the distances_s to some level, you can start
  browsing latencies, bandwidths, graph, etc., while with 3) you have to
  look again in the distances array for the other information.
- 3) needs a lot of .stuff.bar.thing which makes code less readable.
- 3) saves some room by only allocating storage for the available
  information. 1) can already avoid the matrices which is most of the
  room, however.

In the end I think I'd prefer 1).

Also, from an ABI point of view, I'm realizing that hwloc_obj_t should
rather contain a struct hwloc_distances_s **distances rather than just
struct hwloc_distances_s *distances, so that the hwloc_distances_s
structure can grow as needed.

Samuel