[RFC] JIT View as Markdown

Hi Internals,

I'm glad to finally propose including JIT into PHP.

https://wiki.php.net/rfc/jit

In the current state it may be included both into PHP-8, where we are going to continue active improvement, and into PHP-7.4, as an experimental feature.

Thanks. Dmitry.

I think I heard some stat that over 50% of Azure now runs Linux (and I am sure PHP is primarily running on Linux). So given JIT probably helps 95% of production PHP installations I wouldn’t hold this back. If Windows ends up being important to folks some (and possibly msft) will contribute that.

I think we should explore the feasibility of moving some internal PHP functions to userland if performance is reasonable. Will help security.

Get Outlook for iOShttps://aka.ms/o0ukef

I'm honestly a bit perplexed by how many people here viewing Windows
support as a must have, while at the same time I think we all agree PHP is
very scarcely found on production Windows servers, and JIT is a
predominantly production feature.

While this is anecdotal, I think you might find a different perspective from user group organizers. I've encountered many user group members over the years who run PHP on Windows. It's more common that they develop on Windows and deploy to Linux, but I do know those who also deploy to Windows in production.

This is actually very consistent with my experience, including some hard data I have from relevant (even if it 100% representative) download and usage stats. Windows is an extremely popular platform for developing PHP on - in fact, from the data I have (which isn’t conclusive) - it’s even more popular than Linux in certain demographics. But much like you say, this dev scenario is more common (I would say a lot more common) than it is to see Windows in production - which does not come to say it’s non existent in prod, just that it’s a lot less common.

That's not to say I personally think that Windows support is a must-have for JIT, but it's definitely important for many of the people in the user groups I've worked with.

I’m not against having support for Windows at all. I do think that much of the discussion here ensued because it wasn’t completely clear that JIT is geared pretty much exclusively at production systems. Personally, I see Windows support as between nice-to-have and important, but not as a must. In other words, if we can bring this boost to the vast majority of production systems, not being able to bring it to a (I believe small) minority of these systems shouldn’t be a deal breaker. I respect that others may have a different view, as long as it’s clear to everyone that JIT is indeed almost exclusively geared at production.

Zeev

Hi Zeev,

Zeev Suraski in php.internals (Sun, 3 Feb 2019 07:05:49 +0000):

2. Most PHP production workloads are on Linux, and as far as I can tell
   this trend is only growing over the years - with virtual machines and
   now containers becoming more and more popular - meaning that even
   developers with other host OSs still use Linux for the actual PHP
   development.

I am not sure this really is the case. Depending on which statistics you
believe te be true, about a quarter to a third of the Web is powered by
Wordpress. Wordpress market share is not diminishing.

How is that related? The vast majority of WordPress is deployed on Linux servers, much (if not most) of it hosted.

Do not underestimate the huge amount of Wordpress plugin developers that
develop on Windows. Code quality is varying from very low to quite high,
but these people are PHP developers as well.

Again, how does that relate to what I said? I actually said in some demographics Windows is more common than Linux for development. I'm also saying that's slowly changing due to certain tech trends, but it doesn't mean that Windows development isn't still incredibly popular. The thing is, it's mostly orthogonal to JIT - which is a production oriented feature.

Zeev

A concern I have with the current RFC is a lack of a good case for why
it should be necessary;

While this is a subjective opinion, it's definitely a valid one. Unlike
phpng (PHP 7) which was a slam dunk - JIT isn't - and whether or not the
added value is worth the added complexity is very much up for debate.

One our hopes in opening this up for comments, is that people would
actually try the code themselves and experiment with it - well beyond what
we can do ourselves. If & when we get feedback from folks on apps and use
cases they tried this on with interesting results, we'll add them to the
RFC. I'd love to hear from folks trying it on things like React. Then,
there's also the possibility of writing builtin functions in PHP - although
that would obviously require a much wider platform support than we
presently have to be viable.

and not much else. Maybe PHP being able to be used for this kind of
software would be cool, but it wouldn't justify the added complexity
(and for that matter security headaches) of adding a JIT to PHP given C,
C++, FORTRAN and so on already exist and are better-suited to it.

