Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129373
Precedence: list
MIME-Version: 1.0
References: <CANSNCr2JXXmLnNqSxVXQM7i3j_WBi3jmznM4-_rd34LDkmvLZg@mail.gmail.com>
In-Reply-To: <CANSNCr2JXXmLnNqSxVXQM7i3j_WBi3jmznM4-_rd34LDkmvLZg@mail.gmail.com>
Date: Fri, 21 Nov 2025 16:22:23 +0100
Message-ID: <CAP1Jc10GXcH0D=jO0_+sKV7A8V2mJHwL28TQQDCE0F9L5+w-NQ@mail.gmail.com>
Subject: Re: [PHP-DEV] What's the status of the JIT?
To: Brent Roose <brent.roose@jetbrains.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: arnaud.lb@gmail.com (Arnaud Le Blanc)

Hi Brent,

> I'm wondering about the state of PHP's JIT these days. I understand that =
Dmitry is still working on his standalone JIT IR framework [1] that's being=
 used by PHP, and that Arnaud is maintaining it from the Foundation/PHP sid=
e? In my own benchmarks, done in PHP 8.0 and PHP 8.4; I cannot seem to get =
any meaningful performance gain from the JIT in web applications or in tool=
s like PHPStan. [2][3][4]

To be fair, the first web benchmark in [2] shows a 9% improvement with
the tracing JIT enabled. But the benchmark seems very unstable: The
second run gives a widely different number for the baseline, but I
would expect that number to be very close to the first run.

However I confirm that the JIT provides no improvements on PHPStan at
all currently.

> The question I'm left with is whether the JIT is worth the hassle? Assumi=
ng the JIT's existence impacts the complexity of internal development, I wo=
nder if it wouldn't be better to deprecate it in a future PHP version? To b=
e clear, I'm assuming the JIT impacts internal development =E2=80=94 maybe =
that's wrong? Perhaps I'm missing a real-life use case that benefits signif=
icantly from the JIT as well?

If performance is an important feature, then we need a JIT in the long
term. Other VMs have shown that JITs can have spectacular performances
in practice. The reason our JIT is not bringing much benefits yet is
that it's still in a very early stage, especially on the frontend
side. The alternative would be to rely entirely on interpreter
improvements, but it's already state of the art, and we are way past
the point of diminishing returns: it's unlikely that we can make as
much improvements with the interpreter alone than with a JIT. Also
it's likely that work on the JIT has a better cost/benefit ratio at
this point.

Regarding the impact of the JIT on internal development, I believe
that it's relatively low:

 * The JIT is known to be a bit unstable yet, and there are occasional
JIT bug reports, but these affect only the JIT and deployments with
JIT enabled
 * Changes to the VM are likely to require changes to the JIT as well,
but this is not the majority of the work
 * Language changes, such as those proposed in RFCs, often require JIT
changes as well. But RFCs are not required to implement JIT changes
before voting, so this only adds overhead on accepted RFCs. This
represents a very small fraction of the work required on an RFC.
 * Other changes don't usually need to care about the JIT

Best Regards,
Arnaud