This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Memory allocators / STL


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]