valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Preliminary little speedup patch (seen 7% speedup)

[Nicholas N. <nj...@ca...>]

On Mon, 17 Mar 2003, Jason Evans wrote:

> > But the numbers are not good, actually a performance decrease against
> > switch().
>
> I've recently been doing some experimentation with computed gotos in an
> unrelated program, and I've also observed a slowdown in most cases.  This
> indicates to me that gcc typically does a fine job of optimizing switch
> statements, and there isn't a whole lot to be gained by second guessing it
> in such cases.

I think Christian got good results with the first version, but not with
the second version that computes each label address as a difference from a
base label address.  So it looks like it (the first version) is
worthwhile.

I've had mixed successes with computed gotos in the past as well...
branch prediction is very important;  I once tried the computed goto trick
which saved me quite a few instructions, but made the branches more or
less unpredictable, and the end result was little difference.

N

Re: [Valgrind-users] Preliminary little speedup patch (seen 7% speedup)

[Jason E. <ja...@ca...>]

On Mon, Mar 17, 2003 at 03:33:13PM +0100, Christian Leber wrote:
> On Mon, Mar 17, 2003 at 12:37:52PM +0000, Nicholas Nethercote wrote:
> 
> > Valgrind is packaged as a shared library.  Perhaps this might improve
> > things further?
> 
> Ok, I changed it (patch included).
> 
> But the numbers are not good, actually a performance decrease against
> switch().

I've recently been doing some experimentation with computed gotos in an
unrelated program, and I've also observed a slowdown in most cases.  This
indicates to me that gcc typically does a fine job of optimizing switch
statements, and there isn't a whole lot to be gained by second guessing it
in such cases.

Jason

Re: [Valgrind-users] rpm dependency problem (Red Hat 7.3) failed dependencies: libc.so.6(GLIBC_PRIVATE)

[Tom H. <th...@cy...>]

In message <XFM...@lu...>
        Greg Hosler <ho...@lu...> wrote:

> I recently tried building an rpm for valgrind 1.0.4
> (http://developer.kde.org/~sewardj/) (the spec file is in the tar.bz2 file)
> 
> the rpm spec file looks pretty innocent.
> 
> at the end of the rpm build, during dependency checking I see:
> 
> 
>    Requires: ld-linux.so.2 libc.so.6 /bin/sh /usr/bin/perl libc.so.6(GLIBC_2.0)
>    libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.2) libc.so.6(GLIBC_2.1.3)
>    libc.so.6(GLIBC_PRIVATE)
>    Wrote: /home/hosler/WIP/rpmbuild/RPMS/valgrind-1.0.4-1.i386.rpm
> 
> When I try to install the rpm (Red Hat 7.3, all eratta applied), I get the
> following error message:
> 
>         rpm -ivh valgrind-1.0.4-1.i386.rpm 
>         error: failed dependencies:
>                 libc.so.6(GLIBC_PRIVATE)   is needed by valgrind-1.0.4-1
> 
> Now the interesting thing is:
> 
>         # strings /lib/libc.so.6 | grep GLIBC_PRIVATE
>         GLIBC_PRIVATE
> 
> so the pre-requisite symbol is infact in the library, and
> /usr/lib/rpm/find-requires found it, get when rpm goes to install, it can't
> verify that the dependency is satisfied.

The symbols in question - there are actually two - are indeed present
in glibc, but recent releases have given them a version of GLIBC_PRIVATE
to indicate that they are for internal use only. The symbols in question
are:

  __pthread_clock_gettime
  __pthread_clock_settime
 
Both of these are referenced in valgrind's special libpthread.so and
hence are picked up by rpmbuild as dependencies. The problem is that
rpm knows that those are private symbols and doesn't consider that
the glibc package satisfies them, hence the error.

You can force the install with --no-deps and it will all run just
fine, or you can hack the package building to avoid adding that
dependency, which is what I do. I have this script in my RPM sources
directory as valgrind-find-requires:

#!/bin/sh

/usr/lib/rpm/find-requires "$@" | grep -v GLIBC_PRIVATE

and then I add this macro to my valgrind.spec file:

%define __find_requires %{_sourcedir}/valgrind-find-requires

Tom

-- 
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/

[Valgrind-users] rpm dependency problem (Red Hat 7.3) failed dependencies: libc.so.6(GLIBC_PRIVATE)

[Greg H. <ho...@lu...>]

Hi,

