RE: [PHP-DEV] [RFC] JIT

[Anatol Belski]

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 
> 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.
> 
> 
> 
> On 1/31/19 12:43 PM, 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.
> >
> 
> --
> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:
> http://www.php.net/unsub.php


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Benjamin Eberlei]

On Fri, Mar 15, 2019 at 10:53 AM Dmitry Stogov  wrote:

> 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.
>
>
>
> On 1/31/19 12:43 PM, 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.
> >
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

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.



On 1/31/19 12:43 PM, 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.
> 

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [RFC] JIT

[Anatol Belski]

Hi Theodore,

> -Original Message-
> From: Theodore Brown 
> Sent: Thursday, March 7, 2019 5:11 PM
> To: Anatol Belski ; Dmitry Stogov ; PHP
> internals 
> Cc: Joe Watkins 
> Subject: Re: [PHP-DEV] [RFC] JIT
> 
> On Tuesday, March 5, 2019 3:52 PM, Anatol Belski  wrote:
> 
> > > On Thursday, January 31, 2019 12:43 PM, 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.
> >
> > On Tuesday, March 5, 2019 3:38 PM, Dmitry Stogov 
> 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=1000
> 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

Re: [PHP-DEV] [RFC] JIT

[Theodore Brown]

On Tuesday, March 5, 2019 3:52 PM, Anatol Belski  wrote:

> > On Thursday, January 31, 2019 12:43 PM, 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.
>
> On Tuesday, March 5, 2019 3:38 PM, Dmitry Stogov  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=1000
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [RFC] JIT

[Anatol Belski]

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 
> Sent: Tuesday, March 5, 2019 3:38 PM
> To: PHP internals 
> Cc: Anatol Belski ; Joe Watkins 
> Subject: Re: [PHP-DEV] [RFC] JIT
> 
> JIT also works for non-ZTS PHP Windows builds now.
> 
> 
> 
> 
> 
> Thanks. Dmitry.
> 
> 
> 
> 
> From: Anatol Belski  on behalf of Anatol Belski
> 
> 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 
> > Sent: Friday, February 22, 2019 1:49 PM
> > To: Joe Watkins 
> > Cc: PHP internals ; Anatol Belski
> > 
> > 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
> 
> > On 2/22/19 3:21 PM, Joe Watkins wrote:
> > > 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  > > <mailto:dmi...@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 mailto:dmi...@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.
> > >
> > > On 1/31/19 12:43 PM, 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.
> > >  >
> > >


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

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


Thanks. Dmitry.


From: Anatol Belski  on behalf of Anatol Belski 

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 
> Sent: Friday, February 22, 2019 1:49 PM
> To: Joe Watkins 
> Cc: PHP internals ; Anatol Belski 
> 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

> On 2/22/19 3:21 PM, Joe Watkins wrote:
> > 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  > <mailto:dmi...@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 mailto:dmi...@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.
> >
> > On 1/31/19 12:43 PM, 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.
> >  >
> >

RE: [PHP-DEV] [RFC] JIT

[Anatol Belski]

Hi,

> -Original Message-
> From: Dmitry Stogov 
> Sent: Friday, February 22, 2019 1:49 PM
> To: Joe Watkins 
> Cc: PHP internals ; Anatol Belski 
> 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

> On 2/22/19 3:21 PM, Joe Watkins wrote:
> > 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  > <mailto:dmi...@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 mailto:dmi...@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.
> >
> > On 1/31/19 12:43 PM, 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.
> >  >
> >

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

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

On 2/22/19 3:21 PM, Joe Watkins wrote:
> 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  <mailto:dmi...@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 mailto:dmi...@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.
> 
> On 1/31/19 12:43 PM, 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.
>  >
> 

Re: [PHP-DEV] [RFC] JIT

[Joe Watkins]

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  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 
> 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.
>
> On 1/31/19 12:43 PM, 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.
> >
>

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

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 
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.

On 1/31/19 12:43 PM, 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.
>

Re: [PHP-DEV] [RFC] JIT

[Rasmus Schultz]

> 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 Thu, Feb 14, 2019 at 7:45 AM Dmitry Stogov  wrote:

>
>
> On 2/14/19 3:02 AM, Eugene Leonovich wrote:
> > On Tue, Feb 5, 2019 at 6:06 PM Bruce Weirdan  > > wrote:
> >
> > On Tue, Feb 5, 2019 at 8:38 AM Dmitry Stogov  > > wrote:
> >  > > PHP+optimizer (-dopcache.jit_buffer_size=0):  32.29s  (100%)
> >  > > PHP+optimizer+JIT (-dopcache.jit_buffer_size=5000): 30.72s
> > (95.1%)
> >  > > PHP+optimizer+minimalJIT (-dopcache.jit_buffer_size=5000
> >  > > -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).
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> >
> > 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.
>

Re: [PHP-DEV] [RFC] JIT

[Benjamin Eberlei]

On Mon, Feb 4, 2019 at 11:48 PM Benjamin Eberlei 
wrote:

>
>
> On Mon, Feb 4, 2019 at 10:29 PM Benjamin Eberlei 
> wrote:
>
>>
>>
>> On Thu, Jan 31, 2019 at 10:44 AM 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.
>>>
>>
>> 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.
>>>
>>

Re: [PHP-DEV] [RFC] JIT

[azjezz]

Hello internals.


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, February 6, 2019 9:23 AM, Pierre Joye  
wrote:

> On Wed, Feb 6, 2019 at 3:17 PM Dmitry Stogov dmi...@zend.com wrote:
>
> > On 2/5/19 10:31 PM, Kalle Sommer Nielsen wrote:
> >
> > > Den tir. 5. feb. 2019 kl. 20.48 skrev Niklas Keller m...@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
>
> 
>
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php


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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Larry Garfield]

On Friday, February 15, 2019 3:36:40 AM CST Dmitry Stogov wrote:
> 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

signature.asc
Description: This is a digitally signed message part.

Re: [PHP-DEV] [RFC] JIT

[Arvids Godjuks]

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

>
>
> On Fri, Feb 15, 2019 at 10:37 AM Dmitry Stogov  wrote:
>
>> 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.godj...@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

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.

On 2/15/19 11:56 AM, Joe Watkins wrote:
> 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 

Re: [PHP-DEV] [RFC] JIT

[Joe Watkins]

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 

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

Hi,

On 2/14/19 5:22 PM, Joe Watkins wrote:
> 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 
> wrote:
> 
>> чт, 14 февр. 2019 г. в 14:54, Nicolas Grekas >> :
>>
 [...] 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.godj...@gmail.com
>> Skype: psihius
>> Telegram: @psihius https://t.me/psihius
>>
> 

Re: [PHP-DEV] [RFC] JIT

[Rowan Collins]

On Thu, 14 Feb 2019 at 13:34, Arvids Godjuks 
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]

Re: [PHP-DEV] [RFC] JIT

[Joe Watkins]

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 
wrote:

> чт, 14 февр. 2019 г. в 14:54, Nicolas Grekas  >:
>
> > > [...] 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.godj...@gmail.com
> Skype: psihius
> Telegram: @psihius https://t.me/psihius
>

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 2/14/19 2:38 PM, Zeev Suraski wrote:
> On Thu, Feb 14, 2019 at 12:19 PM Nikita Popov  wrote:
>> On Thu, Feb 14, 2019 at 10:43 AM Zeev Suraski  wrote:
>>> On Thu, Feb 14, 2019 at 10:20 AM Sebastian Bergmann 

>>   * 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.

Re: [PHP-DEV] [RFC] JIT

[Arvids Godjuks]

чт, 14 февр. 2019 г. в 14:54, Nicolas Grekas :

> > [...] 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.godj...@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius

Re: [PHP-DEV] [RFC] JIT

[Björn Larsson]

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.

On 1/31/19 12:43 PM, 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.


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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Nicolas Grekas]

> [...] 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

Re: [PHP-DEV] [RFC] JIT

[Zeev Suraski]

On Thu, Feb 14, 2019 at 12:17 PM Rowan Collins 
wrote:

> On Thu, 14 Feb 2019 at 09:43, Zeev Suraski  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

Re: [PHP-DEV] [RFC] JIT

[Zeev Suraski]

On Thu, Feb 14, 2019 at 12:19 PM Nikita Popov  wrote:

> On Thu, Feb 14, 2019 at 10:43 AM Zeev Suraski  wrote:
>
> > On Thu, Feb 14, 2019 at 10:20 AM Sebastian Bergmann 
> > 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

Re: [PHP-DEV] [RFC] JIT

[Nikita Popov]

On Thu, Feb 14, 2019 at 10:43 AM Zeev Suraski  wrote:

> On Thu, Feb 14, 2019 at 10:20 AM Sebastian Bergmann 
> 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

Re: [PHP-DEV] [RFC] JIT

[Rowan Collins]

On Thu, 14 Feb 2019 at 09:43, Zeev Suraski  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.



> 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]

Re: [PHP-DEV] [RFC] JIT

[Zeev Suraski]

On Thu, Feb 14, 2019 at 10:20 AM Sebastian Bergmann 
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

Re: [PHP-DEV] [RFC] JIT

[Sebastian Bergmann]

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 2/14/19 3:02 AM, Eugene Leonovich wrote:
> On Tue, Feb 5, 2019 at 6:06 PM Bruce Weirdan  > wrote:
> 
> On Tue, Feb 5, 2019 at 8:38 AM Dmitry Stogov  > wrote:
>  > > PHP+optimizer (-dopcache.jit_buffer_size=0):  32.29s  (100%)
>  > > PHP+optimizer+JIT (-dopcache.jit_buffer_size=5000): 30.72s
> (95.1%)
>  > > PHP+optimizer+minimalJIT (-dopcache.jit_buffer_size=5000
>  > > -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).
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 
> 
> 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.

Re: [PHP-DEV] [RFC] JIT

[Eugene Leonovich]

On Tue, Feb 5, 2019 at 6:06 PM Bruce Weirdan  wrote:

> On Tue, Feb 5, 2019 at 8:38 AM Dmitry Stogov  wrote:
> > > PHP+optimizer (-dopcache.jit_buffer_size=0):  32.29s  (100%)
> > > PHP+optimizer+JIT (-dopcache.jit_buffer_size=5000): 30.72s (95.1%)
> > > PHP+optimizer+minimalJIT (-dopcache.jit_buffer_size=5000
> > > -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).
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

Re: [PHP-DEV] [RFC] JIT

[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.

On 1/31/19 12:43 PM, 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.
> 

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 2/6/19 12:26 PM, Nikita Popov wrote:
> On Mon, Feb 4, 2019 at 8:30 AM Dmitry Stogov  > wrote:
> 
> 
> 
> On 2/3/19 9:00 PM, Nikita Popov wrote:
>  > On Sun, Feb 3, 2019 at 5:16 PM Zeev Suraski  > wrote:
>  >
>  >>
>  >>> On 3 Feb 2019, at 16:43, Jan Ehrhardt  > wrote:
>  >>>
>  >>> Zeev Suraski in php.internals (Sun, 3 Feb 2019 11:02:56 +):
>  
>  
>   How is that related?
>  >>>
>  >>> It is directly related with your statement that "developers
> with other
>  >>> host OSs still use Linux for the actual PHP development". They
> don't use
>  >>> Linux for the actual PHP development. They are using Windows.
>  >>
>  >> That statement was in a certain context - for those who use
> containers and
>  >> Linux VMs, which is (as mentioned) a growing trend.  I think
> it's clear
>  >> that I'm not claiming it's everyone, or even the majority - but
> if it
>  >> wasn't clear - it should be now...
>  >>
>  >> Zeev
>  >>
>  >
>  > I feel like this discussion ended up going a bit astray, with a
> focus on
>  > only the issue of Windows support... While I think that we should
> endeavor
>  > to support at least Windows and MacOS before the JIT hits a
> release version
>  > of PHP, at this point in time (and for the purposes of the vote) the
>  > questions of maintenance and stability are the most important.
> 
> If we don't start, we definitively won't get support.
> 
> 
>  > Ultimately
>  > those questions can't really be answered until interested parties
> have
>  > reviewed the JIT codebase. To that end it would be helpful if:
>  >
>  > a) A PR of the JIT branch could be submitted against php-src, so
> there is a
>  > place for review comments and more technical discussions. (It
> might be
>  > necessary to squash, as GH doesn't deal with large history well.)
> 
> OK. Not sure about re-base.
> 
>  > b) The RFC (or some other place) is extended with some high-level
> design
>  > information on how the JIT works on a technical level. Some notes
> on how
>  > JIT bugs are usually debugged would also be very helpful.
> 
> 
> OK. I'll try to extend RFC with some design elements.
> 
> Thanks. Dmitry.
> 
> 
> As you probably spent a lot of time profiling the JIT, I'm wondering if 
> you have any insights about what the main issues are right now that 
> prevent better performance and what some idea to improve those would be.

Real-life apps more suffer from bad data locality and data set size.
One of the metric that shows, how good/bad progam is executes is CPI 
(Cycles per Instruction). You may measure it using Linux perf (perf 
stat) or estimate using callgrind.

For bench.php it's 0.5, for Wordpress 1.2. This means that Wordpress 
waste significantly more CPU time because of different stalls.

Even if we improve execution, using JIT, and reduce the amount of 
executed instructions, this doesn't proportionally affects CPU cycles 
(and time), because many data related stalls are still there.

> E.g. I don't think the JIT currently does any inlining (right?) and that 
> might be something that could give a benefit?

Absolutely.

Currently JIT keeps VM state in consistency, when it calls any standard 
VM handler, emits error/warning, throw exception, and just call any PHP 
API function. But this is not necessary for most fast paths.

And this is the challenge for the next JIT improvement iteration.

1) Instead of immediate JIT-ing the whole function after hot-counter 
triggering, we will perform low-cost initial profiling, collecting jump 
probabilities, real run-time types and values.

2) Then we will generate code only for fast paths, especially optimized 
for our cases (information, collected during profiling). This code is 
not going to keep the VM state and may implement inlining of PHP 
functions and other smart optimizations.

3) The fast-path code is going to include "guard" check for transitions 
to slow paths that were never executes during profiling, but that can't 
be eliminated by static analyses (SSA info).

4) In case of guard failure, we should jump form JIT execution to VM, 
restoring the VM state consistency. This process named "deoptimization".

I would recommend, spend some time reading related V8 presentations.

https://v8.dev/docs/turbofan


Thanks. Dmitry.

> 
> Nikita

Re: [PHP-DEV] [RFC] JIT

[Nikita Popov]

On Mon, Feb 4, 2019 at 8:30 AM Dmitry Stogov  wrote:

>
>
> On 2/3/19 9:00 PM, Nikita Popov wrote:
> > On Sun, Feb 3, 2019 at 5:16 PM Zeev Suraski  wrote:
> >
> >>
> >>> On 3 Feb 2019, at 16:43, Jan Ehrhardt  wrote:
> >>>
> >>> Zeev Suraski in php.internals (Sun, 3 Feb 2019 11:02:56 +):
> 
> 
>  How is that related?
> >>>
> >>> It is directly related with your statement that "developers with other
> >>> host OSs still use Linux for the actual PHP development". They don't
> use
> >>> Linux for the actual PHP development. They are using Windows.
> >>
> >> That statement was in a certain context - for those who use containers
> and
> >> Linux VMs, which is (as mentioned) a growing trend.  I think it's clear
> >> that I'm not claiming it's everyone, or even the majority - but if it
> >> wasn't clear - it should be now...
> >>
> >> Zeev
> >>
> >
> > I feel like this discussion ended up going a bit astray, with a focus on
> > only the issue of Windows support... While I think that we should
> endeavor
> > to support at least Windows and MacOS before the JIT hits a release
> version
> > of PHP, at this point in time (and for the purposes of the vote) the
> > questions of maintenance and stability are the most important.
>
> If we don't start, we definitively won't get support.
>
>
> > Ultimately
> > those questions can't really be answered until interested parties have
> > reviewed the JIT codebase. To that end it would be helpful if:
> >
> > a) A PR of the JIT branch could be submitted against php-src, so there
> is a
> > place for review comments and more technical discussions. (It might be
> > necessary to squash, as GH doesn't deal with large history well.)
>
> OK. Not sure about re-base.
>
> > b) The RFC (or some other place) is extended with some high-level design
> > information on how the JIT works on a technical level. Some notes on how
> > JIT bugs are usually debugged would also be very helpful.
>
>
> OK. I'll try to extend RFC with some design elements.
>
> Thanks. Dmitry.
>

As you probably spent a lot of time profiling the JIT, I'm wondering if you
have any insights about what the main issues are right now that prevent
better performance and what some idea to improve those would be. E.g. I
don't think the JIT currently does any inlining (right?) and that might be
something that could give a benefit?

Nikita

Re: [PHP-DEV] [RFC] JIT

[Pierre Joye]

On Wed, Feb 6, 2019 at 3:17 PM Dmitry Stogov  wrote:
> On 2/5/19 10:31 PM, Kalle Sommer Nielsen wrote:
> > Den tir. 5. feb. 2019 kl. 20.48 skrev Niklas Keller :
> >> 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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 2/5/19 10:31 PM, Kalle Sommer Nielsen wrote:
> Den tir. 5. feb. 2019 kl. 20.48 skrev Niklas Keller :
>> 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.

Thanks. Dmitry.

Re: [PHP-DEV] [RFC] JIT

[Matthew Brown]

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.

> On Feb 5, 2019, at 8:47 PM, Andrea Faulds  wrote:
> 
> 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
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Andrea Faulds]

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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Kalle Sommer Nielsen]

Den tir. 5. feb. 2019 kl. 20.48 skrev Niklas Keller :
> 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.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Niklas Keller]

> > 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?
>
> -dopcache.jit=1245 will lead to JIT only functions with @jit doc-comment
> tag. It's possible to extend this manual control.

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

Regards, Niklas

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Bruce Weirdan]

On Tue, Feb 5, 2019 at 8:38 AM Dmitry Stogov  wrote:
> > PHP+optimizer (-dopcache.jit_buffer_size=0):  32.29s  (100%)
> > PHP+optimizer+JIT (-dopcache.jit_buffer_size=5000): 30.72s (95.1%)
> > PHP+optimizer+minimalJIT (-dopcache.jit_buffer_size=5000
> > -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).

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Benjamin Eberlei]

On Tue, Feb 5, 2019 at 11:45 AM Dmitry Stogov  wrote:

>
>
> On 2/5/19 12:40 PM, Benjamin Eberlei wrote:
> >
> >
> > On Tue, Feb 5, 2019 at 7:46 AM Dmitry Stogov  > > wrote:
> >
> >
> >
> > On 2/5/19 1:48 AM, Benjamin Eberlei wrote:
> >  >
> >  >
> >  > On Mon, Feb 4, 2019 at 10:29 PM Benjamin Eberlei
> > mailto:kont...@beberlei.de>
> >  > >> wrote:
> >  >
> >  >
> >  >
> >  > On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov
> > mailto:dmi...@zend.com>
> >  > >> 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?
> >
> > -dopcache.jit=1245 will lead to JIT only functions with @jit
> > doc-comment
> > tag. It's possible to extend this manual control.
> >
> >
> > @jit works if I have full control over my code-base, but whenever I use
> > libraries/frameworks this kind of configuration is too static, and puts
> > a burden on open-source maintainers to figure out what they want to jit
> > or not for users.
> >
> > This option will not be very useful from a distributed maintenance
> > perspective, especially if you don't know if users pick 4 or 3, this is
> > too much configuration details/micro-management in my opinion,
> > especially given your argument that JIT is supposed to be as transparent
> > and behind the scenes as possible for users.
> >
> > In my opinion 4 should not be available to users.
>
> In some cases it may help (similar to "inline" in C).
> For better performance, I would recomend "hot counters trigger" - 3 or
> everything - 0.
>
> >
> >
> >  > 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() ?
> >
> > yes. This makes sense.
> >
> >  >
> >  > 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?
> >
> > Yes. This is, at least expected.
> > PHP profilers/debuggers may disable JIT and opcache for particular
> > request, setting "opcache.enable=0" in RINIT.
> >
> >
> > This may be acceptable for development profilers, but it is not for
> > production profiling such as Blackfire and Tideways. I see that
> > overwriting internal function pointers still works for hooks, so that
> > doesn't need improvement, but PHP extensions need a way to control
> > zend_execute_ex behavior, or get an alternative hook for jit based
> > execution.
>
> JIT doesn't make a lot of sense if it doesn't optimize the overhead of
> interpretation (nested calls to execute_ex, etc). It's clear, that it's
> more difficult to debug optimized native code. Most implementations
> fallback to interpretation when need debugging. Profiling of optimized
> code is possible, but requires additional hooks.
>

I understand, but its not about preventing execute_ex for all calls, just
for the 50ish that I am interested in, high level framework functions that
are probably not efficently Jitted anyways.

For Tideways as production profiler, I am obviously interested in users
having great performance, but our users trust us to instrument what is
necessary to find out what might be wrong.


> > For Xhprof style profilers, a hook that gets the class + function name
> > alone would be enough.
> >
> > For tracing profilers based on a whitelist of a few instrumented
> > functions like tideways, NewRelic and probably all other APM vendor
> > extensions, there needs to be a hook to selectively decide "don't JIT
> > this function", that can be hooked into from 0 to many extensions.
> > Example, Tideways hooks into the userland function Mage::logException(),
> > to detect that Magento has thrown an exception that leads to a 500 page
> > being rendered. It 

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 2/5/19 12:40 PM, Benjamin Eberlei wrote:
> 
> 
> On Tue, Feb 5, 2019 at 7:46 AM Dmitry Stogov  > wrote:
> 
> 
> 
> On 2/5/19 1:48 AM, Benjamin Eberlei wrote:
>  >
>  >
>  > On Mon, Feb 4, 2019 at 10:29 PM Benjamin Eberlei
> mailto:kont...@beberlei.de>
>  > >> wrote:
>  >
>  >
>  >
>  >     On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov
> mailto:dmi...@zend.com>
>  >     >> 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?
> 
> -dopcache.jit=1245 will lead to JIT only functions with @jit
> doc-comment
> tag. It's possible to extend this manual control.
> 
> 
> @jit works if I have full control over my code-base, but whenever I use 
> libraries/frameworks this kind of configuration is too static, and puts 
> a burden on open-source maintainers to figure out what they want to jit 
> or not for users.
> 
> This option will not be very useful from a distributed maintenance 
> perspective, especially if you don't know if users pick 4 or 3, this is 
> too much configuration details/micro-management in my opinion, 
> especially given your argument that JIT is supposed to be as transparent 
> and behind the scenes as possible for users.
> 
> In my opinion 4 should not be available to users.

In some cases it may help (similar to "inline" in C).
For better performance, I would recomend "hot counters trigger" - 3 or 
everything - 0.

> 
> 
>  >     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() ?
> 
> yes. This makes sense.
> 
>  >
>  > 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?
> 
> Yes. This is, at least expected.
> PHP profilers/debuggers may disable JIT and opcache for particular
> request, setting "opcache.enable=0" in RINIT.
> 
> 
> This may be acceptable for development profilers, but it is not for 
> production profiling such as Blackfire and Tideways. I see that 
> overwriting internal function pointers still works for hooks, so that 
> doesn't need improvement, but PHP extensions need a way to control 
> zend_execute_ex behavior, or get an alternative hook for jit based 
> execution.

JIT doesn't make a lot of sense if it doesn't optimize the overhead of 
interpretation (nested calls to execute_ex, etc). It's clear, that it's 
more difficult to debug optimized native code. Most implementations 
fallback to interpretation when need debugging. Profiling of optimized 
code is possible, but requires additional hooks.

> For Xhprof style profilers, a hook that gets the class + function name 
> alone would be enough.
> 
> For tracing profilers based on a whitelist of a few instrumented 
> functions like tideways, NewRelic and probably all other APM vendor 
> extensions, there needs to be a hook to selectively decide "don't JIT 
> this function", that can be hooked into from 0 to many extensions.
> Example, Tideways hooks into the userland function Mage::logException(), 
> to detect that Magento has thrown an exception that leads to a 500 page 
> being rendered. It should be possible to make sure this function never 
> gets jitted, so that I see its execution in zend_execute_ex.

It's easily possible to disable JIT-ing by implementing @nojit (it's 
pity, we didn't get attributes).

Thanks. Dmitry.

> 
> 
> In addition, JIT-ed functions now may be tracked by Linux perf
> (oprofile
> and Intel VTune).
> 
> $ perf record php -d opcache.huge_code_pages=0 -d
> opcache.jit_debug=0x10
> bench.php
> $ perf report
> 
> 
> I think you overestimate PHP users savyness in Linux level profiling, 
> maybe 1 in 100 knows how to use perf. In addition many PHP users don't 

Re: [PHP-DEV] [RFC] JIT

[Benjamin Eberlei]

On Tue, Feb 5, 2019 at 7:46 AM Dmitry Stogov  wrote:

>
>
> On 2/5/19 1:48 AM, Benjamin Eberlei wrote:
> >
> >
> > On Mon, Feb 4, 2019 at 10:29 PM Benjamin Eberlei  > > wrote:
> >
> >
> >
> > On Thu, Jan 31, 2019 at 10:44 AM 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.
> >
> >
> > 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?
>
> -dopcache.jit=1245 will lead to JIT only functions with @jit doc-comment
> tag. It's possible to extend this manual control.
>

@jit works if I have full control over my code-base, but whenever I use
libraries/frameworks this kind of configuration is too static, and puts a
burden on open-source maintainers to figure out what they want to jit or
not for users.

This option will not be very useful from a distributed maintenance
perspective, especially if you don't know if users pick 4 or 3, this is too
much configuration details/micro-management in my opinion, especially given
your argument that JIT is supposed to be as transparent and behind the
scenes as possible for users.

In my opinion 4 should not be available to users.


> > 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() ?
>
> yes. This makes sense.
>
> >
> > 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?
>
> Yes. This is, at least expected.
> PHP profilers/debuggers may disable JIT and opcache for particular
> request, setting "opcache.enable=0" in RINIT.
>

This may be acceptable for development profilers, but it is not for
production profiling such as Blackfire and Tideways. I see that overwriting
internal function pointers still works for hooks, so that doesn't need
improvement, but PHP extensions need a way to control zend_execute_ex
behavior, or get an alternative hook for jit based execution.

For Xhprof style profilers, a hook that gets the class + function name
alone would be enough.

For tracing profilers based on a whitelist of a few instrumented functions
like tideways, NewRelic and probably all other APM vendor extensions, there
needs to be a hook to selectively decide "don't JIT this function", that
can be hooked into from 0 to many extensions.

Example, Tideways hooks into the userland function Mage::logException(), to
detect that Magento has thrown an exception that leads to a 500 page being
rendered. It should be possible to make sure this function never gets
jitted, so that I see its execution in zend_execute_ex.


> In addition, JIT-ed functions now may be tracked by Linux perf (oprofile
> and Intel VTune).
>
> $ perf record php -d opcache.huge_code_pages=0 -d opcache.jit_debug=0x10
> bench.php
> $ perf report
>

I think you overestimate PHP users savyness in Linux level profiling, maybe
1 in 100 knows how to use perf. In addition many PHP users don't have root
on their servers (managed). And within Docker you don't even get there to
start perfing. Profilers that put user experience first must be PHP
extensions, so we need to make sure the basic level of hooking is possible
even though we have a JIT.


>
> Thanks. Dmitry.
>
>
>
> >
> >
> >
> > Thanks. Dmitry.
> >
>

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 2/5/19 1:48 AM, Benjamin Eberlei wrote:
> 
> 
> On Mon, Feb 4, 2019 at 10:29 PM Benjamin Eberlei  > wrote:
> 
> 
> 
> On Thu, Jan 31, 2019 at 10:44 AM 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.
> 
> 
> 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?

-dopcache.jit=1245 will lead to JIT only functions with @jit doc-comment 
tag. It's possible to extend this manual control.

> 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() ?

yes. This makes sense.

> 
> 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?

Yes. This is, at least expected.
PHP profilers/debuggers may disable JIT and opcache for particular 
request, setting "opcache.enable=0" in RINIT.

In addition, JIT-ed functions now may be tracked by Linux perf (oprofile 
and Intel VTune).

$ perf record php -d opcache.huge_code_pages=0 -d opcache.jit_debug=0x10 
bench.php
$ perf report

Thanks. Dmitry.



> 
> 
> 
> Thanks. Dmitry.
> 

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 2/4/19 11:39 PM, Bruce Weirdan wrote:
> After figuring out that opcache.jit_buffer_size is specified in bytes
> (not in megabytes, as RFC states)

Thanks for catching this. Fixed.

> I got ~5% speedup running
> vimeo/psalm (static analyzer) on its own codebase with default
> JIT flags and ~7.3% with minimal JIT (1201).
> 
> PHP+optimizer (-dopcache.jit_buffer_size=0):  32.29s  (100%)
> PHP+optimizer+JIT (-dopcache.jit_buffer_size=5000): 30.72s (95.1%)
> PHP+optimizer+minimalJIT (-dopcache.jit_buffer_size=5000
> -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.

Thanks. Dmitry.

Re: [PHP-DEV] [RFC] JIT

[Benjamin Eberlei]

On Mon, Feb 4, 2019 at 10:29 PM Benjamin Eberlei 
wrote:

>
>
> On Thu, Jan 31, 2019 at 10:44 AM 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.
>>
>
> 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?

>
>>
>> Thanks. Dmitry.
>>
>

Re: [PHP-DEV] [RFC] JIT

[Benjamin Eberlei]

On Thu, Jan 31, 2019 at 10:44 AM 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.
>

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() ?

>
>
> Thanks. Dmitry.
>

Re: [PHP-DEV] [RFC] JIT

[Bruce Weirdan]

After figuring out that opcache.jit_buffer_size is specified in bytes
(not in megabytes, as RFC states) I got ~5% speedup running
vimeo/psalm (static analyzer) on its own codebase with default
JIT flags and ~7.3% with minimal JIT (1201).

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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Nikita Popov]

On Mon, Feb 4, 2019 at 3:44 PM Nikita Popov  wrote:

> On Mon, Feb 4, 2019 at 2:26 PM Dmitry Stogov  wrote:
>
>>
>>
>> On 2/1/19 4:23 PM, Dmitry Stogov wrote:
>> >
>> >
>> > On 2/1/19 3:09 PM, Nikita Popov wrote:
>> >> On Thu, Jan 31, 2019 at 10:44 AM 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.
>> >>
>> >>
>> >> I would like to check if the JIT provides an improvement for
>> PHP-Parser.
>> >> Unfortunately I'm getting a segfault when running the tests. Should be
>> >> reproducible with
>> >>
>> >> git clone g...@github.com:nikic/PHP-Parser.git
>> >> cd PHP-Parser
>> >> composer install
>> >> php-jit vendor/bin/phpunit
>> >>
>> >> I tried to debug this. Unfortunately my gdb doesn't seem to work with
>> >> JIT: It hangs when the script starts running, on line
>> Zend/zend_gdb.c:84
>> >> in zend_gdb_register_code. I don't know if that's a bug or I need to do
>> >> something additional here (I'm using GNU gdb (Ubuntu 8.1-0ubuntu3)
>> >> 8.1.0.20180409-git).
>> >
>> > GDB takes enormous time registering too many JIT-ed functions...
>> > It should be possible to catch the name of problematic functions and the
>> > JIT only them (using PHPDOC trigger). I'll try to analyze the crash, but
>> > most probably, only on next week.
>>
>> I fixed the problem caused JIT to fail on PHP-Parser tests (it was
>> related to changes introduced by typed properties patch).
>>
>> I'm also going to disable automatic JIT code registration in GDB.
>>
>> Thanks. Dmitry.
>>
>
> Thanks. I was now able to run a PHP-Parser benchmark, which showed ~1.5x
> speedup with default JIT configuration. That's promising :)
>

Unfortunately I made a mistake here and benchmarked against vanilla PHP
without opcache (and more importantly the optimizer in opcache). Here are
the correct results (for repeated parsing of a large file):

PHP: 3.7s
PHP+optimizer: 3.2s
PHP+optimizer+JIT: 2.4s

So the speedup is ~1.3x rather than ~1.5x, which is still good.

I also ran the hello-world.php example of
https://github.com/amphp/http-server against wrk -c100 -d30 -t4 and got the
following results:

PHP: 9950 rps
PHP+optimizer: 10750 rps
PHP+optimizer+JIT: 11350 rps

So in this case the improvement is about 5%. (This is the HTTP 1.1 server,
HTTP 2 would also be interesting to try, but needs some more setup.)

Nikita

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 2/4/19 6:22 PM, Nikita Popov wrote:
> On Mon, Feb 4, 2019 at 4:11 PM Dmitry Stogov  > wrote:
> 
> 
> 
> On 2/4/19 5:44 PM, Nikita Popov wrote:
>  > On Mon, Feb 4, 2019 at 2:26 PM Dmitry Stogov  
>  > >> wrote:
>  >
>  >
>  >
>  >     On 2/1/19 4:23 PM, Dmitry Stogov wrote:
>  >      >
>  >      >
>  >      > On 2/1/19 3:09 PM, Nikita Popov wrote:
>  >      >> On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov
> mailto:dmi...@zend.com>
>  >     >
>  >      >> 
>   >      >>
>  >      >>      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 would like to check if the JIT provides an improvement for
>  >     PHP-Parser.
>  >      >> Unfortunately I'm getting a segfault when running the tests.
>  >     Should be
>  >      >> reproducible with
>  >      >>
>  >      >> git clone g...@github.com:nikic/PHP-Parser.git
>  >      >> cd PHP-Parser
>  >      >> composer install
>  >      >> php-jit vendor/bin/phpunit
>  >      >>
>  >      >> I tried to debug this. Unfortunately my gdb doesn't seem
> to work
>  >     with
>  >      >> JIT: It hangs when the script starts running, on line
>  >     Zend/zend_gdb.c:84
>  >      >> in zend_gdb_register_code. I don't know if that's a bug or I
>  >     need to do
>  >      >> something additional here (I'm using GNU gdb (Ubuntu
> 8.1-0ubuntu3)
>  >      >> 8.1.0.20180409-git).
>  >      >
>  >      > GDB takes enormous time registering too many JIT-ed
> functions...
>  >      > It should be possible to catch the name of problematic
> functions
>  >     and the
>  >      > JIT only them (using PHPDOC trigger). I'll try to analyze the
>  >     crash, but
>  >      > most probably, only on next week.
>  >
>  >     I fixed the problem caused JIT to fail on PHP-Parser tests
> (it was
>  >     related to changes introduced by typed properties patch).
>  >
>  >     I'm also going to disable automatic JIT code registration in GDB.
>  >
>  >     Thanks. Dmitry.
>  >
>  >
>  > Thanks. I was now able to run a PHP-Parser benchmark, which
> showed ~1.5x
>  > speedup with default JIT configuration. That's promising :)
>  >
>  > Next I want to try https://github.com/amphp/hpack (part of HTTP 2
>  > implementation), where I also expect good results. Currently
> there is a
>  > segfault while running tests.
> 
> Could you provide a quick instruction, how to reproduce this (in the
> same way like with PHP-Parser).
> 
> 
> The reproduce steps are basically the same in this case, just on a 
> different repo:
> 
> git clone g...@github.com:amphp/hpack.git
> cd hpack
> composer install
> php-jit vendor/bin/phpunit
> 
> Nikita

Fixed.

Re: [PHP-DEV] [RFC] JIT

[Eugene Leonovich]

On Mon, Feb 4, 2019 at 3:45 PM Zeev Suraski  wrote:

> 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.
>

Is there a docker image with JIT support that people can try?

Re: [PHP-DEV] [RFC] JIT

[Nikita Popov]

On Mon, Feb 4, 2019 at 4:11 PM Dmitry Stogov  wrote:

>
>
> On 2/4/19 5:44 PM, Nikita Popov wrote:
> > On Mon, Feb 4, 2019 at 2:26 PM Dmitry Stogov  > > wrote:
> >
> >
> >
> > On 2/1/19 4:23 PM, Dmitry Stogov wrote:
> >  >
> >  >
> >  > On 2/1/19 3:09 PM, Nikita Popov wrote:
> >  >> On Thu, Jan 31, 2019 at 10:44 AM 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.
> >  >>
> >  >>
> >  >> I would like to check if the JIT provides an improvement for
> > PHP-Parser.
> >  >> Unfortunately I'm getting a segfault when running the tests.
> > Should be
> >  >> reproducible with
> >  >>
> >  >> git clone g...@github.com:nikic/PHP-Parser.git
> >  >> cd PHP-Parser
> >  >> composer install
> >  >> php-jit vendor/bin/phpunit
> >  >>
> >  >> I tried to debug this. Unfortunately my gdb doesn't seem to work
> > with
> >  >> JIT: It hangs when the script starts running, on line
> > Zend/zend_gdb.c:84
> >  >> in zend_gdb_register_code. I don't know if that's a bug or I
> > need to do
> >  >> something additional here (I'm using GNU gdb (Ubuntu
> 8.1-0ubuntu3)
> >  >> 8.1.0.20180409-git).
> >  >
> >  > GDB takes enormous time registering too many JIT-ed functions...
> >  > It should be possible to catch the name of problematic functions
> > and the
> >  > JIT only them (using PHPDOC trigger). I'll try to analyze the
> > crash, but
> >  > most probably, only on next week.
> >
> > I fixed the problem caused JIT to fail on PHP-Parser tests (it was
> > related to changes introduced by typed properties patch).
> >
> > I'm also going to disable automatic JIT code registration in GDB.
> >
> > Thanks. Dmitry.
> >
> >
> > Thanks. I was now able to run a PHP-Parser benchmark, which showed ~1.5x
> > speedup with default JIT configuration. That's promising :)
> >
> > Next I want to try https://github.com/amphp/hpack (part of HTTP 2
> > implementation), where I also expect good results. Currently there is a
> > segfault while running tests.
>
> Could you provide a quick instruction, how to reproduce this (in the
> same way like with PHP-Parser).
>

The reproduce steps are basically the same in this case, just on a
different repo:

git clone g...@github.com:amphp/hpack.git
cd hpack
composer install
php-jit vendor/bin/phpunit

Nikita

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 2/4/19 5:44 PM, Nikita Popov wrote:
> On Mon, Feb 4, 2019 at 2:26 PM Dmitry Stogov  > wrote:
> 
> 
> 
> On 2/1/19 4:23 PM, Dmitry Stogov wrote:
>  >
>  >
>  > On 2/1/19 3:09 PM, Nikita Popov wrote:
>  >> On Thu, Jan 31, 2019 at 10:44 AM 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.
>  >>
>  >>
>  >> I would like to check if the JIT provides an improvement for
> PHP-Parser.
>  >> Unfortunately I'm getting a segfault when running the tests.
> Should be
>  >> reproducible with
>  >>
>  >> git clone g...@github.com:nikic/PHP-Parser.git
>  >> cd PHP-Parser
>  >> composer install
>  >> php-jit vendor/bin/phpunit
>  >>
>  >> I tried to debug this. Unfortunately my gdb doesn't seem to work
> with
>  >> JIT: It hangs when the script starts running, on line
> Zend/zend_gdb.c:84
>  >> in zend_gdb_register_code. I don't know if that's a bug or I
> need to do
>  >> something additional here (I'm using GNU gdb (Ubuntu 8.1-0ubuntu3)
>  >> 8.1.0.20180409-git).
>  >
>  > GDB takes enormous time registering too many JIT-ed functions...
>  > It should be possible to catch the name of problematic functions
> and the
>  > JIT only them (using PHPDOC trigger). I'll try to analyze the
> crash, but
>  > most probably, only on next week.
> 
> I fixed the problem caused JIT to fail on PHP-Parser tests (it was
> related to changes introduced by typed properties patch).
> 
> I'm also going to disable automatic JIT code registration in GDB.
> 
> Thanks. Dmitry.
> 
> 
> Thanks. I was now able to run a PHP-Parser benchmark, which showed ~1.5x 
> speedup with default JIT configuration. That's promising :)
> 
> Next I want to try https://github.com/amphp/hpack (part of HTTP 2 
> implementation), where I also expect good results. Currently there is a 
> segfault while running tests.

Could you provide a quick instruction, how to reproduce this (in the 
same way like with PHP-Parser).

Thanks. Dmitry.

> 
> Nikita

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 2/4/19 1:32 PM, Andrea Faulds wrote:
> 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
> 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Nikita Popov]

On Mon, Feb 4, 2019 at 2:26 PM Dmitry Stogov  wrote:

>
>
> On 2/1/19 4:23 PM, Dmitry Stogov wrote:
> >
> >
> > On 2/1/19 3:09 PM, Nikita Popov wrote:
> >> On Thu, Jan 31, 2019 at 10:44 AM 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.
> >>
> >>
> >> I would like to check if the JIT provides an improvement for PHP-Parser.
> >> Unfortunately I'm getting a segfault when running the tests. Should be
> >> reproducible with
> >>
> >> git clone g...@github.com:nikic/PHP-Parser.git
> >> cd PHP-Parser
> >> composer install
> >> php-jit vendor/bin/phpunit
> >>
> >> I tried to debug this. Unfortunately my gdb doesn't seem to work with
> >> JIT: It hangs when the script starts running, on line Zend/zend_gdb.c:84
> >> in zend_gdb_register_code. I don't know if that's a bug or I need to do
> >> something additional here (I'm using GNU gdb (Ubuntu 8.1-0ubuntu3)
> >> 8.1.0.20180409-git).
> >
> > GDB takes enormous time registering too many JIT-ed functions...
> > It should be possible to catch the name of problematic functions and the
> > JIT only them (using PHPDOC trigger). I'll try to analyze the crash, but
> > most probably, only on next week.
>
> I fixed the problem caused JIT to fail on PHP-Parser tests (it was
> related to changes introduced by typed properties patch).
>
> I'm also going to disable automatic JIT code registration in GDB.
>
> Thanks. Dmitry.
>

Thanks. I was now able to run a PHP-Parser benchmark, which showed ~1.5x
speedup with default JIT configuration. That's promising :)

Next I want to try https://github.com/amphp/hpack (part of HTTP 2
implementation), where I also expect good results. Currently there is a
segfault while running tests.

Nikita

Re: [PHP-DEV] [RFC] JIT

[Zeev Suraski]

On Mon, Feb 4, 2019 at 12:33 PM Andrea Faulds  wrote:

> 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

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 2/1/19 4:23 PM, Dmitry Stogov wrote:
> 
> 
> On 2/1/19 3:09 PM, Nikita Popov wrote:
>> On Thu, Jan 31, 2019 at 10:44 AM 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.
>>
>>
>> I would like to check if the JIT provides an improvement for PHP-Parser.
>> Unfortunately I'm getting a segfault when running the tests. Should be
>> reproducible with
>>
>> git clone g...@github.com:nikic/PHP-Parser.git
>> cd PHP-Parser
>> composer install
>> php-jit vendor/bin/phpunit
>>
>> I tried to debug this. Unfortunately my gdb doesn't seem to work with
>> JIT: It hangs when the script starts running, on line Zend/zend_gdb.c:84
>> in zend_gdb_register_code. I don't know if that's a bug or I need to do
>> something additional here (I'm using GNU gdb (Ubuntu 8.1-0ubuntu3)
>> 8.1.0.20180409-git).
> 
> GDB takes enormous time registering too many JIT-ed functions...
> It should be possible to catch the name of problematic functions and the
> JIT only them (using PHPDOC trigger). I'll try to analyze the crash, but
> most probably, only on next week.

I fixed the problem caused JIT to fail on PHP-Parser tests (it was 
related to changes introduced by typed properties patch).

I'm also going to disable automatic JIT code registration in GDB.

Thanks. Dmitry.

> 
> Thanks. Dmitry.
> 
>>
>> Nikita
> 

Re: [PHP-DEV] [RFC] JIT

[Andrea Faulds]

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.


Thanks,
Andrea

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Nikita Popov]

On Mon, Feb 4, 2019 at 8:30 AM Dmitry Stogov  wrote:

>
>
> On 2/3/19 9:00 PM, Nikita Popov wrote:
> > On Sun, Feb 3, 2019 at 5:16 PM Zeev Suraski  wrote:
> >
> >>
> >>> On 3 Feb 2019, at 16:43, Jan Ehrhardt  wrote:
> >>>
> >>> Zeev Suraski in php.internals (Sun, 3 Feb 2019 11:02:56 +):
> 
> 
>  How is that related?
> >>>
> >>> It is directly related with your statement that "developers with other
> >>> host OSs still use Linux for the actual PHP development". They don't
> use
> >>> Linux for the actual PHP development. They are using Windows.
> >>
> >> That statement was in a certain context - for those who use containers
> and
> >> Linux VMs, which is (as mentioned) a growing trend.  I think it's clear
> >> that I'm not claiming it's everyone, or even the majority - but if it
> >> wasn't clear - it should be now...
> >>
> >> Zeev
> >>
> >
> > I feel like this discussion ended up going a bit astray, with a focus on
> > only the issue of Windows support... While I think that we should
> endeavor
> > to support at least Windows and MacOS before the JIT hits a release
> version
> > of PHP, at this point in time (and for the purposes of the vote) the
> > questions of maintenance and stability are the most important.
>
> If we don't start, we definitively won't get support.
>
>
> > Ultimately
> > those questions can't really be answered until interested parties have
> > reviewed the JIT codebase. To that end it would be helpful if:
> >
> > a) A PR of the JIT branch could be submitted against php-src, so there
> is a
> > place for review comments and more technical discussions. (It might be
> > necessary to squash, as GH doesn't deal with large history well.)
>
> OK. Not sure about re-base.
>
> > b) The RFC (or some other place) is extended with some high-level design
> > information on how the JIT works on a technical level. Some notes on how
> > JIT bugs are usually debugged would also be very helpful.
>
>
> OK. I'll try to extend RFC with some design elements.
>
> Thanks. Dmitry.
>

Thanks! Looks like the PR is here: https://github.com/php/php-src/pull/3792

Also, Joe has put up the JIT branch on the r11 lxr, which should make
browsing the code easier:
https://lxr.room11.org/xref/php-src%40jit/ext/opcache/jit/

Nikita

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 2/3/19 9:00 PM, Nikita Popov wrote:
> On Sun, Feb 3, 2019 at 5:16 PM Zeev Suraski  wrote:
> 
>>
>>> On 3 Feb 2019, at 16:43, Jan Ehrhardt  wrote:
>>>
>>> Zeev Suraski in php.internals (Sun, 3 Feb 2019 11:02:56 +):


 How is that related?
>>>
>>> It is directly related with your statement that "developers with other
>>> host OSs still use Linux for the actual PHP development". They don't use
>>> Linux for the actual PHP development. They are using Windows.
>>
>> That statement was in a certain context - for those who use containers and
>> Linux VMs, which is (as mentioned) a growing trend.  I think it's clear
>> that I'm not claiming it's everyone, or even the majority - but if it
>> wasn't clear - it should be now...
>>
>> Zeev
>>
> 
> I feel like this discussion ended up going a bit astray, with a focus on
> only the issue of Windows support... While I think that we should endeavor
> to support at least Windows and MacOS before the JIT hits a release version
> of PHP, at this point in time (and for the purposes of the vote) the
> questions of maintenance and stability are the most important.

If we don't start, we definitively won't get support.


> Ultimately
> those questions can't really be answered until interested parties have
> reviewed the JIT codebase. To that end it would be helpful if:
> 
> a) A PR of the JIT branch could be submitted against php-src, so there is a
> place for review comments and more technical discussions. (It might be
> necessary to squash, as GH doesn't deal with large history well.)

OK. Not sure about re-base.

> b) The RFC (or some other place) is extended with some high-level design
> information on how the JIT works on a technical level. Some notes on how
> JIT bugs are usually debugged would also be very helpful.


OK. I'll try to extend RFC with some design elements.

Thanks. Dmitry.

> 
> Regards,
> Nikita
> 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 2/1/19 7:30 PM, Larry Garfield wrote:
> On Friday, February 1, 2019 2:41:06 AM CST Dmitry Stogov wrote:
>> On 2/1/19 3:29 AM, Larry Garfield wrote:
> 
>>> Question from a non-compiler-engineer: Could we end up in a situation
>>> where
>>> future language features (in 8.3 or something) are only performant on JIT-
>>> enabled platforms?  I know there were some RFCs rejected in the past on
>>> the
>>> grounds that they involved too many runtime checks (and thus a performance
>>> hit); if it were possible for a JIT to optimize some of those away, it
>>> might make the cost acceptable.  However, if a JIT only works on some
>>> systems that might widen the gap between have- and have-not platforms.
>>
>> I think, JIT only approach doesn't make a lot of sense for PHP, with one
>> of the most fast VM. And this is a trend. Even V8, starting from JIT
>> only, switched back to VM+JIT.
>>
>> Thanks. Dmitry.
> 
> I'm... not sure how that answers my question?  I'm saying "if we had a VM+JIT,
> and the JIT part made feature X acceptably fast but it wasn't acceptably fast
> with just the VM, is that a problem?"  Or is that a situation that cannot
> happen?  Or that we don't care if it happens?

Everything is possible, but I don't think very realistic now.
When some features are going to depend on JIT, we might have much better 
JIT then now.

Thanks. Dmitry.

> 
> --Larry Garfield
> 

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Andrey Hristov]

 Guys,
On 3.02.19 г. 18:16 ч., Zeev Suraski wrote:



On 3 Feb 2019, at 16:43, Jan Ehrhardt  wrote:

Zeev Suraski in php.internals (Sun, 3 Feb 2019 11:02:56 +):



How is that related?


It is directly related with your statement that "developers with other
host OSs still use Linux for the actual PHP development". They don't use
Linux for the actual PHP development. They are using Windows.


That statement was in a certain context - for those who use containers and 
Linux VMs, which is (as mentioned) a growing trend.  I think it's clear that 
I'm not claiming it's everyone, or even the majority - but if it wasn't clear - 
it should be now...


please correct me but Docker containers can be run with Hyper-V 
isolation on recent Windows versions. This way the users of of these 
recent Windows versions can get directly the Linux performance jump.


And also, whoever hasn't started using containers while developing with 
PHP should start doing so and not to rely on *AMP tools for packaging.


Andrey


Zeev




--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Nikita Popov]

On Sun, Feb 3, 2019 at 5:16 PM Zeev Suraski  wrote:

>
> > On 3 Feb 2019, at 16:43, Jan Ehrhardt  wrote:
> >
> > Zeev Suraski in php.internals (Sun, 3 Feb 2019 11:02:56 +):
> >>
> >>
> >> How is that related?
> >
> > It is directly related with your statement that "developers with other
> > host OSs still use Linux for the actual PHP development". They don't use
> > Linux for the actual PHP development. They are using Windows.
>
> That statement was in a certain context - for those who use containers and
> Linux VMs, which is (as mentioned) a growing trend.  I think it's clear
> that I'm not claiming it's everyone, or even the majority - but if it
> wasn't clear - it should be now...
>
> Zeev
>

I feel like this discussion ended up going a bit astray, with a focus on
only the issue of Windows support... While I think that we should endeavor
to support at least Windows and MacOS before the JIT hits a release version
of PHP, at this point in time (and for the purposes of the vote) the
questions of maintenance and stability are the most important. Ultimately
those questions can't really be answered until interested parties have
reviewed the JIT codebase. To that end it would be helpful if:

a) A PR of the JIT branch could be submitted against php-src, so there is a
place for review comments and more technical discussions. (It might be
necessary to squash, as GH doesn't deal with large history well.)

b) The RFC (or some other place) is extended with some high-level design
information on how the JIT works on a technical level. Some notes on how
JIT bugs are usually debugged would also be very helpful.

Regards,
Nikita

Re: [PHP-DEV] [RFC] JIT

[Zeev Suraski]

> On 3 Feb 2019, at 16:43, Jan Ehrhardt  wrote:
> 
> Zeev Suraski in php.internals (Sun, 3 Feb 2019 11:02:56 +):
>> 
>> 
>> How is that related?
> 
> It is directly related with your statement that "developers with other
> host OSs still use Linux for the actual PHP development". They don't use
> Linux for the actual PHP development. They are using Windows.

That statement was in a certain context - for those who use containers and 
Linux VMs, which is (as mentioned) a growing trend.  I think it's clear that 
I'm not claiming it's everyone, or even the majority - but if it wasn't clear - 
it should be now...

Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Lester Caine]

On 03/02/2019 06:51, Zeev Suraski wrote:

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.



To add to that ... just how many windows based developers have actually 
moved to PHP7? I'd missed that the official windows package HAD dropped 
PEAR, but it's provided as part of the older third party windows 
distributions, and THOSE are the ones being used by the people I'm 
supporting because for a time there were no official distributions on 
windows.. THAT is the reason their code base has not move to PHP7 as it 
does not have access to all the third party packages being used.


While JIT should be totally transparent, is it not the case that 
invariably edge cases can cause different effects on different 
platforms, and it is perhaps that which is creating a concern if code 
can't be fully tested on a windows platform for that reason? In 
practice, it's academic, since if there are subtle differences between 
Linux and Windows it probably does not matter if JIT is enabled or not? 
One or other is simply displaying a bug that needs fixing?


Certainly production wise there is little evidence that W10 has done 
anything to improve the speed of the web stack which still lags far 
behind Linux on the same hardware, bu it's some time since I ACTUALLY 
tested that but perhaps it is time to update my own benchmarks.


--
Lester Caine - G8HFL
-
Contact - https://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - https://lsces.co.uk
EnquirySolve - https://enquirysolve.com/
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Jan Ehrhardt]

Zeev Suraski in php.internals (Sun, 3 Feb 2019 11:02:56 +):
>Jan Ehrhardt in php.internals (Sun, 03 Feb 2019 11:47:09 +0100):
>>Hi Zeev,
>>
>>Zeev Suraski in php.internals (Sun, 3 Feb 2019 07:05:49 +):
>>>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.
>>
>>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.
>
>How is that related?

It is directly related with your statement that "developers with other
host OSs still use Linux for the actual PHP development". They don't use
Linux for the actual PHP development. They are using Windows.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Zeev Suraski]

On 3 Feb 2019, at 12:47, Jan Ehrhardt 
mailto:php...@ehrhardt.nl>> wrote:

Hi Zeev,

Zeev Suraski in php.internals (Sun, 3 Feb 2019 07:05:49 +):
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

Re: [PHP-DEV] [RFC] JIT

[Jan Ehrhardt]

Hi Zeev,

Zeev Suraski in php.internals (Sun, 3 Feb 2019 07:05:49 +):
>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.

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.
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Zeev Suraski]

On 1 Feb 2019, at 18:30, Larry Garfield 
mailto:la...@garfieldtech.com>> wrote:

I'm... not sure how that answers my question?  I'm saying "if we had a VM+JIT,
and the JIT part made feature X acceptably fast but it wasn't acceptably fast
with just the VM, is that a problem?"  Or is that a situation that cannot
happen?  Or that we don't care if it happens?

Technically, you're absolutely right that this may happen.  For instance, if we 
decide to implement certain features in userland, factoring in the fact that 
JIT makes it fast enough - but without JIT it would be prohibitively slow - 
this could be a problem.  I do think that if we’d want to go in this direction, 
our platform support would likely have to be wider than it currently is.  But 
there are still two things that mitigate this issue to a large degree:

1.  Our VM is super quick, by far the quickest non-JITted dynamic language (to 
the best of our knowledge).  So VM would be slower, but depending on the 
specific use case - probably not dead slow.

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.

That said, again, we should probably evaluate it thoroughly before we come to 
rely on JIT for any must-have functionality.

Zeev

Re: [PHP-DEV] [RFC] JIT

[Zeev Suraski]

> On 3 Feb 2019, at 7:17, Ben Ramsey  wrote:
> 
>> On Thu, Jan 31, 2019, at 11:04, Zeev Suraski wrote:
>> 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

Re: [PHP-DEV] [RFC] JIT

[Ben Ramsey]

On Thu, Jan 31, 2019, at 11:04, Zeev Suraski wrote:
> 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.

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.

-Ben

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Andi Gutmans]

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 iOS<https://aka.ms/o0ukef>


From: Andrey Hristov 
Sent: Friday, February 1, 2019 3:49 AM
To: Pierre Joye
Cc: PHP internals
Subject: Re: [PHP-DEV] [RFC] JIT

Pierre,
On 1.02.19 г. 13:12 ч., Pierre Joye wrote:
> On Thu, Jan 31, 2019, 11:39 PM Dmitry Stogov 
>>
>>
>> I don't see any problems with including JIT without Windows support.
>> Windows runs PHP much slower any way.
>>
>
> How so? I tend to disagree here. Except if recent changes affect Windows
> indirectly (as in optimization done on linux only).
>
> Also while I use php on windows less, I still see a large amount of
> companies using php on windows, in similar ways than on Linux.
>
> Nikita concerns are valid, PHP is and should remain a cross platform
> language. And some top OSes besides linux should remain a target. Easier
> said than done and willing to help at least for windows. I am sure msft
> teams will step in as well.

considering how open is Microsoft to open source nowadays it is probably
a no brainer to have them help. They might only need some hinting :)

>>
>

Cheers,
Andrey


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Pierre Joye]

On Sat, Feb 2, 2019, 12:46 AM Levi Morrison

I strongly with Nikita's points on cost/benefit analysis. I have
> written a lot but thrown it away because I think this point is so
> important:
>
> It appears that the JIT does not work on Clang or MSVC compilers.


It must some changes needed for php or simply lack of time to test on
MSVC.  LibJit and DynAsm support it

As
> such, I consider this dead on arrival, even if it's considered
> experimental. There are cross-platform JIT's out there -- how do they
> manage it? I think that's the next critical step.
>

Re: [PHP-DEV] [RFC] JIT

[Levi Morrison]

On Thu, Jan 31, 2019 at 9:01 AM Nikita Popov  wrote:
>
> On Thu, Jan 31, 2019 at 10:44 AM 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.
> >
>
> This has been a long time on the horizon, nice to see this finally moving
> forward :)
>
> Here are some initial thoughts: I think that it's best to approach this
> issue from a cost/benefit angle. The benefits of the JIT compiler are
> roughly (and as already outlined in the RFC):
>
>  * Significantly better performance for numerical code.
>  * Slightly better performance for "typical" PHP web application code.
>  * The potential to move more code from C to PHP, because PHP will now be
> sufficiently fast.
>
> However, there are also a number of costs, on which I'll expand in more
> detail:
>
> a) Maintenance: This is really my main concern. Right now there are about
> 3-4 people who I would trust to carry out a non-trivial language change,
> which will require touching the compiler, the virtual machine, the
> optimizer and the persistence layer. Each of those components is quite
> complex, in different ways. Some people who are comfortable with doing VM
> changes will struggle with implementing optimizer changes.
>
> Adding a JIT compiler exacerbates this issue further. Because this JIT is
> dynasm based, the core JIT code is essentially written in raw x86 assembly.
> This will further limit the pool of people who will be able to make
> non-trivial engine changes. Personally, I don't have any particular
> familiarity with writing x86 assembly, so it will likely take a while to
> get up to speed with this code.
>
> b) Bugs and stability: I think that everyone is aware that the initial PHP
> 7.3 release suffered from substantial stability issues, more than new minor
> version releases tend to do. I think there are multiple reasons for that
> (and we might want to start a conversation about our QA processes in a
> separate thread), but one main contributing factor were opcache optimizer
> bugs. Compiler optimizations are tricky and hard to verify, and we often
> only learn about issues once the optimizer makes contact with production
> codebases, which feature a much richer collection of code patterns than our
> test suite. One can wonder whether the relatively minor speedups we get
> from our optimization framework are really worth having these stability
> issues...
>
> Adding a JIT compiler adds a new dimension of stability issues. Next to
> "simple" executor bugs, and optimizer bugs, we now get additional bugs in
> the JIT. These are probably going to be hard to debug, as we'll have to
> drop down from our usual C-level tooling, down to inspecting assembly.
>
> c) Platform support: Having a JIT segregates platforms into two tiers:
> Those that have JIT support and those that don't. While that is not a
> problem per se, it does introduce some dangers. For example, if we decide
> to more parts of our C code into PHP because PHP is fast enough with a JIT,
> that will of course only be true for platforms that actually have JIT
> support. I'm not terribly concerned about loosing out some performance on
> MIPS, but we do need to make sure that all our main platforms are supported
> (Windows is a must there, imho).
>
> d) Debugging: I'm not sure whether or not this is an issue (maybe the RFC
> can clarify?), but I'm wondering if this will have an impact on things like
> XDebug. Will it be possible to using XDebug to accurately inspect variables
> at any point in time while the JIT is running? If not, that would be a big
> tooling regression.
>
> I think those are the main points that come to mind right now...
>
> Regards,
> Nikita

I strongly with Nikita's points on cost/benefit analysis. I have
written a lot but thrown it away because I think this point is so
important:

It appears that the JIT does not work on Clang or MSVC compilers. As
such, I consider this dead on arrival, even if it's considered
experimental. There are cross-platform JIT's out there -- how do they
manage it? I think that's the next critical step.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Rowan Collins]

On Fri, 1 Feb 2019 at 13:12, Dmitry Stogov  wrote:

> >I'm not keen on the idea of merging this into 7.4, for various
> > reasons that don't need to be repeated.
>
> OK. It's not only your opinion.
> You may vote against, and persuade others.
>


I think it would be interesting to clarify the intended audience for an
experimental JIT in 7.4. Presumably, it would be marked as not suitable for
production, so would only be of interest to those experimenting with the
feature; but any problems they find might already be fixed in master, so
would it be better to encourage them to download a snapshot build of
8.0-pre-alpha and test there?

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] [RFC] JIT

[Larry Garfield]

On Friday, February 1, 2019 2:41:06 AM CST Dmitry Stogov wrote:
> On 2/1/19 3:29 AM, Larry Garfield wrote:

> > Question from a non-compiler-engineer: Could we end up in a situation
> > where
> > future language features (in 8.3 or something) are only performant on JIT-
> > enabled platforms?  I know there were some RFCs rejected in the past on
> > the
> > grounds that they involved too many runtime checks (and thus a performance
> > hit); if it were possible for a JIT to optimize some of those away, it
> > might make the cost acceptable.  However, if a JIT only works on some
> > systems that might widen the gap between have- and have-not platforms.
> 
> I think, JIT only approach doesn't make a lot of sense for PHP, with one
> of the most fast VM. And this is a trend. Even V8, starting from JIT
> only, switched back to VM+JIT.
> 
> Thanks. Dmitry.

I'm... not sure how that answers my question?  I'm saying "if we had a VM+JIT, 
and the JIT part made feature X acceptably fast but it wasn't acceptably fast 
with just the VM, is that a problem?"  Or is that a situation that cannot 
happen?  Or that we don't care if it happens?

--Larry Garfield

signature.asc
Description: This is a digitally signed message part.

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 2/1/19 4:23 PM, Nikita Popov wrote:
> On Fri, Feb 1, 2019 at 2:12 PM Dmitry Stogov  > wrote:
> 
> 
> 
> On 2/1/19 11:55 AM, Joe Watkins wrote:
>  > Morning Dmitry, and internals,
>  >
>  > This is marvellous stuff, truly brilliant. I particularly
> appreciate the
>  > non-intrusive approach of setting jit'd code as the opcode
> handler, this
>  > makes life a little easier for hacky extension authors, I think.
>  >
>  > As others have said:
>  >
>  >    I don't like the idea of omitting to support windows, less
> worried
>  > about fancy architectures.
> 
> I can provide help to people who will going to implement JIT support
> for
> Windows. This is not going to be easy, because MSVC doesn't support
> "hybrid VM" and "global register variables", therefore the code is
> going
> to be more expensive.
> 
> 
> I think an important point here is that this issue affects not only 
> Windows: It also affects any platform that uses clang as their compiler. 
> Notably this includes MacOS.
> 
> Clang theoretically supports global registers, but only for 
> non-allocatable regs (rsp and rbp), which I think is not very useful for 
> this purpose.

We will have to provide a patch for CLANG, implementing PHP VM calling 
convention (HHVM, Erlang, Haskel did this).

Thanks. Dmitry.

> 
> So this problem needs to be solved not just for Windows support, but 
> also for MacOS support (and also FreeBSD and other clang-using platforms).
> 
> Nikita
> 
>  >    I'm not keen on the idea that there is no way to debug the
> code this
>  > generates outside of GDB, and I'm not sure how useful gdb will
> be: I've
>  > tried to debug JIT'd code in that before and it doesn't do so
> well, but
>  > I could easily have been doing it wrong. I'd be very happy to be
>  > corrected about this ?
> 
> I'm not sure, what is wrong with GDB, and if any other debuggers have
> special API for run-time generated code.
> 
>  >    I'm not keen on the idea of merging this into 7.4, for various
>  > reasons that don't need to be repeated.
> 
> OK. It's not only your opinion.
> You may vote against, and persuade others.
> 
> Thanks. Dmitry.
> 
>  >
>  > Bottom line though, I love it, it's brilliant, and look forward
> to PHP 8.
>  >
>  > Thank you, Dmitry.
>  >
>  > Cheers
>  > Joe
>  >
>  >
>  > On Fri, 1 Feb 2019 at 09:41, Dmitry Stogov  
>  > >> wrote:
>  >
>  >
>  >
>  >     On 2/1/19 3:29 AM, Larry Garfield wrote:
>  >      > On Thursday, January 31, 2019 12:30:52 PM CST Chase Peeler
> wrote:
>  >      >> On Thu, Jan 31, 2019 at 12:04 PM Zeev Suraski
> mailto:z...@php.net>
>  >     >> wrote:
>  >      >>> On Thu, Jan 31, 2019 at 6:47 PM Kalle Sommer Nielsen
>  >     mailto:ka...@php.net>  >>
>  >      >>>
>  >      >>> wrote:
>  >       Without my usual Windows bias, I do believe it is a
>  >     considerable fact
>  >       like Nikita pointed out as Windows is a first class
> citizen in
>  >     terms
>  >       of operating systems we support. While PHP on Windows
> may not
>  >     have the
>  >       speed that the Unix counterpart have, it is still a
> very important
>  >       development platform. Many developers develop on
> Windows and
>  >     deploy on
>  >       a Unix based system, being unable to test such an important
>  >     feature in
>  >       a development environment is also a large question mark.
>  >      >>>
>  >      >>> As long as we can agree that very few actually *deploy *on
>  >     Windows, I
>  >      >>> think
>  >      >>> we're on solid grounds.
>  >      >>> As the JIT implementation is likely to have at least *some*
>  >     significant
>  >      >>> differences compared to Linux, I'm not sure what testing
> it on
>  >     Windows
>  >      >>> would give you.  JIT is supposed to be entirely transparent,
>  >     and the
>  >      >>> performance characteristics - as well as the bug
> patterns - are
>  >     likely to
>  >      >>> be quite different on Linux vs. Windows, at least in
> many cases.
>  >      >>> Is it really that important to have?
>  >      >>>
>  >      >>> 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.
>  >     

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 2/1/19 3:09 PM, Nikita Popov wrote:
> On Thu, Jan 31, 2019 at 10:44 AM 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.
> 
> 
> I would like to check if the JIT provides an improvement for PHP-Parser. 
> Unfortunately I'm getting a segfault when running the tests. Should be 
> reproducible with
> 
> git clone g...@github.com:nikic/PHP-Parser.git
> cd PHP-Parser
> composer install
> php-jit vendor/bin/phpunit
> 
> I tried to debug this. Unfortunately my gdb doesn't seem to work with 
> JIT: It hangs when the script starts running, on line Zend/zend_gdb.c:84 
> in zend_gdb_register_code. I don't know if that's a bug or I need to do 
> something additional here (I'm using GNU gdb (Ubuntu 8.1-0ubuntu3) 
> 8.1.0.20180409-git).

GDB takes enormous time registering too many JIT-ed functions...
It should be possible to catch the name of problematic functions and the 
JIT only them (using PHPDOC trigger). I'll try to analyze the crash, but 
most probably, only on next week.

Thanks. Dmitry.

> 
> Nikita

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Nikita Popov]

On Fri, Feb 1, 2019 at 2:12 PM Dmitry Stogov  wrote:

>
>
> On 2/1/19 11:55 AM, Joe Watkins wrote:
> > Morning Dmitry, and internals,
> >
> > This is marvellous stuff, truly brilliant. I particularly appreciate the
> > non-intrusive approach of setting jit'd code as the opcode handler, this
> > makes life a little easier for hacky extension authors, I think.
> >
> > As others have said:
> >
> >I don't like the idea of omitting to support windows, less worried
> > about fancy architectures.
>
> I can provide help to people who will going to implement JIT support for
> Windows. This is not going to be easy, because MSVC doesn't support
> "hybrid VM" and "global register variables", therefore the code is going
> to be more expensive.
>

I think an important point here is that this issue affects not only
Windows: It also affects any platform that uses clang as their compiler.
Notably this includes MacOS.

Clang theoretically supports global registers, but only for non-allocatable
regs (rsp and rbp), which I think is not very useful for this purpose.

So this problem needs to be solved not just for Windows support, but also
for MacOS support (and also FreeBSD and other clang-using platforms).

Nikita


> >I'm not keen on the idea that there is no way to debug the code this
> > generates outside of GDB, and I'm not sure how useful gdb will be: I've
> > tried to debug JIT'd code in that before and it doesn't do so well, but
> > I could easily have been doing it wrong. I'd be very happy to be
> > corrected about this ?
>
> I'm not sure, what is wrong with GDB, and if any other debuggers have
> special API for run-time generated code.
>
> >I'm not keen on the idea of merging this into 7.4, for various
> > reasons that don't need to be repeated.
>
> OK. It's not only your opinion.
> You may vote against, and persuade others.
>
> Thanks. Dmitry.
>
> >
> > Bottom line though, I love it, it's brilliant, and look forward to PHP 8.
> >
> > Thank you, Dmitry.
> >
> > Cheers
> > Joe
> >
> >
> > On Fri, 1 Feb 2019 at 09:41, Dmitry Stogov  > > wrote:
> >
> >
> >
> > On 2/1/19 3:29 AM, Larry Garfield wrote:
> >  > On Thursday, January 31, 2019 12:30:52 PM CST Chase Peeler wrote:
> >  >> On Thu, Jan 31, 2019 at 12:04 PM Zeev Suraski  > > wrote:
> >  >>> On Thu, Jan 31, 2019 at 6:47 PM Kalle Sommer Nielsen
> > mailto:ka...@php.net>>
> >  >>>
> >  >>> wrote:
> >   Without my usual Windows bias, I do believe it is a
> > considerable fact
> >   like Nikita pointed out as Windows is a first class citizen in
> > terms
> >   of operating systems we support. While PHP on Windows may not
> > have the
> >   speed that the Unix counterpart have, it is still a very
> important
> >   development platform. Many developers develop on Windows and
> > deploy on
> >   a Unix based system, being unable to test such an important
> > feature in
> >   a development environment is also a large question mark.
> >  >>>
> >  >>> As long as we can agree that very few actually *deploy *on
> > Windows, I
> >  >>> think
> >  >>> we're on solid grounds.
> >  >>> As the JIT implementation is likely to have at least *some*
> > significant
> >  >>> differences compared to Linux, I'm not sure what testing it on
> > Windows
> >  >>> would give you.  JIT is supposed to be entirely transparent,
> > and the
> >  >>> performance characteristics - as well as the bug patterns - are
> > likely to
> >  >>> be quite different on Linux vs. Windows, at least in many cases.
> >  >>> Is it really that important to have?
> >  >>>
> >  >>> 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.
> >  >>>
> >  >>> I'm personally interested in taking a look at it (and I'm
> certain
> >  >>>
> >   Anatol does too), but simply dismissing is a no-go for me.
> >  >>>
> >  >>> It'd be interesting to evaluate the cost associated with
> supporting
> >  >>> Windows.  Bare in mind, we're proposing to vote on this as a
> > production
> >  >>> feature for PHP 8 - which realistically means almost two years
> > from now
> >  >>> *at
> >  >>> the earliest*.  I'm sure we'd have Windows support a lot sooner
> > than that
> >  >>> if we decide that it's a must have.  I agree with Nikita that
> > the key
> >  >>> question is in fact, do we or do we not want to introduce JIT
> > in - with
> >  >>> the
> >  >>> main question being the maintenance cost.  Let's tackle this
> > question
> >  >>> first, otherwise - why send Dmitry (and maybe others) 

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 2/1/19 2:12 PM, Pierre Joye wrote:
> 
> 
> On Thu, Jan 31, 2019, 11:39 PM Dmitry Stogov   wrote:
> 
> 
> 
> I don't see any problems with including JIT without Windows support.
> Windows runs PHP much slower any way.
> 
> 
> How so? I tend to disagree here. Except if recent changes affect Windows 
> indirectly (as in optimization done on linux only).

More or less right. PHP uses GCC extensions, that are not available in MSVC.

> Also while I use php on windows less, I still see a large amount of 
> companies using php on windows,  in similar ways than on Linux.
> 
> Nikita concerns are valid, PHP is and should remain a cross platform 
> language. And some top OSes besides linux should remain a target. Easier 
> said than done and willing to help at least for windows. I am sure msft 
> teams will step in as well.

It would be great, if MSFT team helps.
I definitely, can't move JIT forward, and provide support for all 
platforms at the same time.

Thanks. Dmitry.

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 2/1/19 11:55 AM, Joe Watkins wrote:
> Morning Dmitry, and internals,
> 
> This is marvellous stuff, truly brilliant. I particularly appreciate the 
> non-intrusive approach of setting jit'd code as the opcode handler, this 
> makes life a little easier for hacky extension authors, I think.
> 
> As others have said:
> 
>    I don't like the idea of omitting to support windows, less worried 
> about fancy architectures.

I can provide help to people who will going to implement JIT support for 
Windows. This is not going to be easy, because MSVC doesn't support 
"hybrid VM" and "global register variables", therefore the code is going 
to be more expensive.

>    I'm not keen on the idea that there is no way to debug the code this 
> generates outside of GDB, and I'm not sure how useful gdb will be: I've 
> tried to debug JIT'd code in that before and it doesn't do so well, but 
> I could easily have been doing it wrong. I'd be very happy to be 
> corrected about this ?

I'm not sure, what is wrong with GDB, and if any other debuggers have 
special API for run-time generated code.

>    I'm not keen on the idea of merging this into 7.4, for various 
> reasons that don't need to be repeated.

OK. It's not only your opinion.
You may vote against, and persuade others.

Thanks. Dmitry.

> 
> Bottom line though, I love it, it's brilliant, and look forward to PHP 8.
> 
> Thank you, Dmitry.
> 
> Cheers
> Joe
> 
> 
> On Fri, 1 Feb 2019 at 09:41, Dmitry Stogov  > wrote:
> 
> 
> 
> On 2/1/19 3:29 AM, Larry Garfield wrote:
>  > On Thursday, January 31, 2019 12:30:52 PM CST Chase Peeler wrote:
>  >> On Thu, Jan 31, 2019 at 12:04 PM Zeev Suraski  > wrote:
>  >>> On Thu, Jan 31, 2019 at 6:47 PM Kalle Sommer Nielsen
> mailto:ka...@php.net>>
>  >>>
>  >>> wrote:
>   Without my usual Windows bias, I do believe it is a
> considerable fact
>   like Nikita pointed out as Windows is a first class citizen in
> terms
>   of operating systems we support. While PHP on Windows may not
> have the
>   speed that the Unix counterpart have, it is still a very important
>   development platform. Many developers develop on Windows and
> deploy on
>   a Unix based system, being unable to test such an important
> feature in
>   a development environment is also a large question mark.
>  >>>
>  >>> As long as we can agree that very few actually *deploy *on
> Windows, I
>  >>> think
>  >>> we're on solid grounds.
>  >>> As the JIT implementation is likely to have at least *some*
> significant
>  >>> differences compared to Linux, I'm not sure what testing it on
> Windows
>  >>> would give you.  JIT is supposed to be entirely transparent,
> and the
>  >>> performance characteristics - as well as the bug patterns - are
> likely to
>  >>> be quite different on Linux vs. Windows, at least in many cases.
>  >>> Is it really that important to have?
>  >>>
>  >>> 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.
>  >>>
>  >>> I'm personally interested in taking a look at it (and I'm certain
>  >>>
>   Anatol does too), but simply dismissing is a no-go for me.
>  >>>
>  >>> It'd be interesting to evaluate the cost associated with supporting
>  >>> Windows.  Bare in mind, we're proposing to vote on this as a
> production
>  >>> feature for PHP 8 - which realistically means almost two years
> from now
>  >>> *at
>  >>> the earliest*.  I'm sure we'd have Windows support a lot sooner
> than that
>  >>> if we decide that it's a must have.  I agree with Nikita that
> the key
>  >>> question is in fact, do we or do we not want to introduce JIT
> in - with
>  >>> the
>  >>> main question being the maintenance cost.  Let's tackle this
> question
>  >>> first, otherwise - why send Dmitry (and maybe others) for doing
> more work
>  >>> (Windows support) if we are likely to flush it all down the toilet?
>  >>>
>  >> Maybe we're the only ones, but we run production PHP on Windows.
> I have no
>  >> issues with the idea of not initially having support for
> Windows. I can
>  >> probably even live with never having support for Windows -
> provided that we
>  >> don't find ourselves in a situation like Nikita mentioned where
> features
>  >> start getting developed in PHP instead of C and require JIT in
> order to
>  >> function.
>  >
>  > Question from a non-compiler-engineer: Could we end up in a
> situation where
>  > future language features (in 8.3 or 

Re: [PHP-DEV] [RFC] JIT

[Nikita Popov]

On Fri, Feb 1, 2019 at 1:09 PM Nikita Popov  wrote:

> On Thu, Jan 31, 2019 at 10:44 AM 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.
>>
>
> I would like to check if the JIT provides an improvement for PHP-Parser.
> Unfortunately I'm getting a segfault when running the tests. Should be
> reproducible with
>
> git clone g...@github.com:nikic/PHP-Parser.git
> cd PHP-Parser
> composer install
> php-jit vendor/bin/phpunit
>
> I tried to debug this. Unfortunately my gdb doesn't seem to work with JIT:
> It hangs when the script starts running, on line Zend/zend_gdb.c:84 in
> zend_gdb_register_code. I don't know if that's a bug or I need to do
> something additional here (I'm using GNU gdb (Ubuntu 8.1-0ubuntu3)
> 8.1.0.20180409-git).
>
> Nikita
>

Another project that I would like to test is amp
(g...@github.com:amphp/amp.git).
Here I am getting a segfault only on shutdown, after tests finished
running. However there are a number of test failures, all basically looking
the same:

1) Amp\Test\AllTest::testPendingPromiseArray
TypeError: Return value of Amp\Loop\Internal\TimerQueue::removeAndRebuild()
must be an instance of Amp\Loop\Internal\TimerQueueEntry, null returned

/home/nikic/amp/lib/Loop/Internal/TimerQueue.php:100
/home/nikic/amp/lib/Loop/Internal/TimerQueue.php:64
/home/nikic/amp/lib/Loop/NativeDriver.php:107
/home/nikic/amp/lib/Loop/Driver.php:134
/home/nikic/amp/lib/Loop/Driver.php:72
/home/nikic/amp/lib/Loop.php:84
/home/nikic/amp/test/AllTest.php:52

Here is the line that incorrectly gets a null:
https://github.com/amphp/amp/blob/c6f8425473ecc1cfc6909cf42b39abb39a11c837/lib/Loop/Internal/TimerQueue.php#L100

Nikita

Re: [PHP-DEV] [RFC] JIT

[Nikita Popov]

On Thu, Jan 31, 2019 at 10:44 AM 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.
>

I would like to check if the JIT provides an improvement for PHP-Parser.
Unfortunately I'm getting a segfault when running the tests. Should be
reproducible with

git clone g...@github.com:nikic/PHP-Parser.git
cd PHP-Parser
composer install
php-jit vendor/bin/phpunit

I tried to debug this. Unfortunately my gdb doesn't seem to work with JIT:
It hangs when the script starts running, on line Zend/zend_gdb.c:84 in
zend_gdb_register_code. I don't know if that's a bug or I need to do
something additional here (I'm using GNU gdb (Ubuntu 8.1-0ubuntu3)
8.1.0.20180409-git).

Nikita

Re: [PHP-DEV] [RFC] JIT

[Andrey Hristov]

 Pierre,
On 1.02.19 г. 13:12 ч., Pierre Joye wrote:

On Thu, Jan 31, 2019, 11:39 PM Dmitry Stogov 


I don't see any problems with including JIT without Windows support.
Windows runs PHP much slower any way.



How so? I tend to disagree here. Except if recent changes affect Windows
indirectly (as in optimization done on linux only).

Also while I use php on windows less, I still see a large amount of
companies using php on windows,  in similar ways than on Linux.

Nikita concerns are valid, PHP is and should remain a cross platform
language. And some top OSes besides linux should remain a target. Easier
said than done and willing to help at least for windows. I am sure msft
teams will step in as well.


considering how open is Microsoft to open source nowadays it is probably 
a no brainer to have them help. They might only need some hinting :)








Cheers,
Andrey


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Pierre Joye]

On Thu, Jan 31, 2019, 11:39 PM Dmitry Stogov 
>
> I don't see any problems with including JIT without Windows support.
> Windows runs PHP much slower any way.
>

How so? I tend to disagree here. Except if recent changes affect Windows
indirectly (as in optimization done on linux only).

Also while I use php on windows less, I still see a large amount of
companies using php on windows,  in similar ways than on Linux.

Nikita concerns are valid, PHP is and should remain a cross platform
language. And some top OSes besides linux should remain a target. Easier
said than done and willing to help at least for windows. I am sure msft
teams will step in as well.

>

Re: [PHP-DEV] [RFC] JIT

[Andrey Hristov]

 Hi,
On 31.01.19 г. 18:47 ч., Kalle Sommer Nielsen wrote:

Den tor. 31. jan. 2019 kl. 18.39 skrev Dmitry Stogov :




On 1/31/19 7:01 PM, Nikita Popov wrote:

On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov mailto:dmi...@zend.com>> 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.


This has been a long time on the horizon, nice to see this finally
moving forward :)

Here are some initial thoughts: I think that it's best to approach this
issue from a cost/benefit angle. The benefits of the JIT compiler are
roughly (and as already outlined in the RFC):

   * Significantly better performance for numerical code.
   * Slightly better performance for "typical" PHP web application code.
   * The potential to move more code from C to PHP, because PHP will now
be sufficiently fast.

However, there are also a number of costs, on which I'll expand in more
detail:

a) Maintenance: This is really my main concern. Right now there are
about 3-4 people who I would trust to carry out a non-trivial language
change, which will require touching the compiler, the virtual machine,
the optimizer and the persistence layer. Each of those components is
quite complex, in different ways. Some people who are comfortable with
doing VM changes will struggle with implementing optimizer changes.

Adding a JIT compiler exacerbates this issue further. Because this JIT
is dynasm based, the core JIT code is essentially written in raw x86
assembly. This will further limit the pool of people who will be able to
make non-trivial engine changes. Personally, I don't have any particular
familiarity with writing x86 assembly, so it will likely take a while to
get up to speed with this code.

b) Bugs and stability: I think that everyone is aware that the initial
PHP 7.3 release suffered from substantial stability issues, more than
new minor version releases tend to do. I think there are multiple
reasons for that (and we might want to start a conversation about our QA
processes in a separate thread), but one main contributing factor were
opcache optimizer bugs. Compiler optimizations are tricky and hard to
verify, and we often only learn about issues once the optimizer makes
contact with production codebases, which feature a much richer
collection of code patterns than our test suite. One can wonder whether
the relatively minor speedups we get from our optimization framework are
really worth having these stability issues...

Adding a JIT compiler adds a new dimension of stability issues. Next to
"simple" executor bugs, and optimizer bugs, we now get additional bugs
in the JIT. These are probably going to be hard to debug, as we'll have
to drop down from our usual C-level tooling, down to inspecting assembly.

c) Platform support: Having a JIT segregates platforms into two tiers:
Those that have JIT support and those that don't. While that is not a
problem per se, it does introduce some dangers. For example, if we
decide to more parts of our C code into PHP because PHP is fast enough
with a JIT, that will of course only be true for platforms that actually
have JIT support. I'm not terribly concerned about loosing out some
performance on MIPS, but we do need to make sure that all our main
platforms are supported (Windows is a must there, imho).


I don't see any problems with including JIT without Windows support.
Windows runs PHP much slower any way.


Without my usual Windows bias, I do believe it is a considerable fact
like Nikita pointed out as Windows is a first class citizen in terms
of operating systems we support. While PHP on Windows may not have the
speed that the Unix counterpart have, it is still a very important
development platform. Many developers develop on Windows and deploy on
a Unix based system, being unable to test such an important feature in
a development environment is also a large question mark.


in the age of CI systems it doesn't matter much what your primary local 
development platform is, even if it is different than the targeted 
platform. One creates a PR, pushes, CI triggers, checks validity, could 
be performance tested, and that's the real environment.
And not to mention containers for local development when the code is 
actually run in a Linux container, no matter whether running on Win, 
Linux or Mac.



I'm personally interested in taking a look at it (and I'm certain
Anatol does too), but simply dismissing is a no-go for me.



Best,
Andrey

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Joe Watkins]

Morning Dmitry, and internals,

This is marvellous stuff, truly brilliant. I particularly appreciate the
non-intrusive approach of setting jit'd code as the opcode handler, this
makes life a little easier for hacky extension authors, I think.

As others have said:

  I don't like the idea of omitting to support windows, less worried about
fancy architectures.
  I'm not keen on the idea that there is no way to debug the code this
generates outside of GDB, and I'm not sure how useful gdb will be: I've
tried to debug JIT'd code in that before and it doesn't do so well, but I
could easily have been doing it wrong. I'd be very happy to be corrected
about this ?
  I'm not keen on the idea of merging this into 7.4, for various reasons
that don't need to be repeated.

Bottom line though, I love it, it's brilliant, and look forward to PHP 8.

Thank you, Dmitry.

Cheers
Joe


On Fri, 1 Feb 2019 at 09:41, Dmitry Stogov  wrote:

>
>
> On 2/1/19 3:29 AM, Larry Garfield wrote:
> > On Thursday, January 31, 2019 12:30:52 PM CST Chase Peeler wrote:
> >> On Thu, Jan 31, 2019 at 12:04 PM Zeev Suraski  wrote:
> >>> On Thu, Jan 31, 2019 at 6:47 PM Kalle Sommer Nielsen 
> >>>
> >>> wrote:
>  Without my usual Windows bias, I do believe it is a considerable fact
>  like Nikita pointed out as Windows is a first class citizen in terms
>  of operating systems we support. While PHP on Windows may not have the
>  speed that the Unix counterpart have, it is still a very important
>  development platform. Many developers develop on Windows and deploy on
>  a Unix based system, being unable to test such an important feature in
>  a development environment is also a large question mark.
> >>>
> >>> As long as we can agree that very few actually *deploy *on Windows, I
> >>> think
> >>> we're on solid grounds.
> >>> As the JIT implementation is likely to have at least *some* significant
> >>> differences compared to Linux, I'm not sure what testing it on Windows
> >>> would give you.  JIT is supposed to be entirely transparent, and the
> >>> performance characteristics - as well as the bug patterns - are likely
> to
> >>> be quite different on Linux vs. Windows, at least in many cases.
> >>> Is it really that important to have?
> >>>
> >>> 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.
> >>>
> >>> I'm personally interested in taking a look at it (and I'm certain
> >>>
>  Anatol does too), but simply dismissing is a no-go for me.
> >>>
> >>> It'd be interesting to evaluate the cost associated with supporting
> >>> Windows.  Bare in mind, we're proposing to vote on this as a production
> >>> feature for PHP 8 - which realistically means almost two years from now
> >>> *at
> >>> the earliest*.  I'm sure we'd have Windows support a lot sooner than
> that
> >>> if we decide that it's a must have.  I agree with Nikita that the key
> >>> question is in fact, do we or do we not want to introduce JIT in - with
> >>> the
> >>> main question being the maintenance cost.  Let's tackle this question
> >>> first, otherwise - why send Dmitry (and maybe others) for doing more
> work
> >>> (Windows support) if we are likely to flush it all down the toilet?
> >>>
> >> Maybe we're the only ones, but we run production PHP on Windows. I have
> no
> >> issues with the idea of not initially having support for Windows. I can
> >> probably even live with never having support for Windows - provided
> that we
> >> don't find ourselves in a situation like Nikita mentioned where features
> >> start getting developed in PHP instead of C and require JIT in order to
> >> function.
> >
> > Question from a non-compiler-engineer: Could we end up in a situation
> where
> > future language features (in 8.3 or something) are only performant on
> JIT-
> > enabled platforms?  I know there were some RFCs rejected in the past on
> the
> > grounds that they involved too many runtime checks (and thus a
> performance
> > hit); if it were possible for a JIT to optimize some of those away, it
> might
> > make the cost acceptable.  However, if a JIT only works on some systems
> that
> > might widen the gap between have- and have-not platforms.
>
> I think, JIT only approach doesn't make a lot of sense for PHP, with one
> of the most fast VM. And this is a trend. Even V8, starting from JIT
> only, switched back to VM+JIT.
>
> Thanks. Dmitry.
>
> >
> > Is that a concern, or am I making things up?  Or, is it a concern but
> we're
> > legit OK with that happening (which is also an entirely valid decision to
> > make)?
> >
> > --Larry Garfield
> >
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 2/1/19 3:29 AM, Larry Garfield wrote:
> On Thursday, January 31, 2019 12:30:52 PM CST Chase Peeler wrote:
>> On Thu, Jan 31, 2019 at 12:04 PM Zeev Suraski  wrote:
>>> On Thu, Jan 31, 2019 at 6:47 PM Kalle Sommer Nielsen 
>>>
>>> wrote:
 Without my usual Windows bias, I do believe it is a considerable fact
 like Nikita pointed out as Windows is a first class citizen in terms
 of operating systems we support. While PHP on Windows may not have the
 speed that the Unix counterpart have, it is still a very important
 development platform. Many developers develop on Windows and deploy on
 a Unix based system, being unable to test such an important feature in
 a development environment is also a large question mark.
>>>
>>> As long as we can agree that very few actually *deploy *on Windows, I
>>> think
>>> we're on solid grounds.
>>> As the JIT implementation is likely to have at least *some* significant
>>> differences compared to Linux, I'm not sure what testing it on Windows
>>> would give you.  JIT is supposed to be entirely transparent, and the
>>> performance characteristics - as well as the bug patterns - are likely to
>>> be quite different on Linux vs. Windows, at least in many cases.
>>> Is it really that important to have?
>>>
>>> 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.
>>>
>>> I'm personally interested in taking a look at it (and I'm certain
>>>
 Anatol does too), but simply dismissing is a no-go for me.
>>>
>>> It'd be interesting to evaluate the cost associated with supporting
>>> Windows.  Bare in mind, we're proposing to vote on this as a production
>>> feature for PHP 8 - which realistically means almost two years from now
>>> *at
>>> the earliest*.  I'm sure we'd have Windows support a lot sooner than that
>>> if we decide that it's a must have.  I agree with Nikita that the key
>>> question is in fact, do we or do we not want to introduce JIT in - with
>>> the
>>> main question being the maintenance cost.  Let's tackle this question
>>> first, otherwise - why send Dmitry (and maybe others) for doing more work
>>> (Windows support) if we are likely to flush it all down the toilet?
>>>
>> Maybe we're the only ones, but we run production PHP on Windows. I have no
>> issues with the idea of not initially having support for Windows. I can
>> probably even live with never having support for Windows - provided that we
>> don't find ourselves in a situation like Nikita mentioned where features
>> start getting developed in PHP instead of C and require JIT in order to
>> function.
> 
> Question from a non-compiler-engineer: Could we end up in a situation where
> future language features (in 8.3 or something) are only performant on JIT-
> enabled platforms?  I know there were some RFCs rejected in the past on the
> grounds that they involved too many runtime checks (and thus a performance
> hit); if it were possible for a JIT to optimize some of those away, it might
> make the cost acceptable.  However, if a JIT only works on some systems that
> might widen the gap between have- and have-not platforms.

I think, JIT only approach doesn't make a lot of sense for PHP, with one 
of the most fast VM. And this is a trend. Even V8, starting from JIT 
only, switched back to VM+JIT.

Thanks. Dmitry.

> 
> Is that a concern, or am I making things up?  Or, is it a concern but we're
> legit OK with that happening (which is also an entirely valid decision to
> make)?
> 
> --Larry Garfield
> 

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Larry Garfield]

On Thursday, January 31, 2019 12:30:52 PM CST Chase Peeler wrote:
> On Thu, Jan 31, 2019 at 12:04 PM Zeev Suraski  wrote:
> > On Thu, Jan 31, 2019 at 6:47 PM Kalle Sommer Nielsen 
> > 
> > wrote:
> > > Without my usual Windows bias, I do believe it is a considerable fact
> > > like Nikita pointed out as Windows is a first class citizen in terms
> > > of operating systems we support. While PHP on Windows may not have the
> > > speed that the Unix counterpart have, it is still a very important
> > > development platform. Many developers develop on Windows and deploy on
> > > a Unix based system, being unable to test such an important feature in
> > > a development environment is also a large question mark.
> > 
> > As long as we can agree that very few actually *deploy *on Windows, I
> > think
> > we're on solid grounds.
> > As the JIT implementation is likely to have at least *some* significant
> > differences compared to Linux, I'm not sure what testing it on Windows
> > would give you.  JIT is supposed to be entirely transparent, and the
> > performance characteristics - as well as the bug patterns - are likely to
> > be quite different on Linux vs. Windows, at least in many cases.
> > Is it really that important to have?
> > 
> > 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.
> > 
> > I'm personally interested in taking a look at it (and I'm certain
> > 
> > > Anatol does too), but simply dismissing is a no-go for me.
> > 
> > It'd be interesting to evaluate the cost associated with supporting
> > Windows.  Bare in mind, we're proposing to vote on this as a production
> > feature for PHP 8 - which realistically means almost two years from now
> > *at
> > the earliest*.  I'm sure we'd have Windows support a lot sooner than that
> > if we decide that it's a must have.  I agree with Nikita that the key
> > question is in fact, do we or do we not want to introduce JIT in - with
> > the
> > main question being the maintenance cost.  Let's tackle this question
> > first, otherwise - why send Dmitry (and maybe others) for doing more work
> > (Windows support) if we are likely to flush it all down the toilet?
> > 
> Maybe we're the only ones, but we run production PHP on Windows. I have no
> issues with the idea of not initially having support for Windows. I can
> probably even live with never having support for Windows - provided that we
> don't find ourselves in a situation like Nikita mentioned where features
> start getting developed in PHP instead of C and require JIT in order to
> function.

Question from a non-compiler-engineer: Could we end up in a situation where 
future language features (in 8.3 or something) are only performant on JIT-
enabled platforms?  I know there were some RFCs rejected in the past on the 
grounds that they involved too many runtime checks (and thus a performance 
hit); if it were possible for a JIT to optimize some of those away, it might 
make the cost acceptable.  However, if a JIT only works on some systems that 
might widen the gap between have- and have-not platforms.

Is that a concern, or am I making things up?  Or, is it a concern but we're 
legit OK with that happening (which is also an entirely valid decision to 
make)?

--Larry Garfield

signature.asc
Description: This is a digitally signed message part.

Re: [PHP-DEV] [RFC] JIT

[Kalle Sommer Nielsen]

Den tor. 31. jan. 2019 kl. 19.04 skrev Zeev Suraski :
> As long as we can agree that very few actually deploy on Windows, I think 
> we're on solid grounds.
> As the JIT implementation is likely to have at least some significant 
> differences compared to Linux, I'm not sure what testing it on Windows would 
> give you.  JIT is supposed to be entirely transparent, and the performance 
> characteristics - as well as the bug patterns - are likely to be quite 
> different on Linux vs. Windows, at least in many cases.
> Is it really that important to have?

I think we can easily agree on the fact that by no means Windows is
the top candidate for production. For me personally from a project
standpoint, I believe it is something important that we can have a PHP
that is pretty much as transparent and identical no matter what
platform you are on, which is something I have tried to do myself by
implementing various Linux routines for Windows natively to make PHP
as platform independent as possible.

> 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.

With above being said, then I do also agree with you here, but I would
like to have such functionality and improvements to our core system be
as global as possible, naturally I don't think its fair either to
require it so desperately upfront, but it should be a heavy
consideration with the amount of work that we all have put into making
Windows support one of the best among programming languages of similar
category.

> It'd be interesting to evaluate the cost associated with supporting Windows.  
> Bare in mind, we're proposing to vote on this as a production feature for PHP 
> 8 - which realistically means almost two years from now *at the earliest*.  
> I'm sure we'd have Windows support a lot sooner than that if we decide that 
> it's a must have.  I agree with Nikita that the key question is in fact, do 
> we or do we not want to introduce JIT in - with the main question being the 
> maintenance cost.  Let's tackle this question first, otherwise - why send 
> Dmitry (and maybe others) for doing more work (Windows support) if we are 
> likely to flush it all down the toilet?

I don't think it would be fair either to simply dismiss the idea and
many years of hard work for a detail like platform support either, and
that is not the way I hope anyone would cast their vote.

> I think that if we reach the conclusion that Windows support is a must, we 
> can condition the inclusion of JIT based on having it.  Let's first agree on 
> whether we want it in the first place.

Agreed. Naturally I would contribute in what I can to work on those
parts (Windows).


-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 1/31/19 9:12 PM, Derick Rethans wrote:
> On Thu, 31 Jan 2019, Dmitry Stogov wrote:
> 
>>
>>
>> On 1/31/19 8:08 PM, Derick Rethans wrote:
>>> On Thu, 31 Jan 2019, Dmitry Stogov wrote:
>>>
 I'm glad to finally propose including JIT into PHP.

 https://wiki.php.net/rfc/jit
>>>
>>> I don't see anywhere in this RFC how it would affect thigns that do
>>> sneaky things with internals, such as Xdebug. How is that going to be
>>> affected?
>>>
>>
>> I suppose Xdebug should work on non-JIT-ed versions of the functions.
>> Even JVM deoptimizes to bytecode when debugging.
> 
> So, in that case, I think I would need to be able to instruct the PHP
> JIT engine to be turned off. Perhaps through an API?
> 
> Similarly, I think it might be useful for OPcache as well,

Use zend_alter_ini_entry() to set "opcache.enable" to "0".
Better to do it at RINIT.

Thanks. Dmitry.

> as I am
> getting more people confused why some breakpoints don't work, or
> variables don't exist:
> https://bugs.xdebug.org/view.php?id=1609
> 
> cheers,
> Derick
> 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Chase Peeler]

On Thu, Jan 31, 2019 at 12:04 PM Zeev Suraski  wrote:

> On Thu, Jan 31, 2019 at 6:47 PM Kalle Sommer Nielsen 
> wrote:
>
> > Without my usual Windows bias, I do believe it is a considerable fact
> > like Nikita pointed out as Windows is a first class citizen in terms
> > of operating systems we support. While PHP on Windows may not have the
> > speed that the Unix counterpart have, it is still a very important
> > development platform. Many developers develop on Windows and deploy on
> > a Unix based system, being unable to test such an important feature in
> > a development environment is also a large question mark.
> >
>
> As long as we can agree that very few actually *deploy *on Windows, I think
> we're on solid grounds.
> As the JIT implementation is likely to have at least *some* significant
> differences compared to Linux, I'm not sure what testing it on Windows
> would give you.  JIT is supposed to be entirely transparent, and the
> performance characteristics - as well as the bug patterns - are likely to
> be quite different on Linux vs. Windows, at least in many cases.
> Is it really that important to have?
>
> 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.
>
> I'm personally interested in taking a look at it (and I'm certain
> > Anatol does too), but simply dismissing is a no-go for me.
>
>
> It'd be interesting to evaluate the cost associated with supporting
> Windows.  Bare in mind, we're proposing to vote on this as a production
> feature for PHP 8 - which realistically means almost two years from now *at
> the earliest*.  I'm sure we'd have Windows support a lot sooner than that
> if we decide that it's a must have.  I agree with Nikita that the key
> question is in fact, do we or do we not want to introduce JIT in - with the
> main question being the maintenance cost.  Let's tackle this question
> first, otherwise - why send Dmitry (and maybe others) for doing more work
> (Windows support) if we are likely to flush it all down the toilet?
>
> Maybe we're the only ones, but we run production PHP on Windows. I have no
issues with the idea of not initially having support for Windows. I can
probably even live with never having support for Windows - provided that we
don't find ourselves in a situation like Nikita mentioned where features
start getting developed in PHP instead of C and require JIT in order to
function.


> I think that if we reach the conclusion that Windows support is a must, we
> can condition the inclusion of JIT based on having it.  Let's first agree
> on whether we want it in the first place.
>
> Zeev
>
-- 
-- Chase
chasepee...@gmail.com

Re: [PHP-DEV] [RFC] JIT

[Derick Rethans]

On Thu, 31 Jan 2019, Dmitry Stogov wrote:

> 
> 
> On 1/31/19 8:08 PM, Derick Rethans wrote:
> > On Thu, 31 Jan 2019, Dmitry Stogov wrote:
> > 
> >> I'm glad to finally propose including JIT into PHP.
> >>
> >> https://wiki.php.net/rfc/jit
> > 
> > I don't see anywhere in this RFC how it would affect thigns that do
> > sneaky things with internals, such as Xdebug. How is that going to be
> > affected?
> > 
> 
> I suppose Xdebug should work on non-JIT-ed versions of the functions.
> Even JVM deoptimizes to bytecode when debugging.

So, in that case, I think I would need to be able to instruct the PHP 
JIT engine to be turned off. Perhaps through an API? 

Similarly, I think it might be useful for OPcache as well, as I am 
getting more people confused why some breakpoints don't work, or 
variables don't exist:
https://bugs.xdebug.org/view.php?id=1609

cheers,
Derick

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Dmitry Stogov]

On 1/31/19 8:08 PM, Derick Rethans wrote:
> On Thu, 31 Jan 2019, Dmitry Stogov wrote:
> 
>> I'm glad to finally propose including JIT into PHP.
>>
>> https://wiki.php.net/rfc/jit
> 
> I don't see anywhere in this RFC how it would affect thigns that do
> sneaky things with internals, such as Xdebug. How is that going to be
> affected?
> 

I suppose Xdebug should work on non-JIT-ed versions of the functions.
Even JVM deoptimizes to bytecode when debugging.

Thanks. Dmitry.

>> 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.
> 
> 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.
> 
> cheers,
> Derick
> 

Re: [PHP-DEV] [RFC] JIT

[Derick Rethans]

On Thu, 31 Jan 2019, Dmitry Stogov wrote:

> I'm glad to finally propose including JIT into PHP.
> 
> https://wiki.php.net/rfc/jit

I don't see anywhere in this RFC how it would affect thigns that do 
sneaky things with internals, such as Xdebug. How is that going to be 
affected?

> 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.

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.

cheers,
Derick

-- 
https://derickrethans.nl | https://xdebug.org | https://dram.io
Like Xdebug? Consider a donation: https://xdebug.org/donate.php,
or become my Patron: https://www.patreon.com/derickr
twitter: @derickr and @xdebug

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] JIT

[Zeev Suraski]

On Thu, Jan 31, 2019 at 6:47 PM Kalle Sommer Nielsen  wrote:

> Without my usual Windows bias, I do believe it is a considerable fact
> like Nikita pointed out as Windows is a first class citizen in terms
> of operating systems we support. While PHP on Windows may not have the
> speed that the Unix counterpart have, it is still a very important
> development platform. Many developers develop on Windows and deploy on
> a Unix based system, being unable to test such an important feature in
> a development environment is also a large question mark.
>

As long as we can agree that very few actually *deploy *on Windows, I think
we're on solid grounds.
As the JIT implementation is likely to have at least *some* significant
differences compared to Linux, I'm not sure what testing it on Windows
would give you.  JIT is supposed to be entirely transparent, and the
performance characteristics - as well as the bug patterns - are likely to
be quite different on Linux vs. Windows, at least in many cases.
Is it really that important to have?

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.

I'm personally interested in taking a look at it (and I'm certain
> Anatol does too), but simply dismissing is a no-go for me.


It'd be interesting to evaluate the cost associated with supporting
Windows.  Bare in mind, we're proposing to vote on this as a production
feature for PHP 8 - which realistically means almost two years from now *at
the earliest*.  I'm sure we'd have Windows support a lot sooner than that
if we decide that it's a must have.  I agree with Nikita that the key
question is in fact, do we or do we not want to introduce JIT in - with the
main question being the maintenance cost.  Let's tackle this question
first, otherwise - why send Dmitry (and maybe others) for doing more work
(Windows support) if we are likely to flush it all down the toilet?

I think that if we reach the conclusion that Windows support is a must, we
can condition the inclusion of JIT based on having it.  Let's first agree
on whether we want it in the first place.

Zeev

Re: [PHP-DEV] [RFC] JIT

[Kalle Sommer Nielsen]

Den tor. 31. jan. 2019 kl. 18.39 skrev Dmitry Stogov :
>
>
>
> On 1/31/19 7:01 PM, Nikita Popov wrote:
> > On Thu, Jan 31, 2019 at 10:44 AM 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.
> >
> >
> > This has been a long time on the horizon, nice to see this finally
> > moving forward :)
> >
> > Here are some initial thoughts: I think that it's best to approach this
> > issue from a cost/benefit angle. The benefits of the JIT compiler are
> > roughly (and as already outlined in the RFC):
> >
> >   * Significantly better performance for numerical code.
> >   * Slightly better performance for "typical" PHP web application code.
> >   * The potential to move more code from C to PHP, because PHP will now
> > be sufficiently fast.
> >
> > However, there are also a number of costs, on which I'll expand in more
> > detail:
> >
> > a) Maintenance: This is really my main concern. Right now there are
> > about 3-4 people who I would trust to carry out a non-trivial language
> > change, which will require touching the compiler, the virtual machine,
> > the optimizer and the persistence layer. Each of those components is
> > quite complex, in different ways. Some people who are comfortable with
> > doing VM changes will struggle with implementing optimizer changes.
> >
> > Adding a JIT compiler exacerbates this issue further. Because this JIT
> > is dynasm based, the core JIT code is essentially written in raw x86
> > assembly. This will further limit the pool of people who will be able to
> > make non-trivial engine changes. Personally, I don't have any particular
> > familiarity with writing x86 assembly, so it will likely take a while to
> > get up to speed with this code.
> >
> > b) Bugs and stability: I think that everyone is aware that the initial
> > PHP 7.3 release suffered from substantial stability issues, more than
> > new minor version releases tend to do. I think there are multiple
> > reasons for that (and we might want to start a conversation about our QA
> > processes in a separate thread), but one main contributing factor were
> > opcache optimizer bugs. Compiler optimizations are tricky and hard to
> > verify, and we often only learn about issues once the optimizer makes
> > contact with production codebases, which feature a much richer
> > collection of code patterns than our test suite. One can wonder whether
> > the relatively minor speedups we get from our optimization framework are
> > really worth having these stability issues...
> >
> > Adding a JIT compiler adds a new dimension of stability issues. Next to
> > "simple" executor bugs, and optimizer bugs, we now get additional bugs
> > in the JIT. These are probably going to be hard to debug, as we'll have
> > to drop down from our usual C-level tooling, down to inspecting assembly.
> >
> > c) Platform support: Having a JIT segregates platforms into two tiers:
> > Those that have JIT support and those that don't. While that is not a
> > problem per se, it does introduce some dangers. For example, if we
> > decide to more parts of our C code into PHP because PHP is fast enough
> > with a JIT, that will of course only be true for platforms that actually
> > have JIT support. I'm not terribly concerned about loosing out some
> > performance on MIPS, but we do need to make sure that all our main
> > platforms are supported (Windows is a must there, imho).
>
> I don't see any problems with including JIT without Windows support.
> Windows runs PHP much slower any way.

Without my usual Windows bias, I do believe it is a considerable fact
like Nikita pointed out as Windows is a first class citizen in terms
of operating systems we support. While PHP on Windows may not have the
speed that the Unix counterpart have, it is still a very important
development platform. Many developers develop on Windows and deploy on
a Unix based system, being unable to test such an important feature in
a development environment is also a large question mark.

I'm personally interested in taking a look at it (and I'm certain
Anatol does too), but simply dismissing is a no-go for me.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php