Hello, [Gmane swallowed the original message with ID <87hbuf8ddq.fsf@inria.fr> so I'm resending it. Beware of Gmane...] 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 Date: Fri Oct 2 15:02:52 2009 +0200 Deprecate `scm_mask_ints'. commit b9619bff4ddff267149e7e869ef3c2bcb9c4f4b4 Author: Ludovic Courtès 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 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