I recently tried building an rpm for valgrind 1.0.4
(http://developer.kde.org/~sewardj/) (the spec file is in the tar.bz2 file)

the rpm spec file looks pretty innocent.

at the end of the rpm build, during dependency checking I see:


   Requires: ld-linux.so.2 libc.so.6 /bin/sh /usr/bin/perl libc.so.6(GLIBC_2.0)
   libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.2) libc.so.6(GLIBC_2.1.3)
   libc.so.6(GLIBC_PRIVATE)
   Wrote: /home/hosler/WIP/rpmbuild/RPMS/valgrind-1.0.4-1.i386.rpm

When I try to install the rpm (Red Hat 7.3, all eratta applied), I get the
following error message:

        rpm -ivh valgrind-1.0.4-1.i386.rpm 
        error: failed dependencies:
                libc.so.6(GLIBC_PRIVATE)   is needed by valgrind-1.0.4-1

Now the interesting thing is:

        # strings /lib/libc.so.6 | grep GLIBC_PRIVATE
        GLIBC_PRIVATE

so the pre-requisite symbol is infact in the library, and
/usr/lib/rpm/find-requires found it, get when rpm goes to install, it can't
verify that the dependency is satisfied.

is this an rpm bug (kind of feels like it :(
is there a way around this particular situation ?

thank you, and best regards,

-Greg Hosler

+---------------------------------------------------------------------+
   You can release software that's good, software that's inexpensive, or
   software that's available on time.  You can usually release software
   that has 2 of these 3 attributes -- but not all 3.
| Greg Hosler                                   ho...@lu...    |
+---------------------------------------------------------------------+

Re: [Valgrind-users] Preliminary little speedup patch (seen 7% speedup)

[Christian L. <chr...@le...>]

On Mon, Mar 17, 2003 at 12:37:52PM +0000, Nicholas Nethercote wrote:

> Valgrind is packaged as a shared library.  Perhaps this might improve
> things further?

Ok, I changed it (patch included).

But the numbers are not good, actually a performance decrease against
switch().

gzip:
13.78user 0.03system 0:14.21elapsed 97%CPU (0avgtext+0avgdata
0maxresident)k
13.71user 0.06system 0:14.16elapsed 97%CPU (0avgtext+0avgdata
0maxresident)k

bzip2:
48.49user 0.10system 0:49.79elapsed 97%CPU (0avgtext+0avgdata
0maxresident)k
48.66user 0.04system 0:50.06elapsed 97%CPU (0avgtext+0avgdata
0maxresident)k

latex:
real    0m5.056s
user    0m4.880s
sys     0m0.090s

Regards,
Christian Leber

-- 
  "Omnis enim res, quae dando non deficit, dum habetur et non datur,
   nondum habetur, quomodo habenda est."       (Aurelius Augustinus)
  Translation: <http://gnuhh.org/work/fsf-europe/augustinus.html>

Re: [Valgrind-users] Preliminary little speedup patch (seen 7% speedup)

[Christian L. <chr...@le...>]

On Mon, Mar 17, 2003 at 12:37:52PM +0000, Nicholas Nethercote wrote:

> 1. Can you try it with a few other programs?  It would be nice to see if
> the 7% speedup is consistent across programs.  Some programs I've used
> for performance timing in the past:
> 
>    gzip
>    bzip2

48.36user 0.05system 0:49.79elapsed 97%CPU (0avgtext+0avgdata
0maxresident)k
48.47user 0.07system 0:51.22elapsed 94%CPU (0avgtext+0avgdata
0maxresident)k

patched:
47.93user 0.09system 0:49.17elapsed 97%CPU (0avgtext+0avgdata
0maxresident)k
47.91user 0.09system 0:49.22elapsed 97%CPU (0avgtext+0avgdata
0maxresident)k

>    latex

real    0m5.088s
user    0m4.790s
sys     0m0.130s

patched:
real    0m4.741s
user    0m4.490s
sys     0m0.140s

>    konqueror (startup then quit immediately)

It eats up all CPU till it -9 kill it when I quit it.
(I still have KDE 2.2)

> 2. The bottom of the webpage you mention says:
> 
>    "An alternate way to write the above example is
> 
>    static const int array[] = { &&foo - &&foo, &&bar - &&foo,
>                                 &&hack - &&foo };
>    goto *(&&foo + array[i]);
> 
>    This is more friendly to code living in shared libraries, as it reduces
>    the number of dynamic relocations that are needed, and by consequence,
>    allows the data to be read-only."
> 
> Valgrind is packaged as a shared library.  Perhaps this might improve
> things further?

Yes, but initially I did not get it working, was a little stupid error.
I'll try it, but this takes some time.

cachegrind shows me with a little test programm, that it's slower with
the later thing. But it's not a shared library and I don't know how
often it has to be done.


Regards,
Christian Leber

-- 
  "Omnis enim res, quae dando non deficit, dum habetur et non datur,
   nondum habetur, quomodo habenda est."       (Aurelius Augustinus)
  Translation: <http://gnuhh.org/work/fsf-europe/augustinus.html>

Re: [Valgrind-users] Preliminary little speedup patch (seen 7% speedup)

[Nicholas N. <nj...@ca...>]

On Mon, 17 Mar 2003, Christian Leber wrote:

> I saw this realy big switch(opt){case 0x00....} statement and thought
> "this must be slow".
>
> So I tried the "Labels as Values" feature of the gcc.
> (http://www.dis.com/gnu/gcc/gcc_79.html#SEC79)
> Yes it is a gcc feature, but because is specially for x86/Linux I can't
> see a problem.

[snip]

> 13.54 -> 12.55
> that is a speedup of about 7% in this case
>
> If you (Julian or Nick) are perhaps interested in it, I would clean it up
> further and remove this one switch() { } statement.

Interesting.  Two comments:

1. Can you try it with a few other programs?  It would be nice to see if
the 7% speedup is consistent across programs.  Some programs I've used
for performance timing in the past:

   gzip
   bzip2
   latex
   konqueror (startup then quit immediately)

Batch programs are obviously more suitable for this.


2. The bottom of the webpage you mention says:

   "An alternate way to write the above example is

   static const int array[] = { &&foo - &&foo, &&bar - &&foo,
                                &&hack - &&foo };
   goto *(&&foo + array[i]);

   This is more friendly to code living in shared libraries, as it reduces
   the number of dynamic relocations that are needed, and by consequence,
   allows the data to be read-only."

Valgrind is packaged as a shared library.  Perhaps this might improve
things further?


If you could try these two experiments, and tell us the results, that
would be very helpful.

Thanks.

N

[Valgrind-users] Preliminary little speedup patch (seen 7% speedup)

[Christian L. <chr...@le...>]

Hello,

first let me say:

valgrind is absolutly great, thank you for it!
It saved me allready often.

Because I was not able to add MMX support (seems not to be exactly
easy).
I saw this realy big switch(opt){case 0x00....} statement and thought
"this must be slow".

So I tried the "Labels as Values" feature of the gcc.
(http://www.dis.com/gnu/gcc/gcc_79.html#SEC79)
Yes it is a gcc feature, but because is specially for x86/Linux I can't
see a problem.

"benchmark":
core:/home/ijuz/Mail/la# ls -l
total 4508
-rw-------    1 ijuz     ijuz      4602189 Mar 17 11:56
politech_at_politechbot_com

core:/home/ijuz/Mail/la# nice -n -10 time /work/dev/val/bin/valgrind
gzip -9 politech_at_politechbot_com

normali-cvs:
13.57user 0.09system 0:14.07elapsed 97%CPU (0avgtext+0avgdata
0maxresident)k
13.51user 0.08system 0:14.01elapsed 96%CPU (0avgtext+0avgdata
0maxresident)k

patched-cvs:
12.54user 0.06system 0:13.07elapsed 96%CPU (0avgtext+0avgdata
0maxresident)k
12.56user 0.06system 0:12.97elapsed 97%CPU (0avgtext+0avgdata
0maxresident)k

this means (average):

13.54 -> 12.55
that is a speedup of about 7% in this case

If you (Julian or Nick) are perhaps interested in it, I would clean it up
further and remove this one switch() { } statement.

I appended the patch, I hope nobody objects because of this few kb.
(It is against the cvs from now)

Regards,
Christian Leber

-- 
  "Omnis enim res, quae dando non deficit, dum habetur et non datur,
   nondum habetur, quomodo habenda est."       (Aurelius Augustinus)
  Translation: <http://gnuhh.org/work/fsf-europe/augustinus.html>

[Valgrind-users] Here's a nano-FAQ

[Julian S. <js...@ac...>]

Something to get started with ... here's a nano-FAQ I assembled for
the 1.0.X branch but didn't get round to putting in the 2.0.X branch
yet.  Maybe the FAQ will grow as a result of this list.

J

--------------------------------------------------------------------


A mini-FAQ for valgrind, versions 1.0.4 and 1.1.0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Last revised 13 Oct 2002
~~~~~~~~~~~~~~~~~~~~~~~~


Q1. Programs run OK on valgrind, but at exit produce a bunch
    of errors a bit like this

    ==20755== Invalid read of size 4
    ==20755==    at 0x40281C8A: _nl_unload_locale (loadlocale.c:238)
    ==20755==    by 0x4028179D: free_mem (findlocale.c:257)
    ==20755==    by 0x402E0962: __libc_freeres (set-freeres.c:34)
    ==20755==    by 0x40048DCC: vgPlain___libc_freeres_wrapper
                                              (vg_clientfuncs.c:585)
    ==20755==    Address 0x40CC304C is 8 bytes inside a block of size 380 
free'd
    ==20755==    at 0x400484C9: free (vg_clientfuncs.c:180)
    ==20755==    by 0x40281CBA: _nl_unload_locale (loadlocale.c:246)
    ==20755==    by 0x40281218: free_mem (setlocale.c:461)
    ==20755==    by 0x402E0962: __libc_freeres (set-freeres.c:34)

    and then die with a segmentation fault.

A1. When the program exits, valgrind runs the procedure
    __libc_freeres() in glibc.  This is a hook for memory debuggers,
    so they can ask glibc to free up any memory it has used.  Doing
    that is needed to ensure that valgrind doesn't incorrectly
    report space leaks in glibc.

    Problem is that running __libc_freeres() in older glibc versions
    causes this crash.

    WORKAROUND FOR 1.0.X versions of valgrind: The simple fix is to
    find in valgrind's sources, the one and only call to
    __libc_freeres() and comment it out, then rebuild the system.  In
    the 1.0.3 version, this call is on line 584 of vg_clientfuncs.c.
    This may mean you get false reports of space leaks in glibc, but
    it at least avoids the crash.

    WORKAROUND FOR 1.1.X and later versions of valgrind: use the
    --run-libc-freeres=no flag.



Q2. My program dies complaining that syscall 197 is unimplemented.

A2. 197, which is fstat64, is supported by valgrind.  The problem is
    that the /usr/include/asm/unistd.h on the machine on which your
    valgrind was built, doesn't match your kernel -- or, to be more
    specific, glibc is asking your kernel to do a syscall which is
    not listed in /usr/include/asm/unistd.h.

    The fix is simple.  Somewhere near the top of vg_syscall_mem.c,
    add the following line:

       #define __NR_fstat64            197

    Rebuild and try again.  The above line should appear before any
    uses of the __NR_fstat64 symbol in that file.  If you look at the
    place where __NR_fstat64 is used in vg_syscall_mem.c, it will be
    obvious why this fix works.  NOTE for valgrind versions 1.1.0
    and later, the relevant file is actually coregrind/vg_syscalls.c.


Q3. My (buggy) program dies like this:
      valgrind: vg_malloc2.c:442 (bszW_to_pszW):
                Assertion `pszW >= 0' failed.
    And/or my (buggy) program runs OK on valgrind, but dies like
    this on cachegrind.

A3. If valgrind shows any invalid reads, invalid writes and invalid
    frees in your program, the above may happen.  Reason is that your
    program may trash valgrind's low-level memory manager, which then
    dies with the above assertion, or something like this.  The cure
    is to fix your program so that it doesn't do any illegal memory
    accesses.  The above failure will hopefully go away after that.


Q4. I'm running Red Hat Advanced Server.  Valgrind always segfaults at
    startup.

A4. [Note: fixed properly in 1.9.4; the following stuff is now redundant]

    Known issue with RHAS 2.1.  The following kludge works, but
    is too gruesome to put in the sources permanently.  Try it.
    Last verified as working on RHAS 2.1 at 20021008.

    Find the following comment in vg_main.c -- in 1.0.4 this is at
    line 636:

       /* we locate: NEW_AUX_ENT(1, AT_PAGESZ, ELF_EXEC_PAGESIZE) in
          the elf interpreter table */

    Immediately _before_ this comment add the following:

       /* HACK for R H Advanced server.  Ignore all the above and
          start the search 18 pages below the "obvious" start point.
          God knows why.  Seems like we can't go into the highest 18
          pages of the stack.  This is not good! -- the 18 pages is
          determined just by looking for the highest proddable
          address.  It would be nice to see some kernel or libc or
          something code to justify this.  */

       /* 0xBFFEE000 is 0xC0000000 - 18 pages */
       sp = 0xBFFEE000;

       /* end of HACK for R H Advanced server. */

    Obviously the assignment to sp is the only important line.


(this is the end of the FAQ.)

[Valgrind-users] Test message

[Julian S. <js...@ac...>]

Well, like wot the Subject line says ...

J