Open MPI logo

Hardware Locality Development Mailing List Archives

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

Subject: Re: [hwloc-devel] perl bindings
From: Bernd Kallies (kallies_at_[hidden])
Date: 2011-01-21 12:31:16


On Fri, 2011-01-21 at 17:09 +0100, Samuel Thibault wrote:
> Bernd Kallies, le Thu 20 Jan 2011 20:35:04 +0100, a écrit :
> > On Thu, 2011-01-20 at 20:22 +0100, Samuel Thibault wrote:
> > > Bernd Kallies, le Thu 20 Jan 2011 20:13:03 +0100, a écrit :
> > > > The only thing I was wondering about are these OO method names, which I
> > > > had to invent them myself. If there is some need to synchronize these
> > > > with the python binding, we may agree about them. Backwards
> > > > compatibility of the Perl binding is not a real problem, since there may
> > > > be many aliases for a function in the base XS code.
> > >
> > > Could you perhaps list those you have defined already, if any?
> >
> > See
> >
> > http://search.cpan.org/~bka/Sys-Hwloc-0.10/lib/Sys/Hwloc/Topology.pod
> > http://search.cpan.org/~bka/Sys-Hwloc-0.10/lib/Sys/Hwloc/Obj.pod
> > http://search.cpan.org/~bka/Sys-Hwloc-0.10/lib/Sys/Hwloc/Cpuset.pod
> > http://search.cpan.org/~bka/Sys-Hwloc-0.10/lib/Sys/Hwloc/Bitmap.pod
>
> Well, I meant the ones for which you had to invent a name. These are
> mostly the same as the C interface, hwloc_ prefix stripped. Are there
> names that don't exactly map to a C function? I see there is a "not in
> hwloc" section, I guess it is supposed to contain them all?

Yes, most of the OO methods are named like the C function with hwloc_ or
hwloc_topology_ prefixes stripped. Sometimes _get_ was stripped, when it
sounds better, e.g.

$->depth instead of $t->get_depth

Sometimes words are reversed, like

hwloc_obj_type_sprintf($o) but $o->sprintf_type
hwloc_obj_sprintf($t,$o) but $t->sprintf_obj($o)

There also exist functions that operate with hwloc_obj_t and have a
hwloc_topology_t as first argument, but it is unused. So I decided to
put these functions in the Sys::Hwloc::Topology and in the
Sys::Hwloc::Obj namespaces, e.g.

hwloc_obj_is_in_subtree($t,$o1,$o2)
$t->obj_is_in_subtree($o1,$o2)
$o1->is_in_subtree($o2)

>
> > HWLOC_XSAPI_VERSION always returns a version number (may be 0)
>
> Ok
>
> > HWLOC_HAS_XML flag if hwloc was built with XML support
>
> Why do you need it? At worse the xml functions would fail.

This is to be able to decide if coded calls of xml functions in a perl
script should be executed or not. If the C lib was generated without
xml, then the wrapper does not contain the wrapper functions. So the
symbol table of a perl script is different. If one has a perl script
that calls these functions, then it will not byte-compile. The
HWLOC_HAS_XML constant can be used much like an #ifdef in C to provide
alternatives for a perl script without having different scripts for
every variant. It may be nice for C programmers to provide the value of
the HWLOC_HAVE_XML cpp constant in hwloc.h for the same reason.

> > hwloc_compare_objects compares two Sys::Hwloc::Obj by C pointer value
>
> Ok.
>
> > hwloc_bitmap_ids returns bitmap bits as list of decimal numbers
>
> That seems perl-specific indeed.
>
> > hwloc_bitmap_list_sscanf parses a list format cpuset ASCII string
> > hwloc_bitmap_list_sprintf outputs a list format cpuset ASCII string
> > hwloc_bitmap_includes reverse of hwloc_bitmap_isincluded
>
> I guess these could be added to the C API?

Brice said that he tries to add the _list_ things in hwloc 1.2.

>
> > http://search.cpan.org/~bka/Sys-Hwloc-0.10/lib/Sys/Hwloc.pm
>
> Ok, that perl I can read :)
>
> I'd say you shouldn't care about providing all the hwloc_cpuset_*
> functions, since these names are deprecated in the C API.

Currently the wrapper compiles with hwloc 0.9 .. at least 1.1, and
generates different version dependent codes from the same source. The
cpuset API functions are only provided when one compiles the wrapper
against hwloc 1.0. With 1.1 they are not provided.

> > $mapa = hwloc_bitmap_dup($map)
>
> Same issue as in Python: when a const bitmap is returned by a hwloc
> function, the user shouldn't be able to modify it.

Hard to implement. In C this is achieved with prototypes via the C
compiler. There exists no such pendant in Perl. One would have to work
with proxy objects that have a readonly attribute, and maintain this.

> > hwloc_bitmap_from_ulong($set,$mask)
> > hwloc_bitmap_from_ith_ulong($set,$i,$mask)
> > hwloc_bitmap_set_ith_ulong($set,$i,$mask)
> > $val = hwloc_bitmap_to_ulong($set)
> > $val = hwloc_bitmap_to_ith_ulong($set,$i)
>
> Same issue as in Python (but with different answer): AIUI, perl doesn't
> have unbound integers, so has a limitation, but is possibly not exactly
> like C longs. I guess these should just use the regular perl integer
> name and size?

Internally perl handles integers as long or ulong. The problem with
wrappers is the correct cast between the content of a perl scalar (may
be a long or ulong or string or double or ...) and the needed C type.
I'll check what happens when one reaches UINT_MAX and the like.

> About area membind, same remark as for python: if someone uses perl to
> drive C-library computations, it may be useful, but else it probably
> doesn't make sense in pure perl.

Agreed, thatswhy these functions are currently not in the perl wrapper.

> Samuel
> _______________________________________________
> hwloc-devel mailing list
> hwloc-devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel

-- 
Dr. Bernd Kallies
Konrad-Zuse-Zentrum für Informationstechnik Berlin
Takustr. 7
14195 Berlin
Tel: +49-30-84185-270
Fax: +49-30-84185-311
e-mail: kallies_at_[hidden]