Wojtek Meler wrote:
On Mon, Mar 24, 2003 at 09:59:36PM -0800, Zeev Suraski wrote:
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
At 01:37 25/03/2003, Wojtek Meler wrote:
__thread / __declspec(thread) struct {..} thread_globals;
and accesing it in code by
thread_globals.variable
which probably relay on CPU's MMU (depends on compiler and libc) is probably
faster than
(((type) (*((void ***) tsrm_ls))[TSRM_UNSHUFFLE_RSRC_ID(i
On Mon, Mar 24, 2003 at 09:59:36PM -0800, Zeev Suraski wrote:
> 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
> m
At 00:12 25/03/2003, Wojtek Meler wrote:
as Sascha said - NPTL is the future for multi-threaded applications - I think
there is a need for review of TSRM.
If you read what Sascha said you can see that when NPTL is ready, we'll be
taking advantage of it automatically. It's an implementation of POS
At 22:25 24/03/2003, Sascha Schumann wrote:
> 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
On Mon, Mar 24, 2003 at 11:25:47PM +0200, Andi Gutmans wrote:
> At 10:20 PM 3/24/2003 +0100, [EMAIL PROTECTED] 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
> 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
> accumu
At 13:20 24/03/2003, [EMAIL PROTECTED] 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
resourc
At 10:20 PM 3/24/2003 +0100, [EMAIL PROTECTED] 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 ? Thread-safe syscalls
? I don't think so.
Hmm, not worth arguing with
> 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 ? Thread-safe syscalls
? I don't think so.
> There's no need for rewriting TSRM, it's roughly as fast as it can be.
Things
ZTS is *always* going to be slower than non ZTS. There's no need for
rewriting TSRM, it's roughly as fast as it can be. We may still be able to
squeeze a bit more performance by reducing the number of fetches, but most
fetches have already been eliminated, so I don't anticipate too much gains
Hi!
I've done some performance tests of PHP with and without ZTS (RH7.2 -
pthreads). I've noticed that ZTS is signifcally slower than normal mode. My
machine was able to response for 100reqs/s without ZTS and 95reqs/s with ZTS.
When I turned on turck mmcache (code cache & optimizer) it handled 400
12 matches
Mail list logo
