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
