From: ludo@gnu.org (Ludovic Courtès)
To: guile-devel@gnu.org
Subject: [BDW-GC] Performance impact of static allocation
Date: Wed, 02 Sep 2009 02:24:05 +0200 [thread overview]
Message-ID: <87vdk242je.fsf@gnu.org> (raw)
[-- 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 --]
reply other threads:[~2009-09-02 0:24 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87vdk242je.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).