On Thu, Feb 14, 2019 at 11:05 PM Zeev Suraski <z...@php.net> wrote:
> On Thu, Feb 14, 2019 at 7:27 PM Levi Morrison <le...@php.net> wrote:
>
> > 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?
>
>
> > Think
> > 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.
>
Async.io is used for scalability In languages with entirely different
architectures than PHP.
Node.js isn't well suited to monolithic applications such as Wordpress,
Magento and the fast amount of applicatoins that people are building in PHP
right now.
One needs some supporting microservices here and there (to do websockets,
high throughput work with lots of I/O, small daemons, ...) which right now
people are using Go or Node.js for next to PHP, swoole or react-php.
The more monolithic, heavily shared nothing based use case isn't going
away, just because we have JIT and swoole and now can write our PHP as if
it were Node.js. If we assume shared nothing is a major of PHPs unique
selling points, then we want users to do parallel work to improve their
code right now.
parallel is a vastly superior threading API to everything that has been
before, how awesome is doing something like this in your Wordpress,
Symfony, Magento code:
$runtime = new \parallel\Runtime();
$fetchJson = function ($url) { return
json_decode(file_get_contents($url), true); }
$future1 = $runtime->run($fetch, ["http://php.net/releases.json";]);
$future2 = $runtime->run($fetch, ["http://nodejs.org/releases.json";]);
$runtime->await([$future1, $future2]); // a joined wait is not on parallel yet
echo $future1->getValue() . $future2->getValue();
This is like the 80% use-case of threading, Multiple HTTP requests,
multiple long running SQL queries. An API like parallel would allow
each and everyone of us to make controllers faster today without a
large effort.
Swoole is nice, but it will never be the 80% use-case for PHP users.
If we add a JIT, then those non-web use cases which gain the most from
it, would still also benefit from threads for parallel I/O.
All async I/O APIs heavily lean on node.js APIs, which is an entirely
different paradigm to program on and not PHP. Plus you have to rewrite
all libraries to support this, instead of being able to re-use the
libraries and style that PHP has championed for all this time.
> 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
> disabled.
>
> You can
> > 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
> > of value.
>
>
> 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.
>
>
> > It is
> > required for the present, and it will probably be desirable in the
> > future.
>
>
> 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
> for JIT.
>
> 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.
>
> Zeev
>
