Open MPI logo

Hardware Locality Development Mailing List Archives

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

Subject: Re: [hwloc-devel] merging the valarray branch (with a better name)
From: Brice Goglin (Brice.Goglin_at_[hidden])
Date: 2012-08-24 07:09:26


Le 24/08/2012 11:46, Jeff Squyres a écrit :
> On Aug 24, 2012, at 4:26 AM, Brice Goglin wrote:
>
>> The question that remains is about the naming. Right now, it's
>> "valarray" but it don't like it. What it really means is "custom array
>> of float values". Maybe just "values", or "floats", or "custom floats",
>> or ... ?
>
> Random question: why floats and not doubles?

Likely because we have floats in the distance matrices but it didn't
matter for this use.

> Another name suggestion: cached_floats (cached_doubles)

It's not really about caching, it's more about annotating the topology
by merging multiple inputs together (XML topology + benchmark outputs +
application info) inside the same XML file.

> If the goal is to be able to store some data that will also show up in the XML (and text/gui output?)

I don't plan to display any of this to lstopo.

> , why not make the mechanism more general? E.g., the values array should be a union, with an enum indicating its type, and support a small number of intrinsic types: float (or double), string, int (and/or long?).
>

I thought about that but I wasn't sure it was worth doing it. When you
say type, are you talking about the type that appears in the array of
values, or about the global annotation type?

I though about doing this

struct values {
  char *name;
  type /* FLOATS or something else in the future */
  union {
    floats {
      unsigned nr;
      unsigned *indexes;
      floats *values;
    };
  };
};

This is vague enough to support other kinds of annotations (even if I
don't expect many additions). Ideally, we would merge the "info"
attribute into this, but it would break the ABI (because of the
get_info_by_name() inline function).

You're talking about this instead?

struct values {
  char *name;
  type /* DOUBLE or ULLONG */
  unsigned nr;
  unsigned * indexes;
  void * values; /* sizeof(type) * nr */
};

This one is easy to implement. Not sure if we would want
float/double/int/long/ulong/llong/... or only double/ullong. I just need
something clear enough for importing/exporting as string in the XML output.

String is really needed since we have info attributes. It's not an
array, but I don't think it matters much.

Brice