This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Memory allocators / STL
- To: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
- Subject: Re: Memory allocators / STL
- From: Philip Martin <philip_martin at ntlworld dot com>
- Date: 30 Oct 2001 15:18:27 +0000
- Cc: bkoz at redhat dot com, libstdc++ at gcc dot gnu dot org, rittle at labs dot mot dot com
- References: <200110301408.f9UE8iN00452@latour.rsch.comm.mot.com>
Loren James Rittle <rittle@latour.rsch.comm.mot.com> writes:
> How was this compiler and library built? It was clearly not
> bootstrapped in one fell swoop. In fact, it look likes only the last
> reconfiguration has threads enabled properly. Did you perchance, do a
> bootstrap then reconfigure and then somehow only rebuild the gcc driver?
>
> Did you skip any back traces in the report you sent? It is missing
> all the mutex locking on the allocate() calls. Yikes.
>
> 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]
I don't recall how the compiler was built. A bootstrap from scratch
gives me a compiler that produces a working executable.
Apologies for the false alarm.
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
pm 8307 0.6 0.1 4000 748 pts/1 S 14:39 0:13 ./a.out
pm 8308 0.7 0.1 4000 748 pts/1 S 14:39 0:15 ./a.out
pm 8309 0.7 0.1 4000 748 pts/1 S 14:39 0:16 ./a.out
pm 8310 0.7 0.1 4000 748 pts/1 S 14:39 0:15 ./a.out
pm 8311 0.7 0.1 4000 748 pts/1 S 14:39 0:15 ./a.out
pm 8312 0.7 0.1 4000 748 pts/1 R 14:39 0:16 ./a.out
pm 8313 0.8 0.1 4000 748 pts/1 S 14:39 0:18 ./a.out
pm 8314 0.6 0.1 4000 748 pts/1 S 14:39 0:14 ./a.out
pm 8315 0.8 0.1 4000 748 pts/1 S 14:39 0:17 ./a.out
pm 8316 0.6 0.1 4000 748 pts/1 S 14:39 0:13 ./a.out
pm 8317 0.9 0.1 4000 748 pts/1 S 14:39 0:19 ./a.out
pm 8318 0.6 0.1 4000 748 pts/1 S 14:39 0:14 ./a.out
pm 8319 0.6 0.1 4000 748 pts/1 S 14:39 0:13 ./a.out
pm 8320 0.7 0.1 4000 748 pts/1 S 14:39 0:16 ./a.out
pm 8321 0.8 0.1 4000 748 pts/1 S 14:39 0:18 ./a.out
pm 8322 0.6 0.1 4000 748 pts/1 S 14:39 0:13 ./a.out
pm 8323 0.5 0.1 4000 748 pts/1 S 14:39 0:11 ./a.out
pm 8324 0.7 0.1 4000 748 pts/1 S 14:39 0:16 ./a.out
pm 8325 0.7 0.1 4000 748 pts/1 S 14:39 0:15 ./a.out
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.
Philip