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 jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
