On Wed, 2010-12-15 at 13:32 +0100, Brice Goglin wrote:
> Le 15/12/2010 11:14, Bernd Kallies a écrit :
> > Dear all,
> >
> > the Perl module Sys::Hwloc is available via CPAN, see
> >
> > http://search.cpan.org/~bka/Sys-Hwloc-0.04/
> >
> > Comments are welcome.
> >
> > Ciao BK
> >
> >
>
> I am not very familiar with Perl packaging, but at least I like the
> syntax in the perl-lstopo code.
>
> Is this implementation the one that was causing the garbage collector to
> become very slow on your large machines?
No, it was rewritten completely.
The first implementation simply casted hwloc_obj pointers to perl
integers. This was what I posted to the mailing list initially. With
this it was possible to compare objects by pointer comparison like in C,
but it was not possible to access hwloc_obj struct members like in C.
Thatswhy I needed something like hwloc_obj_get_data($obj,$name) to
access them, which is very ugly.
The second implementation tried to mimick the whole topology tree as
tree of hash references. This was completely worse because of the
garbage collector. This is what you were referring to in your question.
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). No links between
the hwloc_obj perl representatives are constructed, so garbage
collection is not a problem.
At the end it turns out that this implementation yields something
similar to a wrapper that is constructed via recent SWIG. One probably
may use SWIG in the future, when it becomes clear how to handle API
changes, and how to retain the additional OO-ish things like
$topology->load or $obj->sprintf_cpuset, which I introduced in my
wrapper for convenience.
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.
Btw. I noticed that it may be nice to have a hwloc API function to
retrieve the API version at runtime. Currently there is only the
constant HWLOC_API_VERSION in hwloc.h, which is relevant at compile
time, only. Having a function would aid language bindings a lot, when
they are distributed outside of the hwloc distro. Then one is able to
check the version of the wrapper against the version of the used
underlying hwloc lib and croak if they are out of sync.
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?
Regards BK
> Brice
>
> _______________________________________________
> hwloc-devel mailing list
> hwloc-de...@open-mpi.org
> 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: kall...@zib.de
