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
