Open MPI logo

Hardware Locality Development Mailing List Archives

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

Subject: Re: [hwloc-devel] Hwloc perl binding
From: Bernd Kallies (kallies_at_[hidden])
Date: 2010-12-15 14:41:42


On Wed, 2010-12-15 at 14:56 +0100, Brice Goglin wrote:
> Le 15/12/2010 14:45, Bernd Kallies a écrit :
> > The CPAN thing is the third implementation, which works with objects and
> > accessor methods. It is as fast as the first implementation, and perl
> > code looks almost like C code (except that it is not possible now to
> > compare the hwloc_obj perl representatives by value).
>
> Could you add something like obj->id which would contain a unique id
> (the original C pointer?) that could be used to compare objects?

I added the global method hwloc_compare_objects($topo,$o1,$o2) with the
OO aliases $topo->compare_objects($o1,$o2) and $o1->is_same_obj($o2).
The method returns true or false, and also works with undef values. I
guess this is better than exposing the raw C pointer value as perl
integer.

I'll collect ideas like that, and will post a next Sys::Hwloc version
via CPAN.

> > In summary I'm very satisfied with this implementation. There remains
> > the question how one should handle structs like hwloc_obj_memory_s and
> > the like. In my implementation these are represented by perl hashes.
> > SWIG code would map them to perl objects. The difference is:
> > my: $obj->memory->{total_memory}
> > OO: $obj->memory->total_memory
> > The first variant is uncoupled from the hwloc_obj struct, and allows to
> > change values or store additional things in the hash.
> > The second variant may allow manipulation of the hwloc_obj struct in the
> > memory of the C lib, but does not allow to store additional properties.
> >
>
> I don't know which one is better.
>
> > In addition I noticed a lot of hwloc API functions that need a topology
> > pointer in their parameter list, which is unused in the function. Will
> > this become cleaned up in the future?
> >
>
> I'd say we have the topology parameter everywhere because the API looks
> more consistent and because we may need it in the future.
>
> Are you actually referring to the main API, or to inline helpers such as
> hwloc/helpers.h ? The latter are not strictly part of the API, and may
> be changed easily since they are not in the ABI.

It is not really clear to me what belongs to the main API, and what are
helpers. I'm referring to things like the following:

int hwloc_obj_attr_snprintf(char * __hwloc_restrict string,
                            size_t size,
                            hwloc_obj_t obj,
                            const char * __hwloc_restrict separator,
                            int verbose);

int hwloc_obj_snprintf(char * __hwloc_restrict string,
                       size_t size,
                       hwloc_topology_t topology,
                       hwloc_obj_t obj,
                       const char * __hwloc_restrict indexprefix,
                       int verbose);

The prototypes are in hwloc.h ("main" API ?). The true source of these
are in src/traversal.c ("helper" API ?). There the topology parameter of
hwloc_obj_snprintf has attribute unused. Things like that.

Bernd

> Brice
>
> _______________________________________________
> 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]