To all internals, but especially to Zeev and Dmitry,
Having a JIT which does not support ZTS is a bit short-sighted.
I don't think anybody's advocating for not having ZTS support for JIT. I
am questioning the portof the absence of ZTS support in the current JIT as
an absolute deal breaker. The question is do we need ZTS support for JIT
in February 2019, ~2 years before PHP 8 comes out, or is it OK that it will
be implemented a bit further down the line? Is it a horrific crime to
include an experimental version in 7.4 that won't have ZTS support?
about it. You want to add a JIT partly so that PHP will be better at
non-web, CPU intensive tasks. If the JIT is successful, eventually you
will want parallelism in that domain, and if you are going to use
threading then something like ZTS is required.
Multithreading isn't the way of choice today for scalable parallelism.
Again, it doesn't mean that ZTS shouldn't be supported - but between Swoole
support and ZTS support - I would rate Swoole as a lot more strategic.
Additionally, a lot of people are using ZTS builds today.
Which they can continue doing, even if we fast forward to 2020, JIT is in,
and it doesn't support ZTS. It seems as if people think that if JIT
doesn't support ZTS, it means ZTS is no longer viable. That's obviously
not the case. You will be able to continue using PHP just fine with JIT
argue all you want, we can't remove it easily. Imagine if I proposed a
breaking change in the language that would affect these same users.
Unless we got a lot of value out of it, I don't think it would pass.
I'm not campaigning for the removal of ZTS; The fact I wouldn't go about
implementing it from scratch today, doesn't mean we need to axe it. There
are two discussions, that kind of got intermixed in this thread:
- How high should we prioritize ZTS build support for JIT? I admit I have
a very hard time accepting that it's as critical as some here portray it.
That said, Dmitry actually started doing some thinking about how we could
improve ZTS to make it friendlier to JIT. So I guess the ZTS crowd got its
way, as it's been de-facto prioritized as high priority, although he seems
to want to get some help there.
- Separate thread, that spun off from Joe's comment that lots of people use
ZTS builds under Windows. I asked a simple question - why he thinks that
is, because to me it sounded anachronistic. While Joe didn't respond,
others did, suggesting that it's because windows.php.net mistakenly tells
people that the only way to run PHP under Apache on Windows, while there's
a much better way of doing it that's both faster and more reliable
(FastCGI). To me, that's something that we should tackle, and it's
completely independent from the JIT discussion.
And no offense, but in its current state the JIT does not have a lot
None taken. I do think it has a lot of value (covered in the RFC), but as
I've said numerous times in various places - it's not quite the no-brainer
that phpng was (twice the speed, half the memory consumption, no downsides).
It's a promising prototype, but it's not going to help the
vast majority of our users.
That's something I think people don't seem to understand. It's not really
a prototype, and arguably, if you don't like it the way it is - I'm not
sure it would hold much promise from your point of view. It's not a
prototype, but rather the intended base implementation of the feature if we
were to accept it. It's the 3rd attempt at doing this, and I don't believe
there are any intentions to try a 4th (nor should we expect any radically
different results if we were to do a 4th). At this point we don't believe
we'll be able to evolve significantly beyond where we are in terms of
performance, although we can improve things in the way of fixing bugs, and
maybe refactoring certain elements to make it more portable. And of course
there's always room for improvement - but nothing that would radically
change the high level characteristics of this feature. It's not going to
make WordPress - or any other conventional PHP Web app - go 2x faster in
the sense that PHP 7 did.
So, respectfully, I hope we can quit talking about removing ZTS.
Again, I'm not arguing for the removal of ZTS.
ZTS was born to do one thing - which is allow PHP to run within a
multithreaded Web server. However, it evolved to do something else - which
is allow thread usage from within PHP. These are distinct, and almost
inherently separate use cases. I have nothing against the latter - but I
do think the former is outdated and should be discouraged. Much like we
discontinued the ISAPI module, we may want to discontinue support for
mod_php under Windows and point people to use FastCGI instead (which, in
turn, can be a ZTS build, it's completely orthogonal). Like I mentioned
before, today, mod_php is hard to find in any modern deployment, it's been
pretty much exclusively replaced by fpm and for very good reasons. All
these reasons apply in Windows as well, and they're supplemented by
improved stability and robustness. There's ALWAYS the possibility that I'm
missing something, I sent a note to one of the XAMPP maintainers to
understand their rationale on this, as well as their take on what we should
consider doing in this front.
I think it is fair to say that in all likelihood, most people who use ZTS
today do so because they think they have to, and not because they are users
of the pthreads extension. It's the former group that I think we should
tackle, in the exact same way that today, not a single person on the planet
is running ISAPI and they've all moved to use FastCGI (or so I hope, at
least, it's been gone for ages). This is something we ought to consider
doing completely independent from this whole JIT discussion.
required for the present, and it will probably be desirable in the
No argument here.
Therefore, some mechanism for a thread-safe JIT code
generation is a requirement.
I don't see how one leads to the other. The fact PHP is being used on a
certain platform or in a certain mode by does not inherently mean that JIT
must support it, certainly not in this early, pre-approval stage. If we
can indeed do away with the bogus perception that you must use ZTS in order
to use PHP under Apache/Windows, and change XAMPP's deployment model to use
FastCGI (which again we should probably try to do independently from this
whole JIT discussion), it would in turn radically reduce the size of the
applicable ZTS install base, and indirectly make this less of a priority
Of course, one thing that can change this whole thing is if we start
shipping internal functions that are implemented in PHP, while relying on
the performance of JIT to make them sufficiently fast. If that happens,
our platform support, as well as ZTS support, must be a lot more exhaustive
than it is today. But we're far from being there at this point.