Re: [PATCH] ZTS as fast as non-ZTS
| From: | Dmitry Stogov | Date: | Tue, 19 Aug 2008 07:22:46 +0000 |
| Subject: | Re: [PATCH] ZTS as fast as non-ZTS | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-40004@lists.php.net to get a copy of this message | ||
Hi Arnaud,
Arnaud Le Blanc wrote:
Hi, On Monday 18 August 2008 19:46:46 Dmitry Stogov wrote:I don't see a big difference between --with-tsrm-full-__thread-tls and --with-tsrm-__thread-tls from TLS point of view (may be I miss it), so I don't understand why one works and the other doesn't. The patch looks more difficult for me than it should. I would prefer to have only --with-tsrm-full-__thread-tls, if it works, as the patch would be simple and PHP faster. Another simple solution, which you probably already tested, is to use only global __thread-ed tsrm_ls (and don't pass/fetch it), however, access thread-globals in the same way: ((*type)tsrm_ls[global_module_id])->global_fileld Anyway you did a great job. I would like to see this idea implemented in HEAD. It is little bit late for 5.3 :( Thanks. Dmitry.Hi Arnaud, The patch looks very interesting. I think it may be committed to the HEAD in the nearest future. I don't have time to look into all details in the moment. Could you explain why --with-tsrm-full-__thread-tls doesn't work with dlopen() however --with-tsrm-__thread-tls does?That's due to the way TLS works internally. Actually I need further reading on that.
Did you test the patch with DSO extensions?I will, but I guess that will be behaves like another shared library dlopen()ed by Apache.It would be interesting to try the same idea on Windows with VC.I will try too.Thanks. Dmitry. Arnaud Le Blanc wrote:pointerHi, Currently the way globals work forces to pass a thread-local-storagefunctionsacross function calls, which involves some overhead. Also, not allForget the pointer as argument and need to use TSRMLS_FETCH(), which is slow.accessinginstance emalloc() involves a TSRMLS_FETCH(). An other overhead istheglobals, 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 removestworequirement of passing the tls pointer across function calls, so that thebit.major overheads of ZTS builds are avoided. Globals can optionally be declared statically, which speeds up things a"ts_rsrc_idResults 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 currentpointerfoo_global_id". These macros declare the global id, plus the __threadtheto the global storage. ts_allocate_id now takes one more callback function as argument to bindts_resource(0)global pointer to its storage. This callback is declared in TSRMG_D[H](). As all TSRMLS_* macros now does nothing, it is needed to callnewexplicitly at least one time in each thread to initialize its storage. AfeaturesTSRMLS_INIT() macro as been added for this purpose. All this is disabled by default. --with-tsrm-__thread-tls enables theofof the patch, and --with-tsrm-full-__thread-tls enables static declarationtroublesglobals. 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) causeswithto dlopen(), actually Apache wont load the module at runtime (it worksnotjust --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 possiblybranch,the case. The patch needs some tweaks and does not pretend to be included in anyRegards, Arnaudbut I would like to have some comments on it. The patch: http://arnaud.lb.s3.amazonaws.com/__thread-tls.patch Regards, Arnaud