This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
On Thu, 2010-12-02 at 10:28 -0500, Jeff Squyres wrote:
> This looks great! Probably much better than SWIG-based bindings that I would have come up with.
> One question: is there any value in having the $topology be a hash of public values instead of using the hwloc_get_obj_data() method? I ask because in all the perl scripty-foo that I've written that parses "lstopo -.xml", having the entire data structure available as a big hash has turned out to be quite useful, particularly on some heterogeneous development machines where the hwloc accessor functions can be misleading, or may require more logic than just trawling the data tree directly.
I had to write this wrapper in two days because we needed this quickly
to handle our new SGI UltraViolet Machines (1024 logical cores per rack
with several levels of NUMA).
However, I thought about providing the members of the hwloc_obj_t struct
all at once in a hashref, but it turned out that this is not so easy
because of the pointer interface of hwloc. 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.
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. 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
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
> On Dec 2, 2010, at 4:25 AM, Bernd Kallies wrote:
> > Hi,
> > I have a perl-wrapper lib for hwloc based on hwloc-1.0.2. It is written
> > manually because of the pointer things. However, the lib is not
> > complete. I use it mainly for discovering topologies. Supporting pinning
> > does not make sense for perl scripts to my opinion
> > I'm thinking about either submitting this to CPAN or to the hwloc dev
> > team. However, I first wanted to wait how things with hwloc 1.1 will
> > look, when the dust has settled somehow.
> > Any hints or ideas?
> > Attached you find the man page.
> > On Tue, 2010-11-30 at 11:07 -0500, Jeff Squyres wrote:
> >> Would anyone object if I take a whack at making some SWIG bindings for hwloc? I'm thinking specifically for perl (because that's my scripting language of choice), but I could probably be convinced to look at python as well.
> >> (this would be for 1.2 at the earliest -- definitely not for 1.1)
> > --
> > 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]
> > <Hwloc.txt>
Dr. Bernd Kallies
Konrad-Zuse-Zentrum für Informationstechnik Berlin