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.

> 
> 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

Reply via email to