On Aug 24, 2012, at 09:06 , Brice Goglin <brice.gog...@inria.fr> wrote:
> hwloc_obj_t already has a "void *userdata" for this. But we cannot store
> it in XML unless we know what it contains.
Contiguous binary structures with a known size can be stored in a XML file.
Instead of forcing the upper level to store their meaningful information as
arrays of one of a few predefined types, let them deal with the content of the
binary object, and focus on preserving the binary objects in the XML structure.
> Exporting to XML is strictly required here since people want to add
> values to the XML topology in a preliminary benchmarking programs, and
> later read it back in their actual application (a charm++ scheduler).
XDR exists for ensuring consistency. Let them store what they want not just
arrays.
george.
>
> Brice
>
>
>
> Le 24/08/2012 15:00, George Bosilca a écrit :
>> If the goal is to allow extra storage for the users why not a simpler
>> solution where all info keys are void* and the users manage their content?
>> Having multiple keys will allow several layers of the software stack to save
>> their own custom values without collisions, while the void* make a good
>> generalization of the stored information.
>>
>> George.
>>
>>
>>
>> On Aug 24, 2012, at 7:09, Brice Goglin <brice.gog...@inria.fr> wrote:
>>
>>> 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
>>>
>>> _______________________________________________
>>> hwloc-devel mailing list
>>> hwloc-de...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>> _______________________________________________
>> hwloc-devel mailing list
>> hwloc-de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
>
> _______________________________________________
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
