[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Thread local storage
From: |
Ludovic Courtès |
Subject: |
Thread local storage |
Date: |
Sun, 04 Oct 2009 16:03:45 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) |
Hello,
I looked again at how/whether we could improve thread-local storage
access, using compiler support (the ‘__thread’ storage class).
There’s now only one thread-local datum in libguile, which is the
pointer to the current thread. It’s accessed mostly when running
‘SCM_TICK’ (at least on every ‘call’, ‘goto/args’, or ‘return’ VM
instruction) and when dealing with dynwinds and dynamic state.
There are 4 TLS access models [0]:
1. The ‘general-dynamic’ model (the default), involves run-time
overhead slightly lower than ‘pthread_getspecific ()’, but
comparable when there are few thread-local variables.
2. The ‘local-dynamic’ model can be used when thread-local variables
are only referenced from within the shared object they appear in.
It is not advantageous when only one thread-local variable is used
(per Section 4.2 of [0]), which is our case.
3. The ‘initial-exec’ model noticeably reduces the run-time overhead.
In addition to the restrictions in for ‘local-dynamic’, the shared
object must be present when the executable is loaded and cannot be
dlopened.
4. The ‘local-exec’ model, an optimization of the above, which can
only be used when the executable is statically linked against
libguile and its dependencies.
So #3 is appealing (~8% speedup on ‘gcbench’, ~10% on 30 iterations of
‘nboyer’). Unfortunately it’s not generally applicable to libguile
since libguile may be dlopened (e.g., the XChat-Guile plug-in).
(Actually, according to [1], we should be able to use it on GNU systems
since we don't use much TLS, but in practice it breaks the allocation of
libgc's TLS for some reason. See attached test program.)
So we’re left with #1, which doesn’t buy us much performance-wise (for
‘general-dynamic’: ~3% speedup on ‘gcbench’, ~4% on 30 iterations of
‘nboyer’.)
The relevant work in ‘wip-tls’:
commit 8346727c49c51a9668f10b507daff62dd889850a
Author: Ludovic Courtès <address@hidden>
Date: Fri Oct 2 15:02:52 2009 +0200
Deprecate `scm_mask_ints'.
commit b9619bff4ddff267149e7e869ef3c2bcb9c4f4b4
Author: Ludovic Courtès <address@hidden>
Date: Fri Oct 2 15:28:29 2009 +0200
Arrange so that `SCM_I_CURRENT_THREAD' is not accessed outside of
libguile.
commit a24c958689c86ac520b73bc9c6e1c40cfbf6f857
Author: Ludovic Courtès <address@hidden>
Date: Fri Oct 2 16:32:34 2009 +0200
Use TLS when available for `SCM_I_CURRENT_THREAD'.
Given the second commit, changing the TLS access model for libguile
doesn’t change the ABI. Power users can compile Guile with the TLS
model of their choice, which is nice. ;-)
Comments?
Thanks,
Ludo’.
[0] http://people.redhat.com/drepper/tls.pdf
[1] http://thread.gmane.org/gmane.comp.lib.phil/619
#include <dlfcn.h>
#include <stdlib.h>
int
main (int argc, char *argv[])
{
void *lib;
void (*init) (void);
void * (*eval) (const char *);
lib = dlopen ("libguile.so", RTLD_LAZY);
init = dlsym (lib, "scm_init_guile");
eval = dlsym (lib, "scm_c_eval_string");
init ();
eval ("(format #t \"hello, world~%2 + 2 = ~A~%\" (+ 2 2))");
return EXIT_SUCCESS;
}
/*
Local Variables:
compile-command: "gcc -g -Wall -o tls-dlopen tls-dlopen.c -ldl"
End:
*/
- Thread local storage,
Ludovic Courtès <=