Le 12/01/2011 13:16, Samuel Thibault a écrit :
> Thanks for the summary!
>
> 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?
>
How would you store the following types of distance information ?
1) latency
2) bandwidth
3) number of hops
4) interconnect graph and/or routing table
(1) and (2) can go in the same float array. (3) can go in a float or
integer array. (4) needs more work.
I see three ways:
1) the distance structure contains latency fields, bandwidth fields, ...
whatever we ever need to add... possibly making a very long list of
distance information.
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...
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).
Brice
