[libdispatch-dev] trivial linux patch + general questions
Joakim Johansson
jocke at tbricks.com
Mon Apr 18 00:08:29 PDT 2011
On Sat, 16 Apr 2011 22:34:21 +0700
"C. Bergström" <cbergstrom at pathscale.com> wrote:
>Does anyone have ideas on Solaris or Linux non-portable
>tsd or semaphore optimizations? Thanks! ./C
Some small comment with regard to TSD optimization for Linux/Solaris
(I did have a small look at this for Solaris):
I'm not aware of how it looks at Linux, but Solaris do already have a
quite optimized version of pthread_get/set_specific() for the first 8
TSD keys allocated [1]. For most "normal" applications, the
libdispatch keys would be allocated in that space during startup
during library initialization. See links below for details (it is not
much code to read really...).
Of course, the Apple implementation is even one more notch 'down to
the metal' [2] - for Solaris I could see the following possible
optimizations:
1. Use the non-portable thr_get/set_specific instead of the pthread
interface, it saves one function call when setting TSD, but loses one
load/store for the get interface
2. Inline the appropriate logic similar to the Apple TSD optimization
using the knowledge of the libc implementation from opensolaris.org
"1" Seems like easy and "safe", but will trade off slightly worse
performance for TSD lookup (see comments in the link below) vs
avoiding an extra function call when setting a TSD - depends on the
usage pattern of libdispatch - I think this has a decent chance of
being a net loss in reality…
"2" Would in practice be difficult to do in terms of robustness
(Oracle might change the implementation…), but could fairly easily be
done as a proof-of-concept just for testing the performance difference
by peeking at the implementation referenced below. It might be a small
challenge to get the required interfaces supported directly by Oracle
then as the next step :-)
Frankly, I don't think either one is that attractive unless someone
from Oracle/Sun would like to step in and directly address "2" so it
could be done in a supported way.
A good performance test case would be needed before going either route
though, so far I haven't seen either function in any samples on
Solaris and decided to postpone further investigation until it's
popped up in any samples.
Cheers,
Joakim
[1]
pthread_getspecific:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/threads/tsd.c#214
pthread_setspecific:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/port/threads/tsd.c#355
Getting current thread ("curthread", from thr_uberdata.h):
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/inc/thr_inlines.h#_curthread
TSD_NFAST:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/inc/thr_uberdata.h#TSD_NFAST
[2]
http://libdispatch.macosforge.org/trac/browser/trunk/src/shims/tsd.h
More information about the libdispatch-dev
mailing list