weak symbols

weak symbols

Dear Intel folks,

I am thinking of writing my own and very lighweight profiling tools and OpenMP is clearly in my radar.

I had a quick look at the source code trying to find how and where i could hook my profiler, and i could not find anything simple :-(

IMHO, the easiest way would be to use weak symbols.

This is what is done in MPI implementations : for example the user application will call MPI_Init. In the MPI library, MPI_Init is a weak symbol pointing to PMPI_Init. So instrumenting MPI_Init only requires to rewrite MPI_Init : do the instrumentation and call PMPI_Init. Then the application can be relinked or started with a preloaded library.

It would be great if for example __kmpc_barrier was a weak symbol.

Is there such a plan to use weak symbols ?

It is of course possible to play with preloads and dlsym but this is quite heavy weight and could be un-necessary.

Best regards,

Kiyo

10 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

There's no need to explain the MPI profiling system to me... I am the chapter author for that chapter of the MPI-1 standard, and it's my hack :-). While it works well for MPI, I don't think it's a good, general, approach for OpenMP, because the functions that you would need to intercept are not standardised, but are part of the interface between the compiler and the runtime. Therefore your tools would have to change for each different compiler.

There is a lot of work in profiling OpenMP, and providing interfaces that are portable between different compilers, including a draft standard that you can find at http://openmp.org/mp-documents/ompt-tr.pdf‎ . I have strong reason to believe that work is already underway to contribute support for this to the open-source runtime, so thinking about whether that interface would work for you may be more productive (and would then allow your tools to work with any OpenMP runtime that supported the interface, rather than being specific to the Intel runtime).

Of course, since you have the code, you can make the interfaces weak should you choose to, but, given the resoning explained above, it's unlikely that we'd be minded to accept patches to do that back into the mainline code.

Hi James,

Thanks a lot for the pointer to the OMPT and OMPD interface, and for the PMPI_* great hack as well :-)

I understand why there will not be any weak symbols in the Intel OpenMP runtime since this will be made unnecessary ... at some point in time.
My goal here is to instrument the commercial version of the Intel OpenMP runtime, and i browsed the source code of the free runtime in order to understand how i could achieve this (e.g. i have no plan to rebuild my own runtime).
That leads me to my next question : when will the (commercial) Intel OpenMP runtime implement the OMPT interface ?
/* or something quite similar : my understanding is that both OMPT and OMPD have been proposed for adoption, and it could take a while before they get eventually adopted, followed by another delay before it is implemented by Intel (and other vendors) */

Best regards,

Kiyo

Quote:

Kiyoaki M. wrote:

That leads me to my next question : when will the (commercial) Intel OpenMP runtime implement the OMPT interface ? 
/* or something quite similar : my understanding is that both OMPT and OMPD have been proposed for adoption, and it could take a while before they get eventually adopted, followed by another delay before it is implemented by Intel (and other vendors) */

I can't give a definitive product schedule here. What I can say is that if we recieve contribution from the Open-Source community to implement those interfaces in the runtime, and it passes our tests (including on performance on all our platforms), then we'll certainly release it as part of the commercial runtime that is packaged with our compilers. (Adopting code into the commercial package is not as easy as posting the source at github :-().

Since there is no such contribution available yet, and if it does arrive it'll have to fit into the compiler release schedule it's impossible to give a firm date.

Kiyo,

You might investigate to see if the implementations use a dispatch table for functors to the omp... runtime library. A DLL typically uses this technique, and I have seen static libraries using this as well. Should a dispatch table be used, then you could concievably hook your profiler into this table (same technique as hooking an interrupt or service). You may have to figure out the relationship between the vector at [n] and the function it dispatches to.

Jim Dempsey

Jim Dempsey

www.quickthreadprogramming.com

Quote:

jimdempseyatthecove wrote:

You might investigate to see if the implementations use a dispatch table for functors to the omp... runtime library. A DLL typically uses this technique, and I have seen static libraries using this as well.

There is no explicit table of functions in the runtime. So (assuming an ELF based system, not Windows) the only place you could hack this would be in the plt (the calls into the runtime are handled like any other call into a dynamic library). Messing with the plt seems a pretty large hammer, though, and not trivial to do by any means!

Hi Jim and James,

i am using Linux only, so i cannot speak about windows ...
i was able to wrap calls (well, i tried only __kmpc_barrier) to the OpenMP runtime library by generating my own library i preload before running my OpenMP enabled binary (which must have been linked dynamically versus the openmp runtime).
This was unelegant, not so trivial but this was no rocket science neither ...

Best regards,

Kiyo

Sure, you can do it with LD_PRELOAD too, and that is much easier than hacking the plt directly! (My comment was specifically answering Jim Dempsey, not discussing what the best overall solution would be :-))

Kiyo,

The preload (of your "filter") is a better way to do the hack then patching the dispatch table. Thanks for providing this hint.

A third possibility (untested), and very similar to your current hack, this would be to compile and link to the static OpenMP library, hower you provide the linker your hooks library with the same function names (similar to linking the dummy omp stubs), then inside the first hook called, perform a specific DLL load of the OpenMP library and then locate the entry points to fill in your vectors to the actual OpenMP routines.

Jim Dempsey

www.quickthreadprogramming.com

Quote:

James Cownie (Intel) wrote:

There's no need to explain the MPI profiling system to me... I am the chapter author for that chapter of the MPI-1 standard, and it's my hack :-). While it works well for MPI, I don't think it's a good, general, approach for OpenMP, because the functions that you would need to intercept are not standardised, but are part of the interface between the compiler and the runtime. Therefore your tools would have to change for each different compiler.

There is a lot of work in profiling OpenMP, and providing interfaces that are portable between different compilers, including a draft standard that you can find at http://openmp.org/mp-documents/ompt-tr.pdf‎ . I have strong reason to believe that work is already underway to contribute support for this to the open-source runtime, so thinking about whether that interface would work for you may be more productive (and would then allow your tools to work with any OpenMP runtime that supported the interface, rather than being specific to the Intel runtime).

Of course, since you have the code, you can make the interfaces weak should you choose to, but, given the resoning explained above, it's unlikely that we'd be minded to accept patches to do that back into the mainline code.

nice

[url=http://www.nile7.com/services]البيع والشراء [/url]

Leave a Comment

Please sign in to add a comment. Not a member? Join today