This too is a subjective (& obviously completely valid) opinion. Of
course, if the only point of JIT would be 'coolness' then it's probably not
worth the trouble (although JIT is a huge selling point even if it doesn't
bring huge gains, as we've seen in the past). But I don't think it'll end
just there. For me, I would prefer using PHP over any of these if I can
help it and if the performance is reasonable enough - and I doubt I'm the
only person on the planet that feels that way. Again, we don't think it's
a slam dunk (the RFC would have looked differently if we did), but it's not
inconceivable that if we position PHP as a language where you can get the
ease of development benefits of PHP, while getting near-native performance

• it will open the door to new audiences.

Zeev

Dmitry Stogov wrote:

Hi Internals,

I'm glad to finally propose including JIT into PHP.

https://wiki.php.net/rfc/jit

In the current state it may be included both into PHP-8, where we are
going to continue active improvement, and into PHP-7.4, as an
experimental feature.

Thanks. Dmitry.

Hi Dmitry,

Thank you for making an RFC for this. That makes it possible to have a
proper discussion about the JIT idea.

A concern I have with the current RFC is a lack of a good case for why
it should be necessary; the case for JIT is based on performance
benefits, but the examples provided are unconvincing to me because they
seem too contrived. Both bench.php and drawing fractals represent a
best-case example for a JIT, small programs which do heavy arithmetic
and not much else. Maybe PHP being able to be used for this kind of
software would be cool, but it wouldn't justify the added complexity
(and for that matter security headaches) of adding a JIT to PHP given C,
C++, FORTRAN and so on already exist and are better-suited to it.

I guess what I am saying is that the JIT RFC could benefit from
real-world examples that show a benefit to having it. The ideal
application is something in between WordPress and your Mandelbrot
example, one which has significant complexity (i.e. a plausible
real-world application), hot code which a JIT can actually make notably
faster than the current Zend VM, and is something not too far away
from the kinds of applications people write in PHP today — even if you
could write applications focussed on high-performance heavy
number-crunching in PHP, I don't expect people would want to, even if it
becomes less slow.

I've added info from Nikita: PHP-Parser became 1.5 times faster.

Thanks. Dmitry.

Thanks,
Andrea

I’m not sure it’s a great real-world example - PHP Parser is much more maths-y than the vast amount of PHP code, but if your PHP-based compiler had a similar makeup it might show somewhat similar benefits.

Hi,

Dmitry Stogov wrote:

I've added info from Nikita: PHP-Parser became 1.5 times faster.

That is actually a very good real-world example from my perspective and makes a better case for why JIT compilation to native code would be beneficial. I would like to write a PHP compiler in PHP (actually, I began doing so but it's very neglected and pretty useless) and it is exciting if JIT could make PHP do that type of task faster. :)

Thanks,
Andrea

Hi Internals,

According to comments, code reviews and discussions, JIT RFC was
extended with few new sections.

Please, consider to review the RFC once again.

https://wiki.php.net/rfc/jit

Any suggestion for RFC improvement are welcome.

I'm not going to invest significant time into JIT implementation
improvement itself, at this point. So, ideas are also welcome, but don't
expect to get them implemented tomorrow.

Thanks. Dmitry.

Hi Internals,

I'm glad to finally propose including JIT into PHP.

https://wiki.php.net/rfc/jit

In the current state it may be included both into PHP-8, where we are
going to continue active improvement, and into PHP-7.4, as an
experimental feature.

Thanks. Dmitry.

PHP+optimizer (-dopcache.jit_buffer_size=0): 32.29s (100%)
PHP+optimizer+JIT (-dopcache.jit_buffer_size=50000000): 30.72s (95.1%)
PHP+optimizer+minimalJIT (-dopcache.jit_buffer_size=50000000
-dopcache.jit=1201): 29.95s (92.7%)

It may be interesting to try -dopcache.jit=1235. It should JIT only hot
functions and requires some warm-up.

For this use case 1201 was the fastest of all the options I tried
(including 1235).

--

Here are my results of benchmarking rybakit/msgpack.php:

bench.php, w/o jit:
Total 9.8220 4.3121

bench.php, opcache.jit=1235 opcache.jit_buffer_size=256M:
Total 8.7255 3.3350

bench2.php, w/o jit:
pure msgpack: 2.2818 sec
pure msgpack packed: 2.1717 sec

bench2.php, opcache.jit=1235 opcache.jit_buffer_size=256M:
pure msgpack: 1.5221 sec
pure msgpack packed: 1.4739 sec

Details: https://gist.github.com/rybakit/bb551f962b706a9e08c995cf5ed9762f

--
Thank you and best regards,
Eugene Leonovich

On Tue, Feb 5, 2019 at 6:06 PM Bruce Weirdan <weirdan@gmail.com
mailto:weirdan@gmail.com> wrote:

On Tue, Feb 5, 2019 at 8:38 AM Dmitry Stogov <dmitry@zend.com
<mailto:dmitry@zend.com>> wrote:
 > > PHP+optimizer (-dopcache.jit_buffer_size=0):  32.29s  (100%)
 > > PHP+optimizer+JIT (-dopcache.jit_buffer_size=50000000): 30.72s
(95.1%)
 > > PHP+optimizer+minimalJIT (-dopcache.jit_buffer_size=50000000
 > > -dopcache.jit=1201): 29.95s (92.7%)
 >
 > It may be interesting to try -dopcache.jit=1235. It should JIT
only hot
 > functions and requires some warm-up.

For this use case 1201 was the fastest of all the options I tried
(including 1235).

-- 

Here are my results of benchmarking rybakit/msgpack.php:

bench.php, w/o jit:
    Total     9.8220     4.3121

bench.php, opcache.jit=1235 opcache.jit_buffer_size=256M:
    Total     8.7255     3.3350

bench2.php, w/o jit:
    pure msgpack: 2.2818 sec
    pure msgpack packed: 2.1717 sec

bench2.php, opcache.jit=1235 opcache.jit_buffer_size=256M:
    pure msgpack: 1.5221 sec
    pure msgpack packed: 1.4739 sec

Details: https://gist.github.com/rybakit/bb551f962b706a9e08c995cf5ed9762f

1.3-1.5 times speed-up.
Thanks for benchmarking.

Dmitry.

Am 31.01.2019 um 18:08 schrieb Derick Rethans:

I do not believe that something major like this should make it into any
PHP 7.x release. Having it as experimental new feature in the master/PHP
8.0 branch makes the most sense to me.

ACK

On Thu, Feb 14, 2019 at 10:20 AM Sebastian Bergmann sebastian@php.net
wrote:

Am 31.01.2019 um 18:08 schrieb Derick Rethans:

I do not believe that something major like this should make it into any
PHP 7.x release. Having it as experimental new feature in the master/PHP
8.0 branch makes the most sense to me.

ACK

Does it mean that when PHP 8.0 comes out (in roughly two years' time most
probably), we'd be saying this is experimental? Or that only in the
meantime, for the brave folks that want to experiment PHP 8.0 ~2yrs before
it's released, we'd say it's experimental but will remove that tag by the
time 8.0 is released?

If it's the former - I don't think we should go in this direction. If we
decide that it's sensible to have it - I think we should work to ensure
that it's production ready by the time PHP 8.0 is released. Offering it as
something experimental (i.e. not for production) in 7.4 can help us with
that goal, as it will make it easier for a wider range of people to
experiment with it and provide feedback. I can't think of any
technological downsides to including it as experimental in 7.4 - there's a
slight "marketing" downside (it will be less of a shiny new thing in PHP
8.0), but personally I think the feedback we're likely to get is worth it.

Zeev

Does it mean that when PHP 8.0 comes out (in roughly two years' time most
probably), we'd be saying this is experimental? Or that only in the
meantime, for the brave folks that want to experiment PHP 8.0 ~2yrs before
it's released, we'd say it's experimental but will remove that tag by the
time 8.0 is released?

The latter. Every new feature is experimental until it's released; scalar
type hints were experimental in master until 7.0 was released; typed
properties are experimental until 7.4 is released; I don't see why this
should be any different.

Offering it as
something experimental (i.e. not for production) in 7.4 can help us with
that goal, as it will make it easier for a wider range of people to
experiment with it and provide feedback.

As I mentioned in a previous e-mail, I'm not clear who these extra users
are, or what value their feedback will be. On one hand, if someone tests
their application on a stale version of the JIT engine released with 7.4.0,
and says "it segfaults when I foo" or "I'm surprised it doesn't optimise
bar", the answer is likely to be "we fixed that 6 months ago in master". On
the other hand, if someone is confident enough to enable an experimental
JIT feature on a server, they're probably fine with running a pre-alpha
snapshot, or building it from source (e.g. by downloading Rasmus's vagrant
box).

If the feature was "mostly finalised but needs more testing", then an
experimental release might make sense; but that's not the impression I get
here, as it's been said over and over that deeper changes are needed to get
the full advantage, and that's why we need PHP 8 in the first place.

Regards,

Rowan Collins
[IMSoP]

On Thu, Feb 14, 2019 at 10:20 AM Sebastian Bergmann sebastian@php.net
wrote:

Am 31.01.2019 um 18:08 schrieb Derick Rethans:

I do not believe that something major like this should make it into any
PHP 7.x release. Having it as experimental new feature in the
master/PHP
8.0 branch makes the most sense to me.

ACK

Does it mean that when PHP 8.0 comes out (in roughly two years' time most
probably), we'd be saying this is experimental? Or that only in the
meantime, for the brave folks that want to experiment PHP 8.0 ~2yrs before
it's released, we'd say it's experimental but will remove that tag by the
time 8.0 is released?

I don't think we can really answer that question at this point in time.
That depends on how stable and compatible the JIT is by the time PHP 8.0
comes around. But having it as a non-experimental feature should definitely
the goal, and I also think this is possible.

If it's the former - I don't think we should go in this direction. If we
decide that it's sensible to have it - I think we should work to ensure
that it's production ready by the time PHP 8.0 is released. Offering it as
something experimental (i.e. not for production) in 7.4 can help us with
that goal, as it will make it easier for a wider range of people to
experiment with it and provide feedback. I can't think of any
technological downsides to including it as experimental in 7.4 - there's a
slight "marketing" downside (it will be less of a shiny new thing in PHP
8.0), but personally I think the feedback we're likely to get is worth it.

There a number of downsides to including it in PHP 7.4:

• First and foremost for me: Maintenance. We are only shortly after
  branching, and the PHP 7.4 and PHP 8.0 branches already have some
  significant divergences (e.g. in object handler APIs). I don't expect that
  this is going to be get as bad as PHP 5 vs PHP 7 internals, but I would
  also very much prefer not having to maintain a new large and complex chunk
  of code against two different major engine versions.

• Marketing: As you already mentioned yourself, adding a JIT is a great
  marketing point. I think that PHP 7 was quite successful from a marketing
  perspective, because it had a nice blend of major performance wins, some
  long-awaited features and a few incompatibilities. It would be great if we
  could repeat this with PHP 8, and I think that having a JIT and some major
  language feature (say generics) would be a great drive to upgrade. Adding
  the JIT earlier as an experimental feature would dilute this a lot.

• Stability / Compatibility: While we can mark features as experimental all
  we want, let's fact it: If it exists, it's going to end up in production. I
  would prefer to only publicize the JIT once it is stable, and also
  importantly, has good integration with 3rd party extensions. Basically
  "just works". I know that Joe has been testing some of this exts (like pcov
  and pthreads) and their interaction with the JIT, and also been talking to
  some other maintainers of "low-level" extensions like profilers. From what
  I understood, quite some work will be needed to allow integration (beyond
  just disabling the JIT).

Nikita

On Thu, Feb 14, 2019 at 10:20 AM Sebastian Bergmann sebastian@php.net
wrote:

Am 31.01.2019 um 18:08 schrieb Derick Rethans:

I do not believe that something major like this should make it into
any
PHP 7.x release. Having it as experimental new feature in the
master/PHP
8.0 branch makes the most sense to me.

ACK

Does it mean that when PHP 8.0 comes out (in roughly two years' time most
probably), we'd be saying this is experimental? Or that only in the
meantime, for the brave folks that want to experiment PHP 8.0 ~2yrs
before
it's released, we'd say it's experimental but will remove that tag by the
time 8.0 is released?

I don't think we can really answer that question at this point in time.
That depends on how stable and compatible the JIT is by the time PHP 8.0
comes around. But having it as a non-experimental feature should definitely
the goal, and I also think this is possible.

Agreed.

If it's the former - I don't think we should go in this direction. If we
decide that it's sensible to have it - I think we should work to ensure
that it's production ready by the time PHP 8.0 is released. Offering it
as
something experimental (i.e. not for production) in 7.4 can help us with
that goal, as it will make it easier for a wider range of people to
experiment with it and provide feedback. I can't think of any
technological downsides to including it as experimental in 7.4 - there's
a
slight "marketing" downside (it will be less of a shiny new thing in PHP
8.0), but personally I think the feedback we're likely to get is worth
it.

There a number of downsides to including it in PHP 7.4:

• First and foremost for me: Maintenance. We are only shortly after
  branching, and the PHP 7.4 and PHP 8.0 branches already have some
  significant divergences (e.g. in object handler APIs). I don't expect that
  this is going to be get as bad as PHP 5 vs PHP 7 internals, but I would
  also very much prefer not having to maintain a new large and complex chunk
  of code against two different major engine versions.

That's a valid point, but given we're only a few months away from
feature-completing 7.4, as well as the general direction that most probably
more substantial changes will make it into 8.0 - I don't know that the
initial investment in a 7.4 version of JIT (and the marginal cost of then
maintaining it) would be too big. I believe Dmitry's proposing that while
realizing the bulk of the work will fall on his shoulders if we decide to
do it.

• Marketing: As you already mentioned yourself, adding a JIT is a great
  marketing point. I think that PHP 7 was quite successful from a marketing
  perspective, because it had a nice blend of major performance wins, some
  long-awaited features and a few incompatibilities. It would be great if we
  could repeat this with PHP 8, and I think that having a JIT and some major
  language feature (say generics) would be a great drive to upgrade. Adding
  the JIT earlier as an experimental feature would dilute this a lot.

We both agree that if we include JIT in 7.4 it will dilute from the 'shiny
new thing' aspect of it when it's available in 8.0. That said -
realistically, it seems that JIT will not be as revolutionary as phpng was
in terms of real world performance impact, so if I had to guess - migration
to 8 it would be a lot slower than the migration to 7 (the motivation to
upgrade to 7 in the vast majority of companies I came across was
predominantly around performance; new features were a nice bonus).

• Stability / Compatibility: While we can mark features as experimental all

we want, let's fact it: If it exists, it's going to end up in production. I
would prefer to only publicize the JIT once it is stable, and also
importantly, has good integration with 3rd party extensions. Basically
"just works". I know that Joe has been testing some of this exts (like pcov
and pthreads) and their interaction with the JIT, and also been talking to
some other maintainers of "low-level" extensions like profilers. From what
I understood, quite some work will be needed to allow integration (beyond
just disabling the JIT).

I'm not too worried about it finding itself into production, as long as we
make it clear that it's not ready for it. People who run experimental
software in production are typically quite aware of the risk they're
taking, and often they are quite determined too - so they might be the ones
who check out Dmitry's code as it is today without waiting for our RFCs
anyway. It's also quite reasonable that an experimental feature won't work
with every last extension (as long as they're not super mainstream like
MySQL or curl).

Either way, I think the decision whether to include it in 7.4 or not is
tactical. It's gaining wider testing exposure, at the expense of losing
some 'sexiness' of a shiny new feature in 8.0. I see both approaches as
entirely valid.

Zeev

On Thu, Feb 14, 2019 at 12:17 PM Rowan Collins rowan.collins@gmail.com
wrote:

Does it mean that when PHP 8.0 comes out (in roughly two years' time most
probably), we'd be saying this is experimental? Or that only in the
meantime, for the brave folks that want to experiment PHP 8.0 ~2yrs before
it's released, we'd say it's experimental but will remove that tag by the
time 8.0 is released?

The latter. Every new feature is experimental until it's released; scalar
type hints were experimental in master until 7.0 was released; typed
properties are experimental until 7.4 is released; I don't see why this
should be any different.

I'm pretty sure we've had experimental features in released versions. To
me tagging something as experimental in master while it's in early
development stages is somewhat superfluous - the whole of master should be
considered pre-alpha / alpha until it goes to beta. That's why I was
asking.

Offering it as

something experimental (i.e. not for production) in 7.4 can help us with
that goal, as it will make it easier for a wider range of people to
experiment with it and provide feedback.

As I mentioned in a previous e-mail, I'm not clear who these extra users
are, or what value their feedback will be.

I'm not sure who they are either, but much like we've had several folks
here on internals report back their experimentation with JIT, I think
casting a wider net will likely result in more feedback.

On one hand, if someone tests their application on a stale version of the

JIT engine released with 7.4.0, and says "it segfaults when I foo" or "I'm
surprised it doesn't optimise bar", the answer is likely to be "we fixed
that 6 months ago in master".

And that could be a very reasonable answer; Given that it's an
experimental feature that someone purposely decided to build and enable,
telling them that they can get a more recent version of JIT by using master
is not an unreasonable response.

On the other hand, if someone is confident enough to enable an
experimental JIT feature on a server, they're probably fine with running a
pre-alpha snapshot, or building it from source (e.g. by downloading
Rasmus's vagrant box).

We seem to agree, but there's no doubt in my mind that 7.4 will reach a
much wider audience than folks who are here on internals. In a nutshell,
the fact that they can get a pre-alpha PHP 8 that has JIT, doesn't mean
they know it even exists. Including it in 7.4 can help advertise that - of
course, other than the fact that I'm sure in many cases it will actually
work, enabling them to provide us with real world feedback without having
to upgrade to master/8. If we thought that all of them would be bumping
into trouble, we wouldn't be proposing it as an option.

If the feature was "mostly finalised but needs more testing", then an
experimental release might make sense; but that's not the impression I get
here, as it's been said over and over that deeper changes are needed to get
the full advantage, and that's why we need PHP 8 in the first place.

Actually, I think it's closer to being "mostly finalized' than it is to
requiring a major overhaul. It's our 3rd attempt at it after spending the
better part of a decade working on it, and while there's always room for
improvement - and there are some specific areas that aren't yet done
(platform support, ZTS, etc.) - I don't think we're likely to see
fundamental ground-breaking changes. The most common PHP use case - Linux
x86/x86_64 single threaded - is probably fairly close to what it will be.

Again, like I told Nikita I think that whether or not we include it in 7.4
is a tactical decision (and I'm not sure myself where I stand on it), but I
do think there's a reasonable case for both directions.

Zeev

[...] I think that whether or not we include it in 7.4
is a tactical decision (and I'm not sure myself where I stand on it), but I
do think there's a reasonable case for both directions.

If I may add some voice to Zeev's arguments, being able to play with JIT as
early as possible would allow the community to experiment using PHP in
areas where it doesn't fit right now. Having to wait 2 more years to
discover that maybe it's useful to build some new libraries could be a
waste of time at the tactical level (there are other technologies around
that move fast also :) )

Not to detract from the technical challenges of moving in this direction,
of course.
Just my 2cts from a "userland" guy :)

Nicolas

Den 2019-02-13 kl. 14:07, skrev Dmitry Stogov:

Hi Internals,

According to comments, code reviews and discussions, JIT RFC was
extended with few new sections.

Please, consider to review the RFC once again.

https://wiki.php.net/rfc/jit

Any suggestion for RFC improvement are welcome.

I'm not going to invest significant time into JIT implementation
improvement itself, at this point. So, ideas are also welcome, but don't
expect to get them implemented tomorrow.

Thanks. Dmitry.

Hi Internals,

I'm glad to finally propose including JIT into PHP.

https://wiki.php.net/rfc/jit

In the current state it may be included both into PHP-8, where we are
going to continue active improvement, and into PHP-7.4, as an
experimental feature.

Thanks. Dmitry.

First, tnx for the excellent work. I think this will be a key driver
for PHP 8 uptake. Mention market aspect in the section "The
Case for JIT Today"?

Secondly I wonder if preloading of e.g. a framework would allow
JIT to work more efficiently and give even better performance?

r//Björn Larsson

чт, 14 февр. 2019 г. в 14:54, Nicolas Grekas nicolas.grekas+php@gmail.com:

[...] I think that whether or not we include it in 7.4
is a tactical decision (and I'm not sure myself where I stand on it),
but I
do think there's a reasonable case for both directions.

If I may add some voice to Zeev's arguments, being able to play with JIT as
early as possible would allow the community to experiment using PHP in
areas where it doesn't fit right now. Having to wait 2 more years to
discover that maybe it's useful to build some new libraries could be a
waste of time at the tactical level (there are other technologies around
that move fast also :) )

Not to detract from the technical challenges of moving in this direction,
of course.
Just my 2cts from a "userland" guy :)

Nicolas

Hello everyone,

I agree with this sentiment and the general idea of shipping JIT as
experimental in 7.4 and required to build with a configure flag.
master for 8.0 is going to contain much more and be more unstable and not
practical for testing what JIT can do at that point due to all other
features and improvements going into it like additional optimizations and
platform support.
It will give me, as a userland developer, a platform where I can actually
play with it early and on a stable platform. And I understand what I'm
doing at that point.

--
Arvīds Godjuks

+371 26 851 664
arvids.godjuks@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius

On Thu, Feb 14, 2019 at 10:20 AM Sebastian Bergmann sebastian@php.net

• First and foremost for me: Maintenance. We are only shortly after
  branching, and the PHP 7.4 and PHP 8.0 branches already have some
  significant divergences (e.g. in object handler APIs). I don't expect that
  this is going to be get as bad as PHP 5 vs PHP 7 internals, but I would
  also very much prefer not having to maintain a new large and complex chunk
  of code against two different major engine versions.

That's a valid point, but given we're only a few months away from
feature-completing 7.4, as well as the general direction that most probably
more substantial changes will make it into 8.0 - I don't know that the
initial investment in a 7.4 version of JIT (and the marginal cost of then
maintaining it) would be too big. I believe Dmitry's proposing that while
realizing the bulk of the work will fall on his shoulders if we decide to
do it.

Currently, I'm keeping in consistency two JIT branches. For master and
PHP-7.4 (links in RFC). In case 7.4 don't pass, I stop its support.

• Marketing: As you already mentioned yourself, adding a JIT is a great
  marketing point. I think that PHP 7 was quite successful from a marketing
  perspective, because it had a nice blend of major performance wins, some
  long-awaited features and a few incompatibilities. It would be great if we
  could repeat this with PHP 8, and I think that having a JIT and some major
  language feature (say generics) would be a great drive to upgrade. Adding
  the JIT earlier as an experimental feature would dilute this a lot.

We both agree that if we include JIT in 7.4 it will dilute from the 'shiny
new thing' aspect of it when it's available in 8.0. That said -
realistically, it seems that JIT will not be as revolutionary as phpng was
in terms of real world performance impact, so if I had to guess - migration
to 8 it would be a lot slower than the migration to 7 (the motivation to
upgrade to 7 in the vast majority of companies I came across was
predominantly around performance; new features were a nice bonus).

Marketing is simple :) We like to make good JIT in PHP-8, and we need
feedback to really do it. The more interest we get to JIT in PHP-7.4 the
better JIT might be implemented in PHP-8.

• Stability / Compatibility: While we can mark features as experimental all

we want, let's fact it: If it exists, it's going to end up in production. I
would prefer to only publicize the JIT once it is stable, and also
importantly, has good integration with 3rd party extensions. Basically
"just works". I know that Joe has been testing some of this exts (like pcov
and pthreads) and their interaction with the JIT, and also been talking to
some other maintainers of "low-level" extensions like profilers. From what
I understood, quite some work will be needed to allow integration (beyond
just disabling the JIT).

Again, the early we know problems, the better.
Most people will start testing PHP-8 with their third-party extension
only after release. Then we will start getting reports about problems,
and the solutions might need serious API or design changes, that are not
allowed in minor releases...

Thanks. Dmitry.

Morning all,

This idea of an experimental feature as complex as a JIT is dangerous. It
is not finished, and dmitry has said he's not willing to put more time into
until it's merged. That's his prerogative, and it is ours to say that we
don't want unfinished software that only one or two people really
understand in PHP. All of the rest of internals need all of the time
between now and PHP 8 to educate ourselves on this so that we function as
well as we do now when it comes to finding and fixing bugs, and pushing PHP
forward. Merging the JIT into 7.4 puts a brick wall in the way of progress
that none of us have the tools to climb over.

I hear the argument about wanting to test, but anyone with sufficient
expertise to test the JIT is capable of building the branch available on
github, we do not need to push out an incomplete product to the entire
world for the sake of that handful of individuals who will actually test.

I believe it is incredibly dangerous to ship 7.4 with the JIT in it's
current form, and would ask everyone to please think very carefully about
it, prior to supporting it.

Thanks
Joe

On Thu, 14 Feb 2019 at 14:34, Arvids Godjuks arvids.godjuks@gmail.com
wrote:

чт, 14 февр. 2019 г. в 14:54, Nicolas Grekas <nicolas.grekas+php@gmail.com

:

[...] I think that whether or not we include it in 7.4
is a tactical decision (and I'm not sure myself where I stand on it),
but I
do think there's a reasonable case for both directions.

If I may add some voice to Zeev's arguments, being able to play with JIT
as
early as possible would allow the community to experiment using PHP in
areas where it doesn't fit right now. Having to wait 2 more years to
discover that maybe it's useful to build some new libraries could be a
waste of time at the tactical level (there are other technologies around
that move fast also :) )

Not to detract from the technical challenges of moving in this direction,
of course.
Just my 2cts from a "userland" guy :)

