Re: performance of multithreading gets gradually worse under gdb

Markus Alber
2011-02-03T20:52:48Z

On Thu, 03 Feb 2011 12:26:25 -0800, Michael Snyder wrote:
> Markus Alber wrote:
>> I compiled gdb-6.5 alright and it performs well as usual, without
>> this problem.
>
> Good info. What version of gdb were you using when you detected the
> problem?

it was gdb 7.1 as it comes with OpenSuSE 11.3

Meanwhile I tried every release between 6.5 and 7.2. All the 7's showed
the
problem, but it was also perceivable with 6.8.91.
I was a bit too quick to assert that 6.5 was working well... it wasn't
possible
to set break points, some 6.8 versions crashed. There seems to be some
incompatibility
between the compiler on OpenSuse 11.3 and the older gdbs (I got them as
sources from
the gnu repository)

> I ran your program stand-alone, then under gdb 7.0, then gdb 7.2CVS.
> On my not-so-new system I got the following times:
> stand alone: 15m33s
> gdb 7.0 16m
> gdb 7.2CVS 16m10s

So I presume the stripping-down removed something that causes the
problem in the
larger application. Or, is it a possibility that it has something to do
with the kernel or compiler of
OpenSuSE 11.3?

Meanwhile I've gone back to my older 4-core machine running gdb 6.5 on
OpenSuse 10.2.
Performance is constant throughout. I did notice that gdb allocates
memory for each
iteration.

>
> I could not perceive any change in the cycle time from beginning to
> end.
>
> GDB 7.0 did increase its memory footprint by about 3mb during the run
> (3 percent). So that could indicate some leakage, around 15k per
> cycle.
> But I can't see that as the main reason for the slow-down you're
> reporting, considering that your system is not memory bound.
>
> GDB 7.2CVS increased its memory footprint by only about 500kb during
> the
> whole run, so you might consider giving that a try. Instructions for
> getting the latest development sources are here:
>
> http://sourceware.org/gdb/current/
>
> If you'd be willing to contribute your little sample program, we
> might be able to use it for a thread debugging stress test or
> something.
>
> Michael