Everything

php

[RFC] [Discussion] A new JIT implementation based on IR Framework

php.internals

Dmitry Stogov

2 years ago

Hi Internals,

After all the Poll Request discussions (see
https://github.com/php/php-src/pull/12079), code-reviews and internal
discussions with core developers we decided to move this through the RFC
process.

Thanks to all participants.

The RFC is open for discussion: https://wiki.php.net/rfc/jit-ir

Thanks. Dmitry.

Tim Düsterhus

2 years ago

Hi

On 9/21/23 10:26, Dmitry Stogov wrote:

> After all the Poll Request discussions (see
> https://github.com/php/php-src/pull/12079), code-reviews and internal
> discussions with core developers we decided to move this through the RFC
> process.
>
> Thanks to all participants.
>
> The RFC is open for discussion: https://wiki.php.net/rfc/jit-ir

Thank you. I find it important to follow the formal process, even if
many folks are not able to make a meaningful decision due to the lack of
knowledge about the topic. This includes me.

That said, I'd like to add my two cents to the "Open Issues" section:

My understanding is that even if the new JIT might not (yet) be better
than the old one, it is not worse and it is more maintainable. The
reactions from more knowledgeable folks were pretty positive overall.

So if the new JIT passes the existing test suite without issues, I don't
see a reason why the old JIT should not be replaced right away. By
immediately removing the old JIT (ideally in a separate commit) the
codebase is cleaned up and users that want to test PHP 8.4 (or whatever
that version may be in the end) will be forced to also test the new JIT
which is probably a good thing.

Best regards
Tim Düsterhus

Sebastian Bergmann

2 years ago

Am 21.09.2023 um 11:13 schrieb Tim Düsterhus:

> Thank you. I find it important to follow the formal process, even if many
> folks are not able to make a meaningful decision due to the lack of
> knowledge about the topic. This includes me.

I'm in the same boat.

> My understanding is that even if the new JIT might not (yet) be better
> than the old one, it is not worse and it is more maintainable. The
> reactions from more knowledgeable folks were pretty positive overall.

That is my understanding as well.

> So if the new JIT passes the existing test suite without issues, I don't
> see a reason why the old JIT should not be replaced right away. By
> immediately removing the old JIT (ideally in a separate commit) the
> codebase is cleaned up and users that want to test PHP 8.4 (or whatever
> that version may be in the end) will be forced to also test the new JIT
> which is probably a good thing.

I agree.

As a sidenote: most of the teams that I work with use PHP 8 in production.
However, none of them use the current JIT. It either caused problems
(especially during early PHP 8.0 versions), or does not bring any
significant performance improvement. Against that backdrop, I would be
interested in whether you, Dmitry or Zend, can share some insight from
real-world usage of the JIT.

Dmitry Stogov

2 years ago

Hi Sebastian,

On Thu, Sep 21, 2023 at 12:22 PM Sebastian Bergmann <sebastian@php.net>
wrote:

> Am 21.09.2023 um 11:13 schrieb Tim Düsterhus:
> > Thank you. I find it important to follow the formal process, even if
> many
> > folks are not able to make a meaningful decision due to the lack of
> > knowledge about the topic. This includes me.
>
> I'm in the same boat.
>
> > My understanding is that even if the new JIT might not (yet) be better
> > than the old one, it is not worse and it is more maintainable. The
> > reactions from more knowledgeable folks were pretty positive overall.
>
> That is my understanding as well.
>
> > So if the new JIT passes the existing test suite without issues, I don't
> > see a reason why the old JIT should not be replaced right away. By
> > immediately removing the old JIT (ideally in a separate commit) the
> > codebase is cleaned up and users that want to test PHP 8.4 (or whatever
> > that version may be in the end) will be forced to also test the new JIT
> > which is probably a good thing.
>
> I agree.
>
> As a sidenote: most of the teams that I work with use PHP 8 in production.
> However, none of them use the current JIT. It either caused problems
> (especially during early PHP 8.0 versions), or does not bring any
> significant performance improvement. Against that backdrop, I would be
> interested in whether you, Dmitry or Zend, can share some insight from
> real-world usage of the JIT.
>

I still don't recommend using JIT for production without serious testing
and benchmarking for each concrete case.
If you see less than 5% speedup - you probably don't need JIT; if an AMPHP
bsed server becomes 1.5 times faster it's a different story.

Thanks. Dmitry.

Dmitry Stogov

2 years ago

Hi Tim.

On Thu, Sep 21, 2023 at 12:13 PM Tim Düsterhus <tim@bastelstu.be> wrote:

> Hi
>
> On 9/21/23 10:26, Dmitry Stogov wrote:
> > After all the Poll Request discussions (see
> > https://github.com/php/php-src/pull/12079), code-reviews and internal
> > discussions with core developers we decided to move this through the RFC
> > process.
> >
> > Thanks to all participants.
> >
> > The RFC is open for discussion: https://wiki.php.net/rfc/jit-ir
>
> Thank you. I find it important to follow the formal process, even if
> many folks are not able to make a meaningful decision due to the lack of
> knowledge about the topic. This includes me.
>
> That said, I'd like to add my two cents to the "Open Issues" section:
>
> My understanding is that even if the new JIT might not (yet) be better
> than the old one, it is not worse and it is more maintainable. The
> reactions from more knowledgeable folks were pretty positive overall.
>
> So if the new JIT passes the existing test suite without issues,

Passing test suites doesn't mean we couldn't have other problems.

> I don't
> see a reason why the old JIT should not be replaced right away. By
> immediately removing the old JIT (ideally in a separate commit)
>

I'm going to agree to remove the old JIT and I like the idea of removing it
in a separate commit.

Thanks. Dmitry.

Deleu

2 years ago

On Thu, Sep 21, 2023 at 6:13 AM Tim Düsterhus <tim@bastelstu.be> wrote:

> Hi
>
> On 9/21/23 10:26, Dmitry Stogov wrote:
> My understanding is that even if the new JIT might not (yet) be better
> than the old one, it is not worse and it is more maintainable. The
> reactions from more knowledgeable folks were pretty positive overall.
>
> So if the new JIT passes the existing test suite without issues, I don't
> see a reason why the old JIT should not be replaced right away. By
> immediately removing the old JIT (ideally in a separate commit) the
> codebase is cleaned up and users that want to test PHP 8.4 (or whatever
> that version may be in the end) will be forced to also test the new JIT
> which is probably a good thing.
>

If I understand correctly, the only way to fallback to the JIT 1.0
implementation is by compiling PHP with a new introduced flag, so the JIT
2.0 needs to be opt-out. The RFC doesn't mention the configurations for new
JIT (init settings) which makes me assume that they're exactly the same? If
these assumptions are right, I think the matter of keeping or removing JIT
1.0 implementation is mostly a matter of what makes Dmitry more
comfortable. Removing it straight-away might result in adding more pressure
in getting bug fixes on the new one, while keeping it might make it
possible for whoever is relying heavily on JIT to still compile new PHP
releases with JIT 1.0 to give more time to iron out the final details on
JIT 2.0.

Of course this is a very basic analysis on my part which mixes my
experience in replacing PHP running-systems with new rewrites and it's much
more comfortable to me to have a fallback mechanism in place which may or
may not be entirely relevant here.

--
Marco Deleu

Dmitry Stogov

2 years ago

Hi Deleu,

On Thu, Sep 21, 2023 at 12:31 PM Deleu <deleugyn@gmail.com> wrote:

>
>
> On Thu, Sep 21, 2023 at 6:13 AM Tim Düsterhus <tim@bastelstu.be> wrote:
>
>> Hi
>>
>> On 9/21/23 10:26, Dmitry Stogov wrote:
>> My understanding is that even if the new JIT might not (yet) be better
>> than the old one, it is not worse and it is more maintainable. The
>> reactions from more knowledgeable folks were pretty positive overall.
>>
>> So if the new JIT passes the existing test suite without issues, I don't
>> see a reason why the old JIT should not be replaced right away. By
>> immediately removing the old JIT (ideally in a separate commit) the
>> codebase is cleaned up and users that want to test PHP 8.4 (or whatever
>> that version may be in the end) will be forced to also test the new JIT
>> which is probably a good thing.
>>
>
> If I understand correctly, the only way to fallback to the JIT 1.0
> implementation is by compiling PHP with a new introduced flag, so the JIT
> 2.0 needs to be opt-out. The RFC doesn't mention the configurations for new
> JIT (init settings) which makes me assume that they're exactly the same? If
> these assumptions are right, I think the matter of keeping or removing JIT
> 1.0 implementation is mostly a matter of what makes Dmitry more
> comfortable. Removing it straight-away might result in adding more pressure
> in getting bug fixes on the new one, while keeping it might make it
> possible for whoever is relying heavily on JIT to still compile new PHP
> releases with JIT 1.0 to give more time to iron out the final details on
> JIT 2.0.
>

In the current state the Pull Request starts using the new JIT
implementation by default, but keeps the old implementation.
It's a question, if we need to keep it for a while or remove it immediately.
Now I think it's going to be removed in PR/RFC before starting the voting.

> Of course this is a very basic analysis on my part which mixes my
> experience in replacing PHP running-systems with new rewrites and it's much
> more comfortable to me to have a fallback mechanism in place which may or
> may not be entirely relevant here.
>

Keeping the disabled old JIT, we won't test it anyway and this won't
guarantee anything.
In case the new JIT will cause really serious problems we may consider
reverting it.

Thanks. Dmitry
.

Dmitry Stogov

2 years ago

Hi Internals,

I've published a presentation about the IR Framework design and
implementation details.
See
https://www.researchgate.net/publication/374470404_IR_JIT_Framework_a_base_for_the_next_generation_JIT_for_PHP
It explains many complex things in simple pictures.

Thanks. Dmitry.

On Thu, Sep 21, 2023 at 11:26 AM Dmitry Stogov <dmitrystogov@gmail.com>
wrote:

Paul Dragoonis

2 years ago

On Thu, 5 Oct 2023, 17:44 Dmitry Stogov, <dmitrystogov@gmail.com> wrote:

> Hi Internals,
>
> I've published a presentation about the IR Framework design and
> implementation details.
> See
>
> https://www.researchgate.net/publication/374470404_IR_JIT_Framework_a_base_for_the_next_generation_JIT_for_PHP
> It explains many complex things in simple pictures.
>

Hi Dmitry,

Thanks for helping explain things in graphical format. I will for sure
study the material closely.

As for the point around keeping the old JIT around as a safety measure and
fallback.

I think this is an excellent idea and may give good peace of mind and
confidence for new adopters, that they can easily "switch back" to JIT 1.0
if any edge cases occur we didn't find yet in JIT 2.0, without waiting for
future PHP releases (patches) to come out.

It can be months before people get new patched PHP versions (think about
centos or Debian distributions, or Docker images of PHP)

Just like we've done with many things over the years, we first deprecated
something and keep it in the language and in future release we remove it
completely.

Many thanks,
Paul