Nicolas

Hello everyone,

I agree with this sentiment and the general idea of shipping JIT as
experimental in 7.4 and required to build with a configure flag.
master for 8.0 is going to contain much more and be more unstable and not
practical for testing what JIT can do at that point due to all other
features and improvements going into it like additional optimizations and
platform support.
It will give me, as a userland developer, a platform where I can actually
play with it early and on a stable platform. And I understand what I'm
doing at that point.

--
Arvīds Godjuks

+371 26 851 664
arvids.godjuks@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius

On Thu, 14 Feb 2019 at 13:34, Arvids Godjuks arvids.godjuks@gmail.com
wrote:

I agree with this sentiment and the general idea of shipping JIT as
experimental in 7.4 and required to build with a configure flag.
master for 8.0 is going to contain much more and be more unstable and not
practical for testing what JIT can do at that point due to all other
features and improvements going into it like additional optimizations and
platform support.

This is a reasonable point - other things will be happening on master which
make JIT harder to test. I guess part of the decision here depends what
those are.

If the idea is for someone to build a tagged release (7.4.x) with an
experimental configure flag, could we have a half-way house, by tagging
official "JIT preview builds"? These would mostly just be commits of master
where things happened to be reasonably stable, with the occasional
throwaway branch reverting out something broken.

We could then publicise these builds as "try PHP 8 today" in all the same
places we would have publicised "try --enable-jit today". If anything, it
could be more visible, because every few months we could post a new tag to
the home page of php.net.

To compare strategies:

• Experimental feature in 7.4, port all JIT changes. Users get a current
  snapshot of JIT every release of 7.4.x; maintainers have to port a lot of
  code that may never be used.
• Experimental feature in 7.4, mostly frozen when 7.4.0 ships. Users get an
  out of date JIT to play with; maintainers have to make sure it's not
  completely broken during 7.4 cycle.
• "JIT preview" tags every few months, with no published schedule. Users
  get a current snapshot of JIT every few months; maintainers only manage the
  implementation in one branch, and choose when to tag a new preview.

Regards,

Rowan Collins
[IMSoP]

Hi,

Morning all,

This idea of an experimental feature as complex as a JIT is dangerous. It
is not finished, and dmitry has said he's not willing to put more time into
until it's merged. That's his prerogative, and it is ours to say that we
don't want unfinished software that only one or two people really
understand in PHP. All of the rest of internals need all of the time
between now and PHP 8 to educate ourselves on this so that we function as
well as we do now when it comes to finding and fixing bugs, and pushing PHP
forward.

Few years ago I was claimed for development PHPNNG privately, but that
time we delivered to @internals almost completed solution. Now you don't
like the solution, because it's incomplete in your opinion (ZTS support,
etc), and the development makes troubles...

If you are interested in ZTS, you may invest time in implementation of
the ZTS improvement idea and then I adopt the JIT in few-days. Tell me
if you start, because I may find time myself.

I told, I'm not going to do any active JIT development at this point.
Why to waste time, if it's not going to be accepted...
However, I keep it in sync with master and PHP-7.4, fix reported
problems, respond to code review comments, etc (just check git commits
history).

In last email I asked for ideas for RFC improvement (like notes about
unsupported ZTS). May be it makes sense to add cons/pros for additional
PHP-7.4 proposal. May be write something more clear (I'm not a native
speaker).

But this "a bit toxic" discussion, at least, steals time from
constructive things.

Joe, please, don't take anything personally.
Despite I wrote above, I appreciate your involvement in PHP development
and respect your opinion regarding JIT, ZTS. etc.

Thanks. Dmitry.

Merging the JIT into 7.4 puts a brick wall in the way of progress
that none of us have the tools to climb over.

I hear the argument about wanting to test, but anyone with sufficient
expertise to test the JIT is capable of building the branch available on
github, we do not need to push out an incomplete product to the entire
world for the sake of that handful of individuals who will actually test.

I believe it is incredibly dangerous to ship 7.4 with the JIT in it's
current form, and would ask everyone to please think very carefully about
it, prior to supporting it.

Thanks
Joe

On Thu, 14 Feb 2019 at 14:34, Arvids Godjuks arvids.godjuks@gmail.com
wrote:

чт, 14 февр. 2019 г. в 14:54, Nicolas Grekas <nicolas.grekas+php@gmail.com

:

[...] I think that whether or not we include it in 7.4
is a tactical decision (and I'm not sure myself where I stand on it),
but I
do think there's a reasonable case for both directions.

If I may add some voice to Zeev's arguments, being able to play with JIT
as
early as possible would allow the community to experiment using PHP in
areas where it doesn't fit right now. Having to wait 2 more years to
discover that maybe it's useful to build some new libraries could be a
waste of time at the tactical level (there are other technologies around
that move fast also :) )

Not to detract from the technical challenges of moving in this direction,
of course.
Just my 2cts from a "userland" guy :)

Nicolas

Hello everyone,

I agree with this sentiment and the general idea of shipping JIT as
experimental in 7.4 and required to build with a configure flag.
master for 8.0 is going to contain much more and be more unstable and not
practical for testing what JIT can do at that point due to all other
features and improvements going into it like additional optimizations and
platform support.
It will give me, as a userland developer, a platform where I can actually
play with it early and on a stable platform. And I understand what I'm
doing at that point.

--
Arvīds Godjuks

+371 26 851 664
arvids.godjuks@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius

Morning Dmitry,

I told, I'm not going to do any active JIT development at this point.
Why to waste time, if it's not going to be accepted...

At this point, nobody can imagine that PHP 8 will not have a JIT, there
is no sense in saying or thinking you would be wasting your time.

If you opened a vote for the JIT to be accepted in PHP 8, and committed to
making the improvements that everyone wants to see in the interim, the
vote would be more or less a formality, not really necessary at all,
because we all know what will happen.

I cannot stress enough that you would not be wasting your time to continue
developing the JIT. Saying "it's this or nothing" is not a very productive
or sensible thing to do at this point.

You must already know that yourself, Nikita, and Bob are really the only
active contributors that are qualified to talk about technical aspects of
the JIT, to improve it, to find or fix bugs. You must also understand that
given the time necessary things will change; You are employed, at least in
part, to work on PHP, and nobody else (afaik) except Nikita is: We have to
find time in our weekends and late at night to read things we're not
familiar with at all, I've never been good at assembly myself, and my
knowledge here is lacking. I look forward to improving my knowledge, I find
it exciting, but it will take a long time, many many weekends and nights,
and 7.4 is simply too early. Even Nikita and Bob are not comfortable enough
to make changes right now, but are still useful. What we're looking at
then, is a bus factor of 1, for about the next year, it may be as high as 3
or 4 by the time 7.4 is actually released. There's not 1000 people familiar
enough with the Zend of today to find, fix and improve PHP, but 3 or 4 is
just unreasonably low - this is the reason I say it's dangerous. My words
are not meant to be toxic, at all.

For the last two and a bit years, I've been focused on being a release
manager, and haven't spent a lot of time working on patches like I used
too, I'm still familiar with zend at a low level, but you've just made it
100x more complicated, and are twisting our arms to accept this additional
complexity, all the while saying you won't make improvements and don't have
time for other improvements that you've identified that would widen the
scope of the JIT considerably (ZTS), and lay the groundwork for supporting
other platforms (Windows).

7.3 was one of the worst releases for stability in recent years, and
regardless of whether you intend to disable the JIT by default, it's going
to be rolled out into production in whatever version of PHP it is merged
into, if what it is merged into is a production release of PHP, you can't
stop that with a configure switch or an INI setting, as has already been
pointed out by Nikita. Therefore, it's important that the JIT is actually
production ready and has a scope wide enough to justify the additional
complexity it brings to everything. I'm aware that you think switching the
JIT off is a solution to the tooling problems we clearly have, but it is
not a solution, people are going to expect their tools to work with it, and
saying "disable the JIT" or "disable opcache" to end users is unacceptable.
I realise you have more important things to do right now than to
concentrate on the issues that extension maintainers have, but it's obvious
that these issues need to be addressed before we push the JIT onto the
ecosystem. By withdrawing the suggestion of merging into 7.4, and focusing
our efforts on a really great PHP 8, you give yourself and all those
maintainers time to work together and find solutions to these problems that
are acceptable to us all, time we all desperately need. yourself included.
You also reduce your own workload considerably by not having to concentrate
on 7.4. You also take away the worry of another unstable release in the 7
series, which we cannot really afford to have if we don't want to damage
adoption rates of PHP 8.

Yesterday the suggestion of "preview" releases was made, previews of the
master branch, this is the best idea I have heard around deploying the JIT
to the world, those releases need not have a fixed schedule and in no sense
are production releases of PHP. I'll happily volunteer myself to do that
additional work and manage those releases while the 7.4 release managers
concentrate on a stable 7.4, I'm quite sure that past release managers will
help me there too. We can then nominate permanent managers for 8 as normal,
and I/we will hand over to them a reasonably stable, well tested JIT, that
many of us are comfortable diagnosing and pushing forward.

If you are interested in ZTS, you may invest time in implementation of
the ZTS improvement idea and then I adopt the JIT in few-days. Tell me
if you start, because I may find time myself.

This is great to hear, but I've worked on the TSRM layer before, it was
myself that prepared for PHP 7 the original native-tls patch that was
proposed some time ago for PHP 5, subsequently Anatol had to do all the
heavy lifting, I understand it very well, but I'm not able to confidently
develop on Windows, just like you, I'm not that familiar with Windows.
Again, fixing these things are going to take time, and the effort of many
of us.

Time and commitment, is all I am asking for, without those my confidence
has evaporated, I'm sorry to say.

Cheers
Joe

Hi,

Morning all,

This idea of an experimental feature as complex as a JIT is dangerous. It
is not finished, and dmitry has said he's not willing to put more time
into
until it's merged. That's his prerogative, and it is ours to say that we
don't want unfinished software that only one or two people really
understand in PHP. All of the rest of internals need all of the time
between now and PHP 8 to educate ourselves on this so that we function as
well as we do now when it comes to finding and fixing bugs, and pushing
PHP
forward.

Few years ago I was claimed for development PHPNNG privately, but that
time we delivered to @internals almost completed solution. Now you don't
like the solution, because it's incomplete in your opinion (ZTS support,
etc), and the development makes troubles...

If you are interested in ZTS, you may invest time in implementation of
the ZTS improvement idea and then I adopt the JIT in few-days. Tell me
if you start, because I may find time myself.

I told, I'm not going to do any active JIT development at this point.
Why to waste time, if it's not going to be accepted...
However, I keep it in sync with master and PHP-7.4, fix reported
problems, respond to code review comments, etc (just check git commits
history).

In last email I asked for ideas for RFC improvement (like notes about
unsupported ZTS). May be it makes sense to add cons/pros for additional
PHP-7.4 proposal. May be write something more clear (I'm not a native
speaker).

But this "a bit toxic" discussion, at least, steals time from
constructive things.

Joe, please, don't take anything personally.
Despite I wrote above, I appreciate your involvement in PHP development
and respect your opinion regarding JIT, ZTS. etc.

Thanks. Dmitry.

Merging the JIT into 7.4 puts a brick wall in the way of progress
that none of us have the tools to climb over.

I hear the argument about wanting to test, but anyone with sufficient
expertise to test the JIT is capable of building the branch available on
github, we do not need to push out an incomplete product to the entire
world for the sake of that handful of individuals who will actually test.

I believe it is incredibly dangerous to ship 7.4 with the JIT in it's
current form, and would ask everyone to please think very carefully about
it, prior to supporting it.

Thanks
Joe

On Thu, 14 Feb 2019 at 14:34, Arvids Godjuks arvids.godjuks@gmail.com
wrote:

чт, 14 февр. 2019 г. в 14:54, Nicolas Grekas <
nicolas.grekas+php@gmail.com

:

[...] I think that whether or not we include it in 7.4
is a tactical decision (and I'm not sure myself where I stand on it),
but I
do think there's a reasonable case for both directions.

If I may add some voice to Zeev's arguments, being able to play with
JIT
as
early as possible would allow the community to experiment using PHP in
areas where it doesn't fit right now. Having to wait 2 more years to
discover that maybe it's useful to build some new libraries could be a
waste of time at the tactical level (there are other technologies
around
that move fast also :) )

Not to detract from the technical challenges of moving in this
direction,
of course.
Just my 2cts from a "userland" guy :)

Nicolas

Hello everyone,

I agree with this sentiment and the general idea of shipping JIT as
experimental in 7.4 and required to build with a configure flag.
master for 8.0 is going to contain much more and be more unstable and
not
practical for testing what JIT can do at that point due to all other
features and improvements going into it like additional optimizations
and
platform support.
It will give me, as a userland developer, a platform where I can
actually
play with it early and on a stable platform. And I understand what I'm
doing at that point.

--
Arvīds Godjuks

+371 26 851 664
arvids.godjuks@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius

Just two things.

I definitely don't think, I "just made it 100x more complicated".
I hate complication, and trying to make things simpler and more
efficient. This, sometime, involves new more or less isolated subsystems
like optimizer and now JIT. Of course, they look complex, if you are not
experienced in these areas. But PHP core may work without them.

Nobody will port their complex applications to PHP-8 preview, just to
try JIT. Having this possibility in PHP-7.4 would involve broader auditory.

Thanks. Dmitry.

Morning Dmitry,

I told, I'm not going to do any active JIT development at this point.
Why to waste time, if it's not going to be accepted...

At this point, nobody can imagine that PHP 8 will not have a JIT,
there is no sense in saying or thinking you would be wasting your time.

If you opened a vote for the JIT to be accepted in PHP 8, and committed
to making the improvements that everyone wants to see in the interim,
the vote would be more or less a formality, not really necessary at all,
because we all know what will happen.

I cannot stress enough that you would not be wasting your time to
continue developing the JIT. Saying "it's this or nothing" is not a very
productive or sensible thing to do at this point.

You must already know that yourself, Nikita, and Bob are really the only
active contributors that are qualified to talk about technical aspects
of the JIT, to improve it, to find or fix bugs. You must also understand
that given the time necessary things will change; You are employed, at
least in part, to work on PHP, and nobody else (afaik) except Nikita is:
We have to find time in our weekends and late at night to read things
we're not familiar with at all, I've never been good at assembly myself,
and my knowledge here is lacking. I look forward to improving my
knowledge, I find it exciting, but it will take a long time, many many
weekends and nights, and 7.4 is simply too early. Even Nikita and Bob
are not comfortable enough to make changes right now, but are still
useful. What we're looking at then, is a bus factor of 1, for about the
next year, it may be as high as 3 or 4 by the time 7.4 is actually
released. There's not 1000 people familiar enough with the Zend of today
to find, fix and improve PHP, but 3 or 4 is just unreasonably low - this
is the reason I say it's dangerous. My words are not meant to be toxic,
at all.

For the last two and a bit years, I've been focused on being a release
manager, and haven't spent a lot of time working on patches like I used
too, I'm still familiar with zend at a low level, but you've just made
it 100x more complicated, and are twisting our arms to accept this
additional complexity, all the while saying you won't make improvements
and don't have time for other improvements that you've identified that
would widen the scope of the JIT considerably (ZTS), and lay the
groundwork for supporting other platforms (Windows).

7.3 was one of the worst releases for stability in recent years, and
regardless of whether you intend to disable the JIT by default, it's
going to be rolled out into production in whatever version of PHP it is
merged into, if what it is merged into is a production release of PHP,
you can't stop that with a configure switch or an INI setting, as has
already been pointed out by Nikita. Therefore, it's important that the
JIT is actually production ready and has a scope wide enough to justify
the additional complexity it brings to everything. I'm aware that you
think switching the JIT off is a solution to the tooling problems we
clearly have, but it is not a solution, people are going to expect their
tools to work with it, and saying "disable the JIT" or "disable opcache"
to end users is unacceptable. I realise you have more important things
to do right now than to concentrate on the issues that extension
maintainers have, but it's obvious that these issues need to be
addressed before we push the JIT onto the ecosystem. By withdrawing the
suggestion of merging into 7.4, and focusing our efforts on a really
great PHP 8, you give yourself and all those maintainers time to work
together and find solutions to these problems that are acceptable to us
all, time we all desperately need. yourself included. You also reduce
your own workload considerably by not having to concentrate on 7.4. You
also take away the worry of another unstable release in the 7 series,
which we cannot really afford to have if we don't want to damage
adoption rates of PHP 8.

Yesterday the suggestion of "preview" releases was made, previews of the
master branch, this is the best idea I have heard around deploying the
JIT to the world, those releases need not have a fixed schedule and in
no sense are production releases of PHP. I'll happily volunteer myself
to do that additional work and manage those releases while the 7.4
release managers concentrate on a stable 7.4, I'm quite sure that past
release managers will help me there too. We can then nominate permanent
managers for 8 as normal, and I/we will hand over to them a reasonably
stable, well tested JIT, that many of us are comfortable diagnosing and
pushing forward.

If you are interested in ZTS, you may invest time in implementation of
the ZTS improvement idea and then I adopt the JIT in few-days. Tell me
if you start, because I may find time myself.

This is great to hear, but I've worked on the TSRM layer before, it was
myself that prepared for PHP 7 the original native-tls patch that was
proposed some time ago for PHP 5, subsequently Anatol had to do all the
heavy lifting, I understand it very well, but I'm not able to
confidently develop on Windows, just like you, I'm not that familiar
with Windows. Again, fixing these things are going to take time, and the
effort of many of us.

Time and commitment, is all I am asking for, without those my confidence
has evaporated, I'm sorry to say.

Cheers
Joe

On Fri, 15 Feb 2019 at 09:06, Dmitry Stogov <dmitry@zend.com
mailto:dmitry@zend.com> wrote:

Hi,


 > Morning all,
 >
 > This idea of an experimental feature as complex as a JIT is
dangerous. It
 > is not finished, and dmitry has said he's not willing to put more
time into
 > until it's merged. That's his prerogative, and it is ours to say
that we
 > don't want unfinished software that only one or two people really
 > understand in PHP. All of the rest of internals need all of the time
 > between now and PHP 8 to educate ourselves on this so that we
function as
 > well as we do now when it comes to finding and fixing bugs, and
pushing PHP
 > forward.

Few years ago I was claimed for development PHPNNG privately, but that
time we delivered to @internals almost completed solution. Now you
don't
like the solution, because it's incomplete in your opinion (ZTS
support,
etc), and the development makes troubles...

If you are interested in ZTS, you may invest time in implementation of
the ZTS improvement idea and then I adopt the JIT in few-days. Tell me
if you start, because I may find time myself.

I told, I'm not going to do any active JIT development at this point.
Why to waste time, if it's not going to be accepted...
However, I keep it in sync with master and PHP-7.4, fix reported
problems, respond to code review comments, etc (just check git commits
history).

In last email I asked for ideas for RFC improvement (like notes about
unsupported ZTS). May be it makes sense to add cons/pros for additional
PHP-7.4 proposal. May be write something more clear (I'm not a native
speaker).

But this "a bit toxic" discussion, at least, steals time from
constructive things.

Joe, please, don't take anything personally.
Despite I wrote above, I appreciate your involvement in PHP development
and respect your opinion regarding JIT, ZTS. etc.

Thanks. Dmitry.


 > Merging the JIT into 7.4 puts a brick wall in the way of progress
 > that none of us have the tools to climb over.
 >
 > I hear the argument about wanting to test, but anyone with sufficient
 > expertise to test the JIT is capable of building the branch
available on
 > github, we do not need to push out an incomplete product to the
entire
 > world for the sake of that handful of individuals who will
actually test.
 >
 > I believe it is incredibly dangerous to ship 7.4 with the JIT in it's
 > current form, and would ask everyone to please think very
carefully about
 > it, prior to supporting it.
 >
 > Thanks
 > Joe
 >
 >
 > On Thu, 14 Feb 2019 at 14:34, Arvids Godjuks
<arvids.godjuks@gmail.com <mailto:arvids.godjuks@gmail.com>>
 > wrote:
 >
 >> чт, 14 февр. 2019 г. в 14:54, Nicolas Grekas
<nicolas.grekas+php@gmail.com <mailto:nicolas.grekas%2Bphp@gmail.com>
 >>> :
 >>
 >>>> [...] I think that whether or not we include it in 7.4
 >>>> is a tactical decision (and I'm not sure myself where I stand
on it),
 >>> but I
 >>>> do think there's a reasonable case for both directions.
 >>>>
 >>>
 >>> If I may add some voice to Zeev's arguments, being able to play
with JIT
 >> as
 >>> early as possible would allow the community to experiment using
PHP in
 >>> areas where it doesn't fit right now. Having to wait 2 more
years to
 >>> discover that maybe it's useful to build some new libraries
could be a
 >>> waste of time at the tactical level (there are other
technologies around
 >>> that move fast also :) )
 >>>
 >>> Not to detract from the technical challenges of moving in this
direction,
 >>> of course.
 >>> Just my 2cts from a "userland" guy :)
 >>>
 >>> Nicolas
 >>>
 >>
 >> Hello everyone,
 >>
 >> I agree with this sentiment and the general idea of shipping JIT as
 >> experimental in 7.4 and required to build with a configure flag.
 >> master for 8.0 is going to contain much more and be more
unstable and not
 >> practical for testing what JIT can do at that point due to all other
 >> features and improvements going into it like additional
optimizations and
 >> platform support.
 >> It will give me, as a userland developer, a platform where I can
actually
 >> play with it early and on a stable platform. And I understand
what I'm
 >> doing at that point.
 >>
 >> --
 >> Arvīds Godjuks
 >>
 >> +371 26 851 664
 >> arvids.godjuks@gmail.com <mailto:arvids.godjuks@gmail.com>
 >> Skype: psihius
 >> Telegram: @psihius https://t.me/psihius

пт, 15 февр. 2019 г. в 13:05, Benjamin Eberlei kontakt@beberlei.de:

Just two things.

I definitely don't think, I "just made it 100x more complicated".
I hate complication, and trying to make things simpler and more
efficient. This, sometime, involves new more or less isolated subsystems
like optimizer and now JIT. Of course, they look complex, if you are not
experienced in these areas. But PHP core may work without them.

Nobody will port their complex applications to PHP-8 preview, just to
try JIT. Having this possibility in PHP-7.4 would involve broader
auditory.

The majority of people uses PHP from pre compiled sources (99%+),

With 7.4 there are just two options:

1. we add jit as a flag called --enable-experimental-jit - which no
   distribution will do, and you don't have additional exposure with this
   approach.
2. or you add it as --enable-jit, and distributions might assume its
   stable and ship it by default, causing potential stability problems.

Both cases are not preferrable to 8.0 master snapshots in my opinion.

Well, for production you probably are not gonna use JIT anyway with 7.4, so
not really an issue about distributions. But we have docker, so if there is
a docker image with the JIT - we can use that for testing and local
development.

--
Arvīds Godjuks

+371 26 851 664
arvids.godjuks@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius

Just two things.

I definitely don't think, I "just made it 100x more complicated".
I hate complication, and trying to make things simpler and more
efficient. This, sometime, involves new more or less isolated subsystems
like optimizer and now JIT. Of course, they look complex, if you are not
experienced in these areas. But PHP core may work without them.

Nobody will port their complex applications to PHP-8 preview, just to
try JIT. Having this possibility in PHP-7.4 would involve broader auditory.

Thanks. Dmitry.

Perhaps I missed this part, but is "port to PHP 8-preview" or "port to JIT"
even a thing? Presumably, just like with 7.0, any reasonably well-behaved
application would be able to run without modification or with only minor
modification on 8.0, no?

I mean, if someone wanted to try out their massive application to see if the
JIT helped it, why would it be more work than (psuedocode):

git clone myapp.git
cd myapp
docker run php8-preview
open web browser

--Larry Garfield

Hello internals.

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

Den tir. 5. feb. 2019 kl. 20.48 skrev Niklas Keller me@kelunik.com:

Shouldn't we introduce annotations instead of relying on doc comments?

Yeah I'm not too happy with that approach either. I would rather see
another way to do this and like you said; annotations is probably the
best way to go about it as introducing a new keyword is not very
suitable imo.

Attributes were proposed ~3 years ago.
https://wiki.php.net/rfc/attributes
There were few other releted proposals.
But they didn't pass.

Understanding and adoptions of annotations (Doctrine mainly afaics)
have change. I think it is tricky to define it in a way that it can be
useful and adopted as a core language feature, meaning being flexible
enough to be extendable and usable as a base for userland extensions.
That latter part is the biggest challenge. What do the actual
users/authors of the current userland implementation think? (pls other
thread? :)

Best,

---

Pierre

@pierrejoye

---

In the past few weeks i have been mainly using hack-lang and the attributes API has changed as of 3.29 ( https://hhvm.com/blog/2018/10/22/hhvm-3.29.html - change actually landed on 4.0 instead ) and i think its a good approach that php can take too.

I have no experience with C so i don't know how this would work out for PHP, but i made a gist with a simple example on how it would be in :
https://gist.github.com/azjezz/918e333646d4f4070ab0be4cb41a81de

On Mon, Feb 4, 2019 at 11:48 PM Benjamin Eberlei kontakt@beberlei.de
wrote:

On Mon, Feb 4, 2019 at 10:29 PM Benjamin Eberlei kontakt@beberlei.de
wrote:

Hi Internals,

I'm glad to finally propose including JIT into PHP.

https://wiki.php.net/rfc/jit

In the current state it may be included both into PHP-8, where we are
going to continue active improvement, and into PHP-7.4, as an experimental
feature.

Can you give some information on if there are pre-conditions that must
hold for a function to be jitted, or quit conditions that force the JIT to
be reverted for a function? In addition, it would be helpful for testing if
there was a way to find out if a function was jitted, maybe through
ReflectionMethod/Function or opcache_get_status() ?

And as a follow up, the JIT seems to affect zend_execute_ex and
zend_execute_internal based profiling (tested with tideways_xhprof) in a
way that all Jitted functions are not called through those two hooks
anymore, and don't appear in profiling data anymore. Is that a correct
description? The number of parent=>child call entries drops from 88 to 12
in my sample code when jit is activated.

Is that a desired side-effect?

Opening this tree of the discussion again with my research findings on JIT

• production tracing.

I want to discuss a few ways forward:

1. Joe prototyped a solution how to instrument userland code that is JIT
   compatible right now without php-src changes. It swaps zend_op_array with
   an additional zend_internal_function wrapper acting as a decorator for each
   entry in CG(function_table) that is instrumented. Code for this approach
   can be found here: https://github.com/beberlei/php-overload-poc/ - but it
   requires some more work, specifically Joe said it must be turned into a
   zend_extension to get fully working.

This approach would help with extensions that currently instrument very
specific functions (mysqli_query, curl_exec, ....) such as tideways,
dd_trace, NewRelics (and other APM vendors).

Downside is it requires to overwrite debug_backtrace to filter out the
double frames and potentially has problems with the ReflectionFunction /
ReflectionMethod API having subtly different behaviors for internal and
userland functions. And this would probably lead to problems when multiple
extensiosn use the same approach.

It would not work with full function profilers such as Blackfire, php-spx,
that don't know the functions they instrument, instrument all the
functions. I don't include xdebug in that list, because it is mostly used
in non production evnironments that don't use the JIT, but the other
profilers are explicitly for production usage.

It would also not work with extensions that allow developers to instrument
class+methods / functions at runtime, such as dd_trace [1] and tideways

2. Another approach could be to generalize this approach
   stackdriver-debugger [2] has by modifying the AST to include the profiling
   code. But having additional internal fucntion calls "profiler_start" +
   "profiler_stop" there would have a lot more overhead than execute_ex
   wrappers currently do. Alternatively the engine could introduce new opcodes
   for enter/leave tracing that directly translate to a C call to newly
   created hooks and could also get JIT support.

This could be generalized to the point where php-src provides the code for
the ast injection so that extensions could just re-use it. I think this
would be the cleanest approach.

3. Separating execute_ex from the desire to do tracing would be possible if
   we introduce a new hook "zend_trace_function(int enterOrExit, const char
   *class_name, const char *function_name, zval *args, zval *returnValue);" .
   I am not sure if the JIT could actually call this hook, probably not
   because args and returnValue might not be in zval representation. I haven't
   looked this deeply into the JIT yet.

As a benefit this new hook would prevent tracing/profiling extensions from
forcing the VM to generate the more inefficient opcodes for function calls
by overwriting zend_execute_ex

4. A last solution for the specific function instrumentation (not feasible
   for generic profilers though) would be an API to register functions that
   extensions consider "@nojit" which extensions could do on MINIT:

opcache_jit_mark_nojit_func("my_function");
opcache_jit_mark_nojit_method("MyClass", "method");

This would allow extensions to always see these calls in zend_execute_ex
callbacks.

@Dmitry: What do you think about a path forward here for a solution that
enables production tracing?

[1]
https://github.com/DataDog/dd-trace-php/blob/master/src/DDTrace/Integrations/PDO/PDOIntegration.php#L44
[2]
https://github.com/GoogleCloudPlatform/stackdriver-debugger-php-extension/blob/master/stackdriver_debugger_ast.c

Thanks. Dmitry.

1.3-1.5 times speed-up

Dare I ask.

But is this even worth while?

This does not bring PHP to the level of performance where you could
reasonably implement, say, interpolated image resampling or a JPEG
decoder/encoder, correct?

This is still orders of magnitude slower than C, am I wrong?

Please don't think that I'm trying to shit on anybody's hard work, and
forgive me for asking, but how much maintenance overhead does the JIT add
to the language going forward?

Will this significantly slow down the development of every new language
feature?

If not, then by all means, please continue :-)

But if this is adding substantial maintenance overhead or significantly
increasing the barrier for contributions, I'd say, think very carefully
about this.

Developers are not picking a dynamic scripting language for the excellent
performance, unless we're talking near-C level performance (e.g. Lua-JIT
and, to my knowledge, not much else) and I don't get the impression this is
anywhere in that neighborhood?

Again, really not trying to bring down this very impressive piece of work -
but, as with any new language feature, we need to weigh complexity against
benefits, and I'm not convinced this kind of speed-up really opens PHP to
any new use-cases?

Being faster is always nice, but unless it's actually "fast", by which I
mean "fast enough to enable doing something new", it's only nice - it's not
necessarily a must.

For example, if this doesn't rival the performance of, say, WASM,
integration of a WASM engine might be a more worth while pursuit in the
long term.

Just wondering.

Please try not to see this post as aggressive or negative - I just hope
we're entering into such a major language change with eyes open? :-)

Thanks.

On Tue, Feb 5, 2019 at 6:06 PM Bruce Weirdan <weirdan@gmail.com
mailto:weirdan@gmail.com> wrote:

On Tue, Feb 5, 2019 at 8:38 AM Dmitry Stogov <dmitry@zend.com
<mailto:dmitry@zend.com>> wrote:
 > > PHP+optimizer (-dopcache.jit_buffer_size=0):  32.29s  (100%)
 > > PHP+optimizer+JIT (-dopcache.jit_buffer_size=50000000): 30.72s
(95.1%)
 > > PHP+optimizer+minimalJIT (-dopcache.jit_buffer_size=50000000
 > > -dopcache.jit=1201): 29.95s (92.7%)
 >
 > It may be interesting to try -dopcache.jit=1235. It should JIT
only hot
 > functions and requires some warm-up.

For this use case 1201 was the fastest of all the options I tried
(including 1235).

--

Here are my results of benchmarking rybakit/msgpack.php:

bench.php, w/o jit:
Total 9.8220 4.3121

bench.php, opcache.jit=1235 opcache.jit_buffer_size=256M:
Total 8.7255 3.3350

bench2.php, w/o jit:
pure msgpack: 2.2818 sec
pure msgpack packed: 2.1717 sec

bench2.php, opcache.jit=1235 opcache.jit_buffer_size=256M:
pure msgpack: 1.5221 sec
pure msgpack packed: 1.4739 sec

Details:
https://gist.github.com/rybakit/bb551f962b706a9e08c995cf5ed9762f

1.3-1.5 times speed-up.
Thanks for benchmarking.

Dmitry.

Hi Internals,

The RFC and implementation was updated once again.

https://wiki.php.net/rfc/jit

Now JIT supports PHP builds with compilers without GCC explicit global register variables extension.

This means we support CLANG/LLVM (Tested on Linux. Should work on Mac as well) and MSVC.

Complete Windows support is not implemented yet, but I don't see any big problems anymore.

ZTS support might be implemented after implementation of proposed TSRM API improvement.

Thanks. Dmitry.

Thanks for all the effort Dmitry, it's looking in much better shape.

Cheers
Joe

Hi Internals,

The RFC and implementation was updated once again.

https://wiki.php.net/rfc/jit

Now JIT supports PHP builds with compilers without GCC explicit global
register variables extension.

This means we support CLANG/LLVM (Tested on Linux. Should work on Mac as
well) and MSVC.

Complete Windows support is not implemented yet, but I don't see any big
problems anymore.

ZTS support might be implemented after implementation of proposed TSRM API
improvement.

Thanks. Dmitry.

---

From: Dmitry Stogov dmitry@zend.com
Sent: Wednesday, February 13, 2019 16:07
To: PHP internals
Subject: Re: [PHP-DEV] [RFC] JIT

Hi Internals,

According to comments, code reviews and discussions, JIT RFC was
extended with few new sections.

Please, consider to review the RFC once again.

https://wiki.php.net/rfc/jit

Any suggestion for RFC improvement are welcome.

I'm not going to invest significant time into JIT implementation
improvement itself, at this point. So, ideas are also welcome, but don't
expect to get them implemented tomorrow.

Thanks. Dmitry.

Hi Internals,

I'm glad to finally propose including JIT into PHP.

https://wiki.php.net/rfc/jit

In the current state it may be included both into PHP-8, where we are
going to continue active improvement, and into PHP-7.4, as an
experimental feature.

Thanks. Dmitry.

Thanks to Anatol, who started working on Windows build and "enforced" me
to implement MSVC support :)

Thanks for all the effort Dmitry, it's looking in much better shape.

Cheers
Joe

On Fri, 22 Feb 2019 at 13:18, Dmitry Stogov <dmitry@zend.com
mailto:dmitry@zend.com> wrote:

Hi Internals,


The RFC and implementation was updated once again.


https://wiki.php.net/rfc/jit


Now JIT supports PHP builds with compilers without GCC explicit
global register variables extension.

This means we support CLANG/LLVM (Tested on Linux. Should work on
Mac as well) and MSVC.

Complete Windows support is not implemented yet, but I don't see any
big problems anymore.


ZTS support might be implemented after implementation of proposed
TSRM API improvement.


Thanks. Dmitry.


________________________________
From: Dmitry Stogov <dmitry@zend.com <mailto:dmitry@zend.com>>
Sent: Wednesday, February 13, 2019 16:07
To: PHP internals
Subject: Re: [PHP-DEV] [RFC] JIT

Hi Internals,

According to comments, code reviews and discussions, JIT RFC was
extended with few new sections.

Please, consider to review the RFC once again.

https://wiki.php.net/rfc/jit

Any suggestion for RFC improvement are welcome.

I'm not going to invest significant time into JIT implementation
improvement itself, at this point. So, ideas are also welcome, but don't
expect to get them implemented tomorrow.

Thanks. Dmitry.


 > Hi Internals,
 >
 >
 > I'm glad to finally propose including JIT into PHP.
 >
 >
 > https://wiki.php.net/rfc/jit
 >
 >
 > In the current state it may be included both into PHP-8, where we are
 > going to continue active improvement, and into PHP-7.4, as an
 > experimental feature.
 >
 >
 > Thanks. Dmitry.

Hi,

-----Original Message-----
From: Dmitry Stogov dmitry@zend.com
Sent: Friday, February 22, 2019 1:49 PM
To: Joe Watkins krakjoe@gmail.com
Cc: PHP internals internals@lists.php.net; Anatol Belski ab@php.net
Subject: Re: [PHP-DEV] [RFC] JIT

Thanks to Anatol, who started working on Windows build and "enforced" me
to implement MSVC support :)

Owing to Dmitry's great work on this, the Windows part is now in a very good shape. Zend/bench.php shows at least 4x better performance with Opcache+JIT vs. just Opcache on current master. A dev snapshot x64/NTS of the today's jit-dynasm branch are available here

https://windows.php.net/downloads/snaps/ostc/jit-dynasm/20190301/

Regards

Anatol

Thanks for all the effort Dmitry, it's looking in much better shape.

Cheers
Joe

On Fri, 22 Feb 2019 at 13:18, Dmitry Stogov <dmitry@zend.com
mailto:dmitry@zend.com> wrote:

Hi Internals,


The RFC and implementation was updated once again.


https://wiki.php.net/rfc/jit


Now JIT supports PHP builds with compilers without GCC explicit
global register variables extension.

This means we support CLANG/LLVM (Tested on Linux. Should work on
Mac as well) and MSVC.

Complete Windows support is not implemented yet, but I don't see any
big problems anymore.


ZTS support might be implemented after implementation of proposed
TSRM API improvement.


Thanks. Dmitry.


________________________________
From: Dmitry Stogov <dmitry@zend.com <mailto:dmitry@zend.com>>
Sent: Wednesday, February 13, 2019 16:07
To: PHP internals
Subject: Re: [PHP-DEV] [RFC] JIT

Hi Internals,

According to comments, code reviews and discussions, JIT RFC was
extended with few new sections.

Please, consider to review the RFC once again.

https://wiki.php.net/rfc/jit

Any suggestion for RFC improvement are welcome.

I'm not going to invest significant time into JIT implementation
improvement itself, at this point. So, ideas are also welcome, but don't
expect to get them implemented tomorrow.

Thanks. Dmitry.


 > Hi Internals,
 >
 >
 > I'm glad to finally propose including JIT into PHP.
 >
 >
 > https://wiki.php.net/rfc/jit
 >
 >
 > In the current state it may be included both into PHP-8, where we are
 > going to continue active improvement, and into PHP-7.4, as an
 > experimental feature.
 >
 >
 > Thanks. Dmitry.

JIT also works for non-ZTS PHP Windows builds now.

Thanks. Dmitry.

