Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121085
MIME-Version: 1.0
References: <CAPVMwwtcLwq8AGEBYCXB1-HngS1R0D-xM5kTGjYqEdjmB7M=ag@mail.gmail.com>
 <CAPVMwwu9+RK13ByqFpexrQ4Sc+xARvyQb=WVxruhVtGKzxjo+A@mail.gmail.com> <8b9a1aae-5aec-91a8-5377-27f6f53581cd@php.net>
In-Reply-To: <8b9a1aae-5aec-91a8-5377-27f6f53581cd@php.net>
Date: Mon, 18 Sep 2023 09:08:59 +0300
Message-ID: <CAPVMwwsDL-Gbsq-sQtL2dGWwJM_AweMRBs==ORST7YoNGLce-Q@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000018ed0606059bfbf2"
Subject: Re: [PHP-DEV] A new JIT engine for PHP-8.4/9
From: dmitrystogov@gmail.com (Dmitry Stogov)

--00000000000018ed0606059bfbf2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Derick,

On Fri, Sep 15, 2023 at 5:35=E2=80=AFPM Derick Rethans <derick@php.net> wro=
te:

> I think this is great work. It looks like the new JIT-IR approach is
> more suitable. I have however concerns with a few things here.
>
> This is a lot of new code, that very few other people understand in
> great detail.
>
> I think it is unwise if we have another large part of the engine that
> does not have enough people understanding enough of it, to be able to
> debug issues, and contribute to its continued development.
>

The IR Framework project is going to be developed separately from PHP.
Ideally this project will involve compiler experts from different areas.
I'm doing my best in this direction.


> As such, I don't think this should just be merged, without a
> comprehensive document explaining what it is, how it works, what pitfalls
> there are, etc.


In the mid of October I'll speak about IR at a Java related conference.
Then I'll make available a presentation that explains many internals of the
IR Framework.


> The natural process that we have for PHP would be to
> create an RFC.
>

I'm not sure. The PR just adds a different way to generate native code.
Instead of existing ``zend_jit_x86.dasc`` and ``zend_jit_arm64.dasc`` where
we had to write assembler code manually, now we have a single
``zend_jit_ir.c`` where we have to construct the IR graph. Disassembler,
Linux perf interface and other low-level JIT details were also moved to JIT
framework. So, actually the PHP part becomes even simple.


> An RFC should also include a user-facing API on how to configure, and
> enable, the JIT and its optimisations, as our current implementation
> it is not the most convenient for users.
>

Nothing has changed. The new JIT is a completely self-containing
replacement.
Only few new ``opcache.jit_debug`` options that may show the IR.

I understand that working on an RFC for such a complex issue is going to
> take time, but that also gives to opportunity to pair with somebody,
> who, while writing it, will also learn how it works. That would also
> ready improve the debugging/contributing issues.
>

IR documentation could be a good addition and it's going to be created soon
or later.
I don't think it's a blocker, because the IR APIs are quite simple and
intuitive.
Just two public C headers  https://github.com/dstogov/ir/blob/master/ir.h
and https://github.com/dstogov/ir/blob/master/ir_builder.h

Separately, I am not sure why your PR couldn't just replace the JIT that
> we already have? It would IMO not make sense to have two different ones
> at the same time.
>

This is a question.
I decided to keep the old JIT to have an ability to quickly switch back in
case of big problems.
On the other hand we will be able to revert to PHP-8.3.


> Furthermore, I am curious as if you have already done some benchmarks. I
> am curious to learn how well it makes non-benchmark code run faster.
>

This doesn't improve the speed of the real apps yet.
bench.php is 5-10% faster.

Thanks. Dmitry.

--00000000000018ed0606059bfbf2--