* [BDW-GC] Performance impact of static allocation
@ 2009-09-02 0:24 Ludovic Courtès
0 siblings, 0 replies; only message in thread
From: Ludovic Courtès @ 2009-09-02 0:24 UTC (permalink / raw)
To: guile-devel
[-- Attachment #1: Type: text/plain, Size: 3140 bytes --]
Hello!
I just updated the `bdw-gc-static-alloc' branch [0]. It statically
allocates stringbufs, strings, and subrs defined using the "snarfing
macros". It links `libguile' with `-z relro' such that constants
needing relocation are placed in a `PT_GNU_RELRO' ELF segment, which is
made read-only by the dynamic linker after relocation.
Current libgc CVS (pre-7.2) is aware of `PT_GNU_RELRO' [1, 2] and does
not scan data contained in this segment (since it cannot possibly
contain pointers to heap-allocated objects). This was not the case in
7.1. Thus I compared `bdw-gc-static-alloc' to `boehm-demers-weiser-gc'
using the latest libgc. The benchmark is (again) `gcbench.scm'; the
baseline is current Guile `master':
* no static allocation (boehm-demers-weiser-gc)
heap size (MiB) execution time (s.)
Guile 53.83 (1.00x) 21.167 (1.00x)
BDW-GC, FSD=3 53.22 (0.99x) 15.204 (0.72x) !
BDW-GC, FSD=6 53.11 (0.99x) 15.457 (0.73x) !
BDW-GC, FSD=9 43.62 (0.81x) 16.810 (0.79x) !
BDW-GC, FSD=3 incr. 63.22 (1.17x) 19.716 (0.93x)
BDW-GC, FSD=3 gene. 96.42 (1.79x) 18.641 (0.88x)
* static allocation, `-z relro' (bdw-gc-static-alloc)
heap size (MiB) execution time (s.)
Guile 53.83 (1.00x) 20.556 (1.00x)
BDW-GC, FSD=3 47.33 (0.88x) 14.391 (0.70x) !
BDW-GC, FSD=6 46.75 (0.87x) 14.914 (0.73x) !
BDW-GC, FSD=9 44.74 (0.83x) 15.130 (0.74x) !
BDW-GC, FSD=3 incr. 82.51 (1.53x) 19.023 (0.93x)
BDW-GC, FSD=3 gene. 93.87 (1.74x) 17.147 (0.83x)
* static allocation (bdw-gc-static-alloc), *without* `-z relro'
heap size (MiB) execution time (s.)
Guile 53.83 (1.00x) 21.768 (1.00x)
BDW-GC, FSD=3 55.85 (1.04x) 16.156 (0.74x)
BDW-GC, FSD=6 55.29 (1.03x) 15.220 (0.70x)
BDW-GC, FSD=9 44.74 (0.83x) 16.355 (0.75x) !
BDW-GC, FSD=3 incr. 102.09 (1.90x) 20.571 (0.95x)
BDW-GC, FSD=3 gene. 89.70 (1.67x) 19.215 (0.88x)
(Heap usage in incremental mode seems to be highly variable in this
case, sometimes going as high as 128 MiB.)
Conclusions
-----------
Libgc's handling of `PT_GNU_RELRO' segments provides a noticeable
improvement. With it, static allocation actually improves performance
(5%) and leads to reduced heap usage (11%).
However, when not linking with `-z relro', static allocation leads to
slightly degraded performance and increased heap usage (perhaps due to
misidentified pointers in the `.data.rel.ro' section?). This is
probably worth some investigation on the BDW-GC side.
Thanks,
Ludo'.
[0] http://git.savannah.gnu.org/gitweb/?p=guile.git;a=commit;h=5f236208d0d864546e59afa0f5a11c9b3ba14b10
[1] http://thread.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/2570
[2] http://thread.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/2716
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2009-09-02 0:24 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-09-02 0:24 [BDW-GC] Performance impact of static allocation Ludovic Courtès
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).