Newsgroups: php.cvs,php.internals
Path: news.php.net
Xref: news.php.net php.cvs:82024 php.internals:77727
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.220.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+9eiLsJ-QjRbsZDiOyYL6QZ3oa=vibZ6=AvRUwOXshPAyZaJA@mail.gmail.com>
References: <35865ab5a49aa7711727174e173d0723.squirrel@webmail.klapt.com>
	<CA+9eiLu1fsRFMvP3B0T+kELjKxyPRt1rFEuGzcOZvdXF-F87Sg@mail.gmail.com>
	<57df99a6abdfeeb9036b529fb83175bd.squirrel@webmail.klapt.com>
	<CA+9eiLsJ-QjRbsZDiOyYL6QZ3oa=vibZ6=AvRUwOXshPAyZaJA@mail.gmail.com>
Date: Wed, 1 Oct 2014 02:09:25 +0400
Message-ID: <CA+9eiLumVZ0KzRNUyMe60_H5xV-ykQKMf3=3zmMK9iWtcT2rvw@mail.gmail.com>
To: Anatol Belski <anatol.php@belski.net>, Joe Watkins <krakjoe@php.net>
Cc: Anatol Belski <ab@php.net>, Nikita Popov <nikita.ppv@gmail.com>, 
	"php-cvs@lists.php.net" <php-cvs@lists.php.net>, PHP Internals <internals@lists.php.net>, 
	Pierre Joye <pierre.php@gmail.com>, Xinchen Hui <laruence@php.net>
Content-Type: multipart/alternative; boundary=089e0111b0a2e42ab605044fa287
Subject: Re: [PHP-DEV] Re: [PHP-CVS] com php-src: fix CG(empty_string) init in
 ZTS: Zend/zend.c
From: dmitry@zend.com (Dmitry Stogov)

--089e0111b0a2e42ab605044fa287
Content-Type: text/plain; charset=UTF-8

Hi,

I took a quick look over the patch.
I didn't get why it's named "native_tls" now, because it doesn't use
"__thread" variables anymore.
Actually, now the patch get rid of additional TSRMLS_ arguments, but
performs near the same thing as TSRMLS_FETCH() on each module global
access. It leads to huge slowdown.

bench.php.

non-zts:     1.222 sec
zts:           1.362 sec
native_tls:  1.785 sec

I think, the patch makes no sense in this state.

It looks like on Windows we can't use __declspec(thread) in DLLs loaded
using LoadLibray() at all, so we won't ale to build mod_php for Apache or
use __declspec(thread) for module globals of extensions build as DLL

On Linux it must be possible, but it depends on TLS model (gcc
-ftls-model=...).  "global-dynamic" model must work in all cases, but I'm
not sure about performance, because it'll lead to additional function call
for each "__thread" variable access (may be I'm wrong). Better models (like
"initial-exec") have some limitations. I don't have enough experience to
say, if they could work for us.

Thanks. Dmitry.

On Mon, Sep 29, 2014 at 10:54 AM, Dmitry Stogov <dmitry@zend.com> wrote:

> Hi Anatol.
>
> I'll take a look on Tuesday or Wednesday.
>
> Thanks. Dmitry.
>
> On Sat, Sep 27, 2014 at 12:59 AM, Anatol Belski <anatol.php@belski.net>
> wrote:
>
>> Hi Dmitry,
>>
>> On Mon, September 22, 2014 08:43, Dmitry Stogov wrote:
>> > Hi Anatol,
>> >
>> >
>> > I didn't completely get your ideas, but if tsrm_ls_cache can't be
>> > exported on Windows directly, can we have a copy of tsrm_ls_cache in
>> each
>> > DLL/EXE
>> > and initialize it once?
>> >
>> > Thanks. Dmitry.
>> >
>> Joe and me was working on this and there is a worky version now. Generally
>> it suffers from some issues already present in master, but in all things
>> together it's a worky crossplatform approach. Please look up the
>> native-tls branch.
>>
>> For the current variant I used the idea from the original RFC, but removed
>> exporting the TSRM cache through a __thread variable as it's not portable.
>> I've also removed the offset logic from the RFC patch, as that brought
>> additional hard to find bugs especially into the current unstable version.
>> I don't think it's necessary to copy the arbitrary globals structs in
>> every ext, further more i think it's not easy possible without some big
>> overhead. However even with the current native-tls branch I'm able to run
>> wordpress, symfony, ab -c 8 -n 2048 pass also with multiple calls. Still,
>> some Apache bugs are already reported against master, I also repro some
>> others, mostly arbitrary shutdown crashes in Apache (so TS version). So as
>> they're in master, they're for sure in native-tls.
>>
>> PHP happens to always have used TLS, however the pointer was passed
>> directly to the functions. In TSRM.c, that's tsrm_tls_get/tsrm_tls_set.
>> Now, a function wrapper is used to fetch the TLS cache directly in the
>> TSRMG macro. This makes the whole slowlier, but allows to get rid of the
>> TSRMLS_* macros. The big question is to optimize the function call to
>> speedup the whole. Maybe one can speedup it saving a tsrm ls cache pointer
>> locally per extension or code area. ATM we're checking the functional
>> part, then one can proceed further with removing the TSRMLS_* macros. Any
>> speedup or improvement thoughts are welcome.
>>
>> Possible directions of the further work after known bugs are fixed (in
>> master or in native-tls), some are mutually exclusive
>>
>> - reimplement the offset logic instead of arrays for the globals structs
>> - share the tsrm cache pointer globally to some scope, like extension or
>> sapi
>> - remove the linked lists logic and use TLS explicitly
>> - improve locking
>>
>> Thanks
>>
>> Anatol
>>
>>
>

--089e0111b0a2e42ab605044fa287--