2008/8/20 Arnaud Le Blanc <[EMAIL PROTECTED]>: > Hi, > > On Tuesday 19 August 2008 18:22:44 Andi Gutmans wrote: >> OK checked with Zeev. It seems there are some significant limitations at >> least on Windows including that it doesn't work with LoadLibrary() >> (which is our bread and butter). > > Ok, so there is the same limitations than on Linux with dlopen() :( > >> There may also be some size limitations on thread local storage. >> In any case, this is Windows-only feedback and we may find additional >> limitations/compatibility issues on other platforms. >> >> As there are clear benefits to an increased use of TLS (we already use >> it for index caching today) I definitely suggest to revisit this issue >> and try and figure out for the variety of platforms whether there's some >> middle ground that we can make work. It sounds like a non-trivial >> project though. >> Arnaud, are you setup to also play around with Windows and possibly some >> other OSes to look into this further? > > Yes, I will try at least with Windows (XP, so no IIS) and FreeBSD. >
Windows XP Professional have IIS, all you need is your CD and then install it from the Add/Remove programs. It's IIS 5.1, which should be good enough. >> >> Andi >> >> >> > -----Original Message----- >> > From: Arnaud Le Blanc [mailto:[EMAIL PROTECTED] >> > Sent: Monday, August 18, 2008 10:00 PM >> > To: Andi Gutmans >> > Cc: PHP Development >> > Subject: Re: [PHP-DEV] [PATCH] ZTS as fast as non-ZTS >> > >> > Hi, >> > >> > Yes, I have looked for the issue with --with-tsrm-full-__thread-tls >> and there >> > are effectively some issues. >> > >> > When building PIC code, the used TLS model is a static model which >> does not >> > allow modules to be loaded at run-time. glibc's dlopen() sometimes >> allow such >> > code to be loaded at runtime when it finds some free memory, that's >> why -- >> > with- >> > tsrm-__thread-tls works, but it is not expected to always work. >> > >> > So when building PIC code that's expected to work only when the >> > server/application links the PHP module, or when using LD_PRELOAD, >> etc. >> > >> > Building non-PIC code allows to use a dynamic TLS model, which allows >> to load >> > modules a run-time, but it is less efficient (4.8s in bench.php, still >> faster >> > than unpatched version, even non-PIC, but less efficient). >> > >> > Regards, >> > >> > Arnaud >> > >> > On Tuesday 19 August 2008 06:18:51 Andi Gutmans wrote: >> > > Hi Arnaud, >> > > >> > > I remember that at the time we looked at thread local storage and >> there >> > > were some real issues with it. I can't remember what as it was about >> 7+ >> > > years ago. >> > > I will ask Zeev if he remembers and if not search my archives (don't >> > > have years prior to 2007 indexed :'( ). >> > > >> > > Andi >> > > >> > > >> > > >> > > >> > > > -----Original Message----- >> > > > From: Arnaud Le Blanc [mailto:[EMAIL PROTECTED] >> > > > Sent: Saturday, August 16, 2008 7:19 PM >> > > > To: PHP Development >> > > > Subject: [PHP-DEV] [PATCH] ZTS as fast as non-ZTS >> > > > >> > > > Hi, >> > > > >> > > > Currently the way globals work forces to pass a >> thread-local-storage >> > > pointer >> > > > across function calls, which involves some overhead. Also, not all >> > > functions >> > > > get the pointer as argument and need to use TSRMLS_FETCH(), which >> is >> > > slow. For >> > > > instance emalloc() involves a TSRMLS_FETCH(). An other overhead is >> > > accessing >> > > > globals, using multiple pointers in different locations. >> > > > >> > > > The following patch caches each global address in a native TLS >> > > variable so >> > > > that accessing a global is as simple as global_name->member. This >> > > removes the >> > > > requirement of passing the tls pointer across function calls, so >> that >> > > the two >> > > > major overheads of ZTS builds are avoided. >> > > > >> > > > Globals can optionally be declared statically, which speeds up >> things >> > > a bit. >> > > > >> > > > Results in bench.php: >> > > > non-ZTS: 3.7s >> > > > ZTS unpatched: 5.2s >> > > > ZTS patched: 4.0s >> > > > ZTS patched and static globals: 3.8s >> > > > >> > > > The patch introduces two new macros: TSRMG_D() (declare) and >> > > TSRMG_DH() >> > > > (declare, for headers) to declare globals, instead of the current >> > > "ts_rsrc_id >> > > > foo_global_id". These macros declare the global id, plus the >> __thread >> > > pointer >> > > > to the global storage. >> > > > >> > > > ts_allocate_id now takes one more callback function as argument to >> > > bind the >> > > > global pointer to its storage. This callback is declared in >> > > TSRMG_D[H](). >> > > > >> > > > As all TSRMLS_* macros now does nothing, it is needed to call >> > > ts_resource(0) >> > > > explicitly at least one time in each thread to initialize its >> storage. >> > > A new >> > > > TSRMLS_INIT() macro as been added for this purpose. >> > > > >> > > > All this is disabled by default. --with-tsrm-__thread-tls enables >> the >> > > features >> > > > of the patch, and --with-tsrm-full-__thread-tls enables static >> > > declaration of >> > > > globals. >> > > > >> > > > It as been tested on Linux compiled with --disable-all in CLI and >> a >> > > bit in >> > > > Apache2 with the worker MPM. Known issues: >> > > > - Declaring globals statically (--with-tsrm-full-__thread-tls) >> causes >> > > troubles >> > > > to dlopen(), actually Apache wont load the module at runtime (it >> works >> > > with >> > > > just --with-tsrm-__thread-tls). >> > > > - The patch assumes that all resources are ts_allocate_id()'ed >> before >> > > any >> > > > other thread calls ts_allocate_id or ts_resource_ex(), which is >> > > possibly not >> > > > the case. >> > > > >> > > > The patch needs some tweaks and does not pretend to be included in >> any >> > > branch, >> > > > but I would like to have some comments on it. >> > > > >> > > > The patch: http://arnaud.lb.s3.amazonaws.com/__thread-tls.patch >> > > > >> > > > Regards, >> > > > >> > > > Arnaud >> > > > >> > > > >> > > > -- >> > > > PHP Internals - PHP Runtime Development Mailing List >> > > > To unsubscribe, visit: http://www.php.net/unsub.php >> > > >> > > >> >> > > Regards, > > Arnaud > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Kalle Sommer Nielsen -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
