On Dec 2, 2010, at 4:25 PM, Bernd Kallies wrote:
> Your understanding was right. There may be a method hwloc_get_obj_data
> which returns a hasref containing (at least most of) the hwloc_obj_t
> struct members in a perl representation. The hwloc_obj_t struct members
> that are of type hwloc_obj_t would be still the C pointer values, which
> are meaningless outside the API.
Ok.
Per your comments below (that I snipped), it's a shame that doing the hash tree of objects is terrible. This is simply reflecting my bias how I've written perl scripts to read XML and C code to traverse the obj tree directly. But if it really does become performance inhibitive on large-core-count machines, then you're right and something else will have to be done (e.g., the "combo" method of hashes + accessor functions).
> Hmm. I did no profiling. The machines in question have 64 NUMA nodes
> with 16 logical CPUs, each. The topology depth is 10. So parsing
> of /sys/devices/system/node/* and evaluating the distance matrix to
> fiddle out the topology tree should be quite expensive. But I guess this
> statement is trivial and does not help very much.
If you ever get some time to compile hwloc with -g and run it through a profiler, that would be great. Maybe we can't avoid the overhead of traversing /sys/devices/system/node/*, but the data may point out some other inadvertent bottlenecks.
Thanks!
--
Jeff Squyres
jsquyres_at_[hidden]
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
|
![[Flag]](../../../../../community/mirrors/flag-us.gif){kind=small}