|
From: Christoph S. <chr...@gm...> - 2011-08-16 16:42:14
|
Hi all, I'm evaluating cost of different implementations for a particular algorithm using callgrind. However, the cost seems to include overhead from valgrind itself, such as malloc & other hooks. (I see in the call graph that malloc calls "malloc_hook_ini" once with a cost of around 60,000 Ir. Having only one a few mallocs in a particluar algorithm this overhead greatly distorts test results. A second problem are symbol resolutions in the C library. Apparently '_dl_runtime_resolve' is called once for each symbol used from the C lib (such as sprintf). This is also unwanted overhead. a) How can I inhibit installation of malloc (and similar hooks)? b) Why are those hooks installed when running callgrind anyway, the prupose of callgrind is not memory error debugging. c) Are there other ways to automatically subtract or exclude this overhead from the test results? (I can use --toggle-collect but I do not want to specify each individual hook, and for _dl_runtime_resolve it does not seem to work properly as on resolve can call another) thanks, Chris |
|
From: WAROQUIERS P. <phi...@eu...> - 2011-08-30 10:50:28
|
>However, the cost seems to include overhead from valgrind itself, such >as malloc & other hooks. >(I see in the call graph that malloc calls "malloc_hook_ini" >once with a >cost of around 60,000 Ir. >Having only one a few mallocs in a particluar algorithm this overhead >greatly distorts test results. > >A second problem are symbol resolutions in the C library. Apparently >'_dl_runtime_resolve' is called once for each symbol used from >the C lib >(such as sprintf). This is also unwanted overhead. Are you sure these hooks are from valgrind ? I think there are rather from glibc and similar, and callgrind properly shows that your code (indirectly) implies these calls. (I did a grep for malloc_hook_ini on recent Valgrind sources, and found no hit in .c or .h files). Philippe ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender. |
|
From: Christoph S. <chr...@gm...> - 2011-08-30 16:51:47
|
On 30/08/2011 3:50 AM, WAROQUIERS Philippe wrote: >> However, the cost seems to include overhead from valgrind itself, such >> as malloc& other hooks. >> (I see in the call graph that malloc calls "malloc_hook_ini" >> once with a >> cost of around 60,000 Ir. >> Having only one a few mallocs in a particluar algorithm this overhead >> greatly distorts test results. >> >> A second problem are symbol resolutions in the C library. Apparently >> '_dl_runtime_resolve' is called once for each symbol used from >> the C lib >> (such as sprintf). This is also unwanted overhead. > Are you sure these hooks are from valgrind ? > I think there are rather from glibc and similar, and callgrind properly > shows that your code (indirectly) implies these calls. > > (I did a grep for malloc_hook_ini on recent Valgrind sources, and found > no hit in .c or .h files). > Probably not. I now believe that all those unwanted calls are to blame on the C library and dynamic loader. There were many unwanted calls to functions like '_dl_runtime_resolve', '_dl_addr' and the like. Looking at my call graph again, 'malloc_hook_ini' calls 'ptmalloc_init' which calls '_dl_addr', and the cost of 60,000 Ir is due to '_dl_addr'. I solved all those problems by using static linkage. Chris |
|
From: Josef W. <Jos...@gm...> - 2011-09-01 12:07:08
|
Just some followup... On Tuesday 30 August 2011, Christoph Schwarz wrote: > On 30/08/2011 3:50 AM, WAROQUIERS Philippe wrote: > >> However, the cost seems to include overhead from valgrind itself, such > >> as malloc& other hooks. ... > > Are you sure these hooks are from valgrind ? ... > Probably not. I now believe that all those unwanted calls are to blame > on the C library and dynamic loader. This has nothing to do with Valgrind/Callgrind. For every binary using shared libs, relocation/resolving of symbols has to be done at some point in time, and with the calls to _dl_* you see what this involves (e.g. calls to runtime_resolve for lazy binding of functions from shared libs). But this is nothing really "unwanted", and this cost should be visible with every profiling tool. However, often, the overhead is neglectable, unless you have a huge number of relocations to do. And yes, linking statically is often the right solution (but not really feasable to do with every KDE/GNOME binary). Josef > There were many unwanted calls to > functions like '_dl_runtime_resolve', '_dl_addr' and the like. Looking > at my call graph again, 'malloc_hook_ini' calls 'ptmalloc_init' which > calls '_dl_addr', and the cost of 60,000 Ir is due to '_dl_addr'. > > I solved all those problems by using static linkage. > > Chris > > > ------------------------------------------------------------------------------ > Special Offer -- Download ArcSight Logger for FREE! > Finally, a world-class log management solution at an even better > price-free! And you'll get a free "Love Thy Logs" t-shirt when you > download Logger. Secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsisghtdev2dev > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |