Re: Memory allocators / STL

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <87itcxxikc.fsf@ntlworld.com>,
Philip Martin <philip_martin@ntlworld.com> writes:

>> If you don't know how that compiler was built.  Please rebootstrap
>> from complete scratch and try again.  It sure looks to me like something
>> weird happened to your build.

> [Embarassed look]

Don't feel too bad.  It took maybe a few minutes to debug this problem
(at least at this end ;-).  I offer many thanks to the anonymous
person that radically improved the output of gcc -v to allow for a
hint of this type of problem to be seen (Alexander?).

It would be somewhat useful to learn how you managed to build a bogus
library so we could warn future generations and/or figure out how to
better detect the problem, but I suspect the many reconfigures and
then incomplete rebuilds is the root cause.  Normal users of the
compiler should always use a full bootstrap in a fresh build tree.
The gcc Makefile don't always rebuild everything required when the
configuration changes; one has to really know what they are doing
here.  I still use `rm -rf $target-triple/libstdc++-v3' a lot. ;-)

> I don't recall how the compiler was built. A bootstrap from scratch
> gives me a compiler that produces a working executable.

Excellent.

> I note that the program doesn't run very fast:

> $ uptime; ps aux | grep a.out | grep -v grep
>   3:14pm  up  3:10,  3 users,  load average: 0.06, 0.05, 0.34
> pm        8304  0.0  0.1  4000  748 pts/1    S    14:39   0:00 ./a.out
> pm        8305  0.0  0.1  4000  748 pts/1    S    14:39   0:00 ./a.out
> pm        8306  0.6  0.1  4000  748 pts/1    S    14:39   0:13 ./a.out
[... 19 similar tasks removed ...]

> So in 35 minutes of wall clock time it has used only a minute or two
> of CPU per processor, on lightly loaded machine. I assume this is down
> to mutex contention in the allocator, the test program is quite
> extreme in this regard as it does no other work.

On the contrary, the program is running exactly as expected and it is
indeed running very fast...

Read poll(1) for the gory details.  Here is a hint: the last argument
to poll() is a time to sleep in milliseconds.  Change the 10 to a 0
and the program will really fly.

BTW, unless your mutex implementation is very strange indeed, mutex
contention in the allocator would show up in either user or system
time measurements.  I dare say that I would know of no way to
determine by looking at just the presented numbers whether the process
was just CPU-bound or experiencing real mutex contention...

Regards,
Loren