Open MPI logo

Hardware Locality Development Mailing List Archives

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

Subject: Re: [hwloc-devel] SWIG bindings
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2010-12-02 14:42:14

On Dec 2, 2010, at 11:07 AM, Bernd Kallies wrote:

> To implement a hash there
> exist two ways:
> a) the easy one: provide a new method like hwloc_get_obj_data(), that
> gets a "pointer" to the C object and returns a hashref. This would be a
> simple extension of my current implementation by leaving the children
> and parent pointers as-is to be used in future calls.

Do you mean that with this idea, you could do something like:

my $obj = hwloc_get_...($t, ...);
my $data = hwloc_get_obj_data($obj);
print Dumper($data);

$VAR = {
   type => HWLOC_OJB_CORE,
   os_index => 42,
   name => 'core number 42',

Something like that? (I typed that in email, so it's just an approximation) And then that would open the door to something like this:

my $child_obj = $data{child}[1];
my $child_data = hwloc_get_obj_data($child_obj);
print Dumper($child_data);

$VAR = {
   type => HWLOC_OJB_PU,
   os_index => 98,
   name => 'PU number 98',

Or are you saying something else?

> b) the complicated one: make the perl wrapper lib object oriented. One
> may translate a hwloc_obj_t struct into a perl object. This sounds
> straightforward at first sight, and indeed I started with this idea. But
> very soon I got stuck about what to do with the child and parent
> pointers and arrays. In the OO implementation these should also be perl
> objects. One ends up with representing the whole topology as perl
> objects once the topo gets loaded. In addition, one has to take care
> about circular references because of the perl reference counters, which
> makes all this very slow and clumsy.

Ah, yes, this is what I was thinking of. $obj{parent} would be a pointer to the object of the parent, and $obj{children} would be an array of pointers to the children objects. And so on.

Do you have much of a feel for how slow this would make it on your machines where lstopo is already expensive?

> In addition, in the OO
> implementation one should do true OO, that means one should implement
> object methods that access object data. The hwloc API is not of this
> kind.


> These were my ideas. Comments are welcome. Note that we have very big
> machines with complicated topologies. Executing lstopo (pure C API)
> takes up to a second there. It made no sense to me to slow this down
> more.

Also agreed.

Do you have any feel for if there are particular bottlenecks in hwloc / lstopo that make it take so long? I wonder if we should just attack those (if possible)...? Samuel and Brice have done all the work in the guts of the API, so they might know offhand if there are places that can be optimized or not...

Jeff Squyres
For corporate legal information go to: