[boehms-gc] Performance results

["Laurynas Biveinis" <laurynas dot biveinis at gmail dot com>]

Hi,

(This email is quite long; if you are not interested in performance
data, scroll down for my questions that you might be able to answer)

Below are some performance results with --with-gc=boehm. This
collector since the last posted results at
http://gcc.gnu.org/ml/gcc/2006-06/msg00729.html, has following further
changes:
http://gcc.gnu.org/ml/gcc/2006-07/msg00194.html
http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00678.html
http://www.cs.aau.dk/~lauras/gcc-patch.txt

Additionally compilers [2] and [3], [5] and [6] differ in that [3] and [6] have
http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00695.html

[A]: Peak GC mem usage
[B]: garbage collection, absolute usr time
[C]: garbage collection, % of usr time
[D]: user time
[E]: sys time
[F]: user bootstrap time
[G]: sys bootstrap time

All tested compilers are based on
gcc version 4.2.0 20060615 (experimental)

[1]: Cygwin baseline, ggc-page

Target: i686-pc-cygwin
Thread model: single

[2]: Cygwin ggc-boehm, with cache support, no "deletable" support

Target: i686-pc-cygwin
Thread model: single

[3]: Cygwin ggc-boehm, with cache support, with "deletable" support

Target: i686-pc-cygwin
Thread model: single

[4]: Linux baseline

Target: i686-pc-linux-gnu
Thread model: posix

[5]: Linux boehm (+cache, no "deletable" support)

Target: i686-pc-linux-gnu
Thread model: posix

[6]: Linux boehm (+cache, deletable)

Target: i686-pc-linux-gnu
Thread model: posix

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

Bootstrap:

4F: 33m51.280s 4G: 4m23.677s
5F: 35m12.730s 5G: 4m31.270s
6F: 35m14.948s 6G: 4m29.909s

reload.c:

1A: 10636K   1B: 0.50   1C: 6%   1D: 0m8.591s   1E: 0m0.405s
2A: 15908K   2B: 0.31   2C: 4%   2D: 0m8.309s   2E: 0m0.560s
3A: 16036K   3B: 0.90   3C: 4%   3D: 0m25.576s  3E: 0m1.389s

4D: 0m4.835s 4E: 0m0.581s
5D: 0m5.036s 5E: 0m0.633s
6D: 0m5.044s 6E: 0m0.599s

combine.c:

1A: 13921K   1B: 0.71   1C: 5%   1D: 0m13.559s  1E: 0m0.748s
2A: 21716K   2B: 0.50   2C: 4%   2D: 0m13.653s  2E: 0m0.591s
3A: 21716K   3B: 1.42   3C: 4%   3D: 0m39.310s  3E: 0m1.872s

4D: 0m7.498s    4E: 0m0.832s
5D: 0m7.782s    5E: 0m0.884s
6D: 0m7.778s    6E: 0m0.848s

PR/8361 (C++, -g -O3)

1A: 67071K   1B: 5.95   1C: 9%   1D: 1m9.496s   1E: 0m2.122s
2A: 141988K  2B: 3.21   2C: 4%   2D: 1m22.169s  2E: 0m2.809s
3A: 131936K  3B: 8.64   3C: 4%   3D: 3m23.059s  3E: 0m6.138s

4D: 0m41.204s   4E: 0m3.167s
5: ICE
6: ICE

PR/19614 (C++, -g -O3)

1A: 139521K   1B: 4.42   1C: 17%   1D: 0m26.686s   1E: 0m0.873s
2A: 170848K   2B: 5.95   2C: 17%   2D: 0m35.108s   2E: 0m1.108s
3A: 170752K   3B: 10.75  3C: 15%   3D: 1m13.342s   3E: 0m1.920s

4D: 0m18.354s   4E: 0m0.400s
5D: 0m20.522s   5E: 0m0.472s
6D: 0m20.515s   6E: 0m0.456s


I hope you made sense of my A..G, 1..6 notation. Cygwin and Linux
numbers cannot be directly compared. Linux compilers were configured
with --disable-checking, Cygwin ones had default development checking
enabled. Now about the results:

1) The basic patch here for cache support with weak pointers is a big
improvement, shaving a 100M or so from C++ GC peak usage (compare with
http://gcc.gnu.org/ml/gcc/2006-06/msg00729.html)

2) The "deletable" support patch
http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00695.html gives me a lot
of headache. Mem usage: for C++ it reduces peak GC memory usage, in
some other cases it does not affect it, but I don't see how setting
things to NULL can actually increase peak GC memory usage? Its running
time is another headache on Cygwin, but fits my expectations on Linux.
I will try compilers on Linux without --disable-checking, in hope to
confirm that checking is the reason for such a long running time on
Cygwin.

3) OTOH, I don't fully get "deletable" GTY flag. Can anyone explain if
things marked with it must be cleared to NULL or is it OK to leave the
old value if the object pointed by it did not get collected?

4) I have configured Linux compilers with "--disable-checking". I was
quite surprised to see that GGC times have disappeared from the "-Q
-ftime-report -fmem-report" output. Is this expected by design
behaviour? What minimum configure options will cause GGC time to
reappear?

5) While peak GC memory usage is well decreased currently, still it
has a long way to go. I want to check if that's because of ordinary
data misintrepreted as pointers. Can anyone suggest what are the
biggest atomic data structures in GCC? I could check sources
file-by-file and replace calls to GC_malloc() to atomic version where
appropriate, but if anybody knows the what atomic data structures are
the biggest ones, it would save me a lot of time.

6) Are there any data objects in GCC, that the only pointers pointing
to them point to their interiors and not the beginning? If I could
disable Boehm's interior pointer support, that should boost
performance in all respects.

7) There are two ICEs, I'm looking into them.

--
Laurynas