Re: [hwloc-devel] Embedding: is it worth it?
Jeff Squyres, le Fri 02 Apr 2010 12:32:35 -0400, a écrit : > But to use an external PLPA/libltdl/whatever, OMPI's configure would just > call their configure ?! I'm not 100% sure what RedHat etc. do, but in Debian the policy wouldn't be to do this, but to just link against the existing installed library, i.e. use the installed hwloc.pc file only, _not_ run its configure script. I believe that's what RedHat etc. mean. Samuel
[hwloc-devel] Embedding: is it worth it?
The total amount of time I've spent getting hwloc "embeddable" has been fairly large. Most recently, I've spent almost the full past 2 days making hwloc embeddable in Open MPI. I'm wondering -- is it worth it? What's fueling this is that over the past 2-3 months, I've gotten emails from various BSD maintainers and from RedHat saying that they *don't* want to use the PLPA/libltdl/whatever embedded in Open MPI -- they want to link against their system-installed version. Which makes perfect sense from their point of view and quite reasonable of them to ask me to support. The obvious thing for Open MPI to do is to provide a configure switch that allows selecting to use the embedded version or an external one (the same exact situation will occur with hwloc; this is why I bring it up). But to use an external PLPA/libltdl/whatever, OMPI's configure would just call their configure -- no m4-isms would be involved, nor would any symbol shifting occur. So this would make 2 different code paths through the configure/build system -- one that uses m4 and one that invokes another configure script. So I find myself in the uncomfortable position of asking: is all this m4 embedding stuff worth it? Bear with me while I think out loud... + = PRO: a good thing - = CON: a bad thing Embedding gives us two main things: 1. "Seamless" configure magic + The outer configure can slurp in the relevant m4 from hwloc and call it directly (vs. hwloc's configure repeating a bunch of tests [e.g., look for $CC]) - It's not entirely seamless; the outer configure MUST to call AC_USE_EXTENSIONS (etc.) very early on, etc. - It is a ton of development work (for hwloc) to make this work + 95% of this ton of work is already done - ...but it may be a non-trivial amount of work to maintain (this is an unknown quantity) 2. Symbol shifting (hwloc_foo -> my_prefix_hwloc_foo) + Prevents clashes when a package needs a specific hwloc version (E.g., OMPI needs hwloc vX.Y, system has vA.B) + Allows multiple layers in the same app to link against different hwloc versions - Requires upkeep of include/hwloc/rename.h I think the symbol shifting is genuinely useful, despite the annoyance of maintaining rename.h. I'm questioning how useful the m4 embedding is, particularly if OMPI -- and any other distro-supplied software -- is going to have to support compiling and linking against external hwloc instances. I'm wondering if I could accomplish everything I need for OMPI by simply invoking $path_to_hwloc/configure with the existing hwloc configure switches: --enable-embedding-mode: only build libhwloc_embedded.la (no utils, etc.) and don't install *anything* --with-hwloc-symbol-prefix=: symbol shift all hwloc types and functions I almost wrote "public" types and functions -- but if compiler visibility functionality isn't available, then we need to shift all private-but-not-static symbols, too (I added a chunk to rename.h this afternoon for that). There probably isn't much I would remove from the configure stuff at this point if we gave up the m4-embedding capability. But there probably are a few things that I might simplify (i.e., they were done the way they were done specifically to enable embedding the m4 stuff). So the net "win" of not supporting m4 embedding might be a little simplification and a zero maintenance effort over time -- vs. keeping what is done and maintaining it over time. Thoughts? -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
Re: [hwloc-devel] comments on API changes
Fawzi Mohamed, le Fri 02 Apr 2010 17:34:20 +0200, a écrit : > would be fine with me, planning to add al lot of flags? because there > is still lot of space to grow (and one can later switch to 64 bit... :) Just switching to 64bits would break the ABI. It's better to just use chars and be done with the ABI :) > >>HWLOC_OBJ_SYSTEM seems on the way out > > > >It isn't :) > > > >>I treated it just as a MACHINE anyway, > > > >What do you mean by this? They really are not supposed to be the > >same, > >as Brice explained. > > I understand, but in the end I am just interested in building a > structure to have a sequence where you first look at neighbors, and > then further and further away, so I use both just as a way got keep > together things that have the same "distance". Mmm, I don't understand. Why would you need to have a look at the type? Can't you test the parent pointer to know whether you got at the top of the hierarchy? Samuel
Re: [hwloc-devel] comments on API changes
On 2-apr-10, at 16:17, Samuel Thibault wrote: Fawzi Mohamed, le Fri 02 Apr 2010 14:38:26 +0200, a écrit : I would take advantage more info about the possible numa node connectivity (to know where to steal tasks), This is on the TODO list, although (as Brice mentioned) OS often do not provide such information. Thanks for the comments! thank you for your answers, I don't post often here, but I always had good answers/discussions with you Brice and Jeff... Fawzi
Re: [hwloc-devel] comments on API changes
On 2-apr-10, at 16:16, Samuel Thibault wrote: Fawzi Mohamed, le Fri 02 Apr 2010 12:34:58 +0200, a écrit : flags attributes: C bitfields are used, normally they are avoided because they are slow (a compiler can bit or at compile time the constants and check/set several at once. Speed is not a concern here, but in any case I am wrapping to D that does not support bitfields directly, so I used flags, I was just wondering why bitfields were used... Mmm, thinking twice about it. As Brice mentioned, this is not really performance-critical. But since it's not performance-critical, it is probably not a problem to just use chars here. Also, maybe we can use a level of pointer to avoid any ABI issue when adding fields? would be fine with me, planning to add al lot of flags? because there is still lot of space to grow (and one can later switch to 64 bit... :) HWLOC_OBJ_SYSTEM seems on the way out It isn't :) I treated it just as a MACHINE anyway, What do you mean by this? They really are not supposed to be the same, as Brice explained. I understand, but in the end I am just interested in building a structure to have a sequence where you first look at neighbors, and then further and further away, so I use both just as a way got keep together things that have the same "distance". It is not strictly correct, but seems to work well in practice... Fawzi