I've uploaded a build from the latest branch state https://windows.php.net/downloads/snaps/ostc/jit-dynasm/20190305/, NTS/x64/SSE2/PGO. For PGO training, I've omitted some apps like Drupal/Symfony, as they're not yet compatible with 8.0, still a slight improvement with Zend/bench.php does show.

Thanks

Anatol

-----Original Message-----
From: Dmitry Stogov dmitry@zend.com
Sent: Tuesday, March 5, 2019 3:38 PM
To: PHP internals internals@lists.php.net
Cc: Anatol Belski ab@php.net; Joe Watkins krakjoe@gmail.com
Subject: Re: [PHP-DEV] [RFC] JIT

JIT also works for non-ZTS PHP Windows builds now.

Thanks. Dmitry.

---

From: Anatol Belski weltling@outlook.de on behalf of Anatol Belski
ab@php.net
Sent: Friday, March 1, 2019 3:47:07 PM
To: Dmitry Stogov; Joe Watkins
Cc: PHP internals
Subject: RE: [PHP-DEV] [RFC] JIT

Hi,

-----Original Message-----
From: Dmitry Stogov dmitry@zend.com
Sent: Friday, February 22, 2019 1:49 PM
To: Joe Watkins krakjoe@gmail.com
Cc: PHP internals internals@lists.php.net; Anatol Belski
ab@php.net
Subject: Re: [PHP-DEV] [RFC] JIT

Thanks to Anatol, who started working on Windows build and "enforced"
me to implement MSVC support :)

Owing to Dmitry's great work on this, the Windows part is now in a very
good shape. Zend/bench.php shows at least 4x better performance with
Opcache+JIT vs. just Opcache on current master. A dev snapshot x64/NTS of
the today's jit-dynasm branch are available here

https://windows.php.net/downloads/snaps/ostc/jit-dynasm/20190301/

Regards

Anatol

Thanks for all the effort Dmitry, it's looking in much better shape.

Cheers
Joe

On Fri, 22 Feb 2019 at 13:18, Dmitry Stogov <dmitry@zend.com
mailto:dmitry@zend.com> wrote:

Hi Internals,


The RFC and implementation was updated once again.


https://wiki.php.net/rfc/jit


Now JIT supports PHP builds with compilers without GCC explicit
global register variables extension.

This means we support CLANG/LLVM (Tested on Linux. Should work on
Mac as well) and MSVC.

Complete Windows support is not implemented yet, but I don't see any
big problems anymore.


ZTS support might be implemented after implementation of proposed
TSRM API improvement.


Thanks. Dmitry.


________________________________
From: Dmitry Stogov <dmitry@zend.com <mailto:dmitry@zend.com>>
Sent: Wednesday, February 13, 2019 16:07
To: PHP internals
Subject: Re: [PHP-DEV] [RFC] JIT

Hi Internals,

According to comments, code reviews and discussions, JIT RFC was
extended with few new sections.

Please, consider to review the RFC once again.

https://wiki.php.net/rfc/jit

Any suggestion for RFC improvement are welcome.

I'm not going to invest significant time into JIT implementation
improvement itself, at this point. So, ideas are also welcome, but don't
expect to get them implemented tomorrow.

Thanks. Dmitry.


 > Hi Internals,
 >
 >
 > I'm glad to finally propose including JIT into PHP.
 >
 >
 > https://wiki.php.net/rfc/jit
 >
 >
 > In the current state it may be included both into PHP-8, where we are
 > going to continue active improvement, and into PHP-7.4, as an
 > experimental feature.
 >
 >
 > Thanks. Dmitry.

Hi Internals,

I'm glad to finally propose including JIT into PHP.

https://wiki.php.net/rfc/jit

In the current state it may be included both into PHP-8, where we are
going to continue active improvement, and into PHP-7.4, as an
experimental feature.

Thanks. Dmitry.

JIT also works for non-ZTS PHP Windows builds now.

Thanks. Dmitry.

I've uploaded a build from the latest branch state
https://windows.php.net/downloads/snaps/ostc/jit-dynasm/20190305/,
NTS/x64/SSE2/PGO. For PGO training, I've omitted some apps like
Drupal/Symfony, as they're not yet compatible with 8.0, still a
slight improvement with Zend/bench.php does show.

Thanks

Anatol

I downloaded the Windows build and added the following settings to php.ini:
opcache.jit_buffer_size=10000000
opcache.jit=1205

I'm not sure if these are ideal settings or not, but they produced a
nearly 3x speed improvement in the spectral-norm benchmark with $n=100
(https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/spectralnorm-php-1.html).

Unfortunately I can't test with our real-world app since it relies on
the SQL Server extension (https://github.com/Microsoft/msphpsql)
which doesn't support PHP 8 yet.

I guess this would be one benefit to having the JIT be an experimental
feature in PHP 7.4 - extensions will likely support it long before
they support PHP 8 which will make it possible to test a lot more
real-world use cases.

Thanks,
Theodore Brown

Hi Theodore,

-----Original Message-----
From: Theodore Brown theodorejb@outlook.com
Sent: Thursday, March 7, 2019 5:11 PM
To: Anatol Belski ab@php.net; Dmitry Stogov dmitry@zend.com; PHP
internals internals@lists.php.net
Cc: Joe Watkins krakjoe@gmail.com
Subject: Re: [PHP-DEV] [RFC] JIT

Hi Internals,

I'm glad to finally propose including JIT into PHP.

https://wiki.php.net/rfc/jit

In the current state it may be included both into PHP-8, where we
are going to continue active improvement, and into PHP-7.4, as an
experimental feature.

Thanks. Dmitry.

On Tuesday, March 5, 2019 3:38 PM, Dmitry Stogov dmitry@zend.com
wrote:

JIT also works for non-ZTS PHP Windows builds now.

Thanks. Dmitry.

I've uploaded a build from the latest branch state
https://windows.php.net/downloads/snaps/ostc/jit-dynasm/20190305/,
NTS/x64/SSE2/PGO. For PGO training, I've omitted some apps like
Drupal/Symfony, as they're not yet compatible with 8.0, still a slight
improvement with Zend/bench.php does show.

Thanks

Anatol

I downloaded the Windows build and added the following settings to php.ini:
opcache.jit_buffer_size=10000000
opcache.jit=1205

I'm not sure if these are ideal settings or not, but they produced a nearly 3x
speed improvement in the spectral-norm benchmark with $n=100
(https://benchmarksgame-
team.pages.debian.net/benchmarksgame/program/spectralnorm-php-
1.html).

Unfortunately I can't test with our real-world app since it relies on the SQL
Server extension (https://github.com/Microsoft/msphpsql)
which doesn't support PHP 8 yet.

I guess this would be one benefit to having the JIT be an experimental
feature in PHP 7.4 - extensions will likely support it long before they support
PHP 8 which will make it possible to test a lot more real-world use cases.

Thanks for sharing this! Once the required extension becomes available, a snapshot could be created for the further tests. Otherwise I had Wordpress running and several other simple apps, so those can be used for the tests, too.

Regards

Anatol

Hi Internals,

https://wiki.php.net/rfc/jit

Now JIT also supports ZTS (checked on Linux and Windows).
Please, test and report problems.

So, complains about JIT compatibility matrix are satisfied.
It should be some incompatibilities with ZTS on Mac, but this easily
fixable.

I'll spend some additional time on code cleanup, and then start voting.

Ideas for RFC and code improvement are welcome.

Thanks. Dmitry.

Hi Internals,

I'm glad to finally propose including JIT into PHP.

https://wiki.php.net/rfc/jit

In the current state it may be included both into PHP-8, where we are going to continue active improvement, and into PHP-7.4, as an experimental feature.

Thanks. Dmitry.

Hi Internals,

https://wiki.php.net/rfc/jit

Now JIT also supports ZTS (checked on Linux and Windows).
Please, test and report problems.

So, complains about JIT compatibility matrix are satisfied.
It should be some incompatibilities with ZTS on Mac, but this easily
fixable.

I'll spend some additional time on code cleanup, and then start voting.

Ideas for RFC and code improvement are welcome.

I think this can still be done post RFC, but I am still very keen on
solving the tracing issue with a new unified API that:

• avoids zend_execute overwrites (to keep a stackless VM)
• works with VM and JIT
• works with internal and userland functions
• maybe allows some control for extension developers to run only on a
  selective number of calls (this can be implemented with AST processor and
  internal function handler overwrites).
• has access to arguments and return value

And an API in either reflection or opcache to find out which
functions/methods are jitted would also be helpful.
Testing with the jit branch currently its very hard to verify that it
actually works without turning debug output on.

Thanks. Dmitry.

Hi Internals,

I'm glad to finally propose including JIT into PHP.

https://wiki.php.net/rfc/jit

In the current state it may be included both into PHP-8, where we are
going to continue active improvement, and into PHP-7.4, as an experimental
feature.

Thanks. Dmitry.

Hi,

New Windows builds are available here https://windows.php.net/downloads/snaps/ostc/jit-dynasm/20190315/ . Anyone interested, especially usage with Apache, are encouraged to test hard :)

Thanks

Anatol

-----Original Message-----
From: Dmitry Stogov dmitry@zend.com
Sent: Friday, March 15, 2019 10:53 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] JIT

Hi Internals,

https://wiki.php.net/rfc/jit

Now JIT also supports ZTS (checked on Linux and Windows).
Please, test and report problems.

So, complains about JIT compatibility matrix are satisfied.
It should be some incompatibilities with ZTS on Mac, but this easily fixable.

I'll spend some additional time on code cleanup, and then start voting.

Ideas for RFC and code improvement are welcome.

Thanks. Dmitry.

Hi Internals,

I'm glad to finally propose including JIT into PHP.

https://wiki.php.net/rfc/jit

In the current state it may be included both into PHP-8, where we are going
to continue active improvement, and into PHP-7.4, as an experimental feature.

Thanks. Dmitry.

--
To unsubscribe, visit:
http://www.php.net/unsub.php