Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:245
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Reply-To: zeev@zend.com
Message-ID: <5.1.0.14.2.20030324214937.04581cf0@localhost>
Date: Mon, 24 Mar 2003 21:59:36 -0800
To: wmeler@wp-sa.pl
Cc: internals@lists.php.net
In-Reply-To: <3b6af3b7d2.3b7d23b6af@wp-sa.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] ZTS performance
From: zeev@zend.com (Zeev Suraski)
References: <3b6af3b7d2.3b7d23b6af@wp-sa.pl>

At 13:20 24/03/2003, wmeler@wp-sa.pl wrote:
> > ZTS is *always* going to be slower than non ZTS.
>
>Yes, but it can be faster than it is. PHP doesn't use almost any shared
>resources (compiled regexs?) so why it is so slow ?

It uses lots of globals.  These aren't shared resources, but they're 
resources that in ZTS mode, take more time to access than they do in 
non-ZTS mode.  I mentioned the issues involved with this in my previous email.

>  Thread-safe syscalls
>? I don't think so.

That's one of the reasons, I would guess.  The libc memory manager is not 
very efficient with multiple threads accessing it at once, it has locks 
(which is one of the reasons we implemented our own in ZE2).  It's 
definitely one of the reasons, and as you know, performance penalties 
accumulate.

> > There's no need for rewriting TSRM, it's roughly as fast as it can be.
>
>Things changes ...
>Now we have AD2003 and __thread keyword in gcc. I suppose that if we use
>it we could get rid of all this TSRMLS*. I know - PHP is not for linux
>only - but we could have it in TSRM implementation.

If __thread is any similar to Tls under Windows (which would be my guess), 
then we can't use it directly.  We're already using pthread_setspecific so 
we're extremely quick with fetches as it is.  As I said, I also doubt very 
much that our performance penalty is solely due to fetches, but mostly 
based on other issues, which __thread will not alter in any way.  You're 
more than encouraged to try and implement a __thread based solution in 
place of the pthread_setspecific solution and see if it makes any 
difference.  If it does, we can investigate further in that direction and 
see if it's usable.

>I'm sure that compiler will optimize it better if __thread keyword will
>be used instead of TSRMLS*.

Probably not much more than pthread_setspecific.  I wouldn't be surprised 
if __thread is built around that, actually.

Zeev