Hi internals,
I'm glad to present a new JIT engine that is going to be used in the next
major PHP version. Now it's a real optimizing compiler with Intermediate
Representation similar to Java HotSpot server compiler.
It makes a base for future improvements and eliminates many low-level
details of the existing PHP JIT. Instead of supporting assembler code for
different CPUs, now PHP generates a single IR and passes it to a
PHP-independent JIT engine.
The old JIT implementation is going to be kept for a while.
Everybody are welcome to take a look over tne code
https://github.com/php/php-src/pull/12079
Thanks. Dmitry.
Den 2023-09-11 kl. 11:28, skrev Dmitry Stogov:
Hi internals,
I'm glad to present a new JIT engine that is going to be used in the next
major PHP version. Now it's a real optimizing compiler with Intermediate
Representation similar to Java HotSpot server compiler.It makes a base for future improvements and eliminates many low-level
details of the existing PHP JIT. Instead of supporting assembler code for
different CPUs, now PHP generates a single IR and passes it to a
PHP-independent JIT engine.The old JIT implementation is going to be kept for a while.
Everybody are welcome to take a look over tne code
https://github.com/php/php-src/pull/12079Thanks. Dmitry.
Great work Dmitry! Looking forward to test it in next major PHP version.
Are there any performance figures available for this new JIT engine?
Regards //Björn L
Hi,
After the code-review feedback, one of the most questionable decisions was
changed.
Instead of including IR Framework as a git submodule, now its part is
embedded into php-src.
This will complicate the IR/JIT development a bit, but will simplify things
for everyone else.
I'm going to merge https://github.com/php/php-src/pull/12079 into master
next week.
If someone likes to take a look before, please do it now.
After the merge, I don't plan to do active PHP-JIT development for 1-2
months (I'll wait for problems, bugs, etc and work on general IR
improvements).
Then, in case of no major problems, I'm going to remove the old JIT
implementation and make a PHP-JIT code-cleanup pass.
Thanks. Dmitry.
On Mon, Sep 11, 2023 at 12:28 PM Dmitry Stogov dmitrystogov@gmail.com
wrote:
Hi internals,
I'm glad to present a new JIT engine that is going to be used in the next
major PHP version. Now it's a real optimizing compiler with Intermediate
Representation similar to Java HotSpot server compiler.It makes a base for future improvements and eliminates many low-level
details of the existing PHP JIT. Instead of supporting assembler code for
different CPUs, now PHP generates a single IR and passes it to a
PHP-independent JIT engine.The old JIT implementation is going to be kept for a while.
Everybody are welcome to take a look over tne code
https://github.com/php/php-src/pull/12079Thanks. Dmitry.
Hi,
After the code-review feedback, one of the most questionable decisions was
changed.
Instead of including IR Framework as a git submodule, now its part is
embedded into php-src.
This will complicate the IR/JIT development a bit, but will simplify things
for everyone else.I'm going to merge https://github.com/php/php-src/pull/12079 into master
next week.
If someone likes to take a look before, please do it now.After the merge, I don't plan to do active PHP-JIT development for 1-2
months (I'll wait for problems, bugs, etc and work on general IR
improvements).
Then, in case of no major problems, I'm going to remove the old JIT
implementation and make a PHP-JIT code-cleanup pass.Thanks. Dmitry.
On Mon, Sep 11, 2023 at 12:28 PM Dmitry Stogov dmitrystogov@gmail.com
wrote:Hi internals,
I'm glad to present a new JIT engine that is going to be used in the next
major PHP version. Now it's a real optimizing compiler with Intermediate
Representation similar to Java HotSpot server compiler.It makes a base for future improvements and eliminates many low-level
details of the existing PHP JIT. Instead of supporting assembler code for
different CPUs, now PHP generates a single IR and passes it to a
PHP-independent JIT engine.The old JIT implementation is going to be kept for a while.
Everybody are welcome to take a look over tne code
https://github.com/php/php-src/pull/12079Thanks. Dmitry.
If merged to master, will that automatically mean that the next
version of PHP will be PHP 9.0 ?
If so, would that warrant a separate discussion ? (whether there should
still be a 8.4/8.5/8.6 or not)
Smile,
Juliette
On Fri, Sep 15, 2023 at 4:03 PM Juliette Reinders Folmer <
php-internals_nospam@adviesenzo.nl> wrote:
If merged to
master, will that automatically mean that the next
version of PHP will be PHP 9.0 ?If so, would that warrant a separate discussion ? (whether there should
still be a 8.4/8.5/8.6 or not)
I can't answer this question.
I just came to the state when the new PHP-JIT is good enough to be merged
and we have plenty of time to resolve possible problems until the release.
Thanks. Dmitry.
Hi Dmitry,
After the code-review feedback, one of the most questionable decisions
was changed.Instead of including IR Framework as a git submodule, now its part is
embedded into php-src.This will complicate the IR/JIT development a bit, but will simplify
things for everyone else.I'm going to merge https://github.com/php/php-src/pull/12079 into
master next week.
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.
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. The natural process that we have for PHP would be to
create an RFC.
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.
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.
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.
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.
cheers,
Derick
--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
Host of PHP Internals News: https://phpinternals.news
mastodon: @derickr@phpc.social @xdebug@phpc.social
twitter: @derickr and @xdebug
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.
Agreed.
Additionally, despite the use of a Git submodule complicating things for
"everyone else," it provides a clear dependency and development
boundary, avoiding situations where the php-src version of IR drifts
from the upstream version. I think we can adjust tooling and messaging
to help folks know how to use the submodule. :-)
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. The natural process that we have for PHP would be to
create an RFC.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.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.
+1, this needs an RFC, if only to help articulate and explain how it
works, as Derick says. I'd love to volunteer to help with the RFC, but
I'm already stretched thin, as it is.
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 was my thought, as well.
A few things I noted while looking through the code in the IR repository...
It looks like the goal of the project is for IR to provide JIT
compilation for other projects. Do you already have some idea where
(other than php-src) it will be used? Is it already being used elsewhere?
IR is currently on your personal GitHub account, but the copyright
listed on the license is for "Zend by Perforce," while other source
files (e.g., ir_cpuinfo.c) list "IR project" as the copyright holder. I
assume this is because you (Dmitry) have been working on this on Zend's
time, while other contributors have been working on it independently.
Who is the ultimate owner/controller of the project? If it's a Zend by
Perforce project, what's their goal for it? (I'm not asking because I
think there are hidden agendas; I'm just curious what the plans are for
long-ish term support of IR.)
Noted that the license on IR is MIT. Love it!
Cheers,
Ben
Hi
Additionally, despite the use of a Git submodule complicating things for
"everyone else," it provides a clear dependency and development
boundary, avoiding situations where the php-src version of IR drifts
from the upstream version. I think we can adjust tooling and messaging
to help folks know how to use the submodule. :-)
Do not want: If the submodule repository goes away for whatever reason,
the dependency will no longer be available. IR is currently sitting in
Dmitry's personal GitHub account and it would not be the first time that
a GitHub account is suspended for good or less good reasons [1].
Bundle IR in some dedicated directory with php-src. Then updating it is
as easy as "throw away the directory and copy over the new files". We
could even automate that using GitHub actions to sync in the changes
every night or so.
Dmitry also said that he gave 'git subtree' a try. I don't know that
command myself, but it looks exactly like what is required here. I would
be interested in hearing why it didn't work well.
Best regards
Tim Düsterhus
[1] Such as sanctions, see:
https://techcrunch.com/2019/07/29/github-ban-sanctioned-countries/
I think the submodule approach is fine, but maybe it should be moved from
Dmitry's gh to php-src gh, or maybe it's own dedicated group, to reduce the
bus factor (how much work needs to be done if Dmitry is hit by a bus~)
Hi
Additionally, despite the use of a Git submodule complicating things for
"everyone else," it provides a clear dependency and development
boundary, avoiding situations where the php-src version of IR drifts
from the upstream version. I think we can adjust tooling and messaging
to help folks know how to use the submodule. :-)Do not want: If the submodule repository goes away for whatever reason,
the dependency will no longer be available. IR is currently sitting in
Dmitry's personal GitHub account and it would not be the first time that
a GitHub account is suspended for good or less good reasons [1].Bundle IR in some dedicated directory with php-src. Then updating it is
as easy as "throw away the directory and copy over the new files". We
could even automate that using GitHub actions to sync in the changes
every night or so.Dmitry also said that he gave 'git subtree' a try. I don't know that
command myself, but it looks exactly like what is required here. I would
be interested in hearing why it didn't work well.Best regards
Tim Düsterhus[1] Such as sanctions, see:
https://techcrunch.com/2019/07/29/github-ban-sanctioned-countries/--
To unsubscribe, visit: https://www.php.net/unsub.php
On Sat, Sep 16, 2023 at 12:46 PM Hans Henrik Bergan divinity76@gmail.com
wrote:
I think the submodule approach is fine, but maybe it should be moved from
Dmitry's gh to php-src gh, or maybe it's own dedicated group, to reduce the
bus factor (how much work needs to be done if Dmitry is hit by a bus~)
git submodulesare useful for development, but I'm not sure about the
problems that they may make for maintainability.
Imagine, we have few different php versions that use different versions of
IR, then we have to backport patches and maintain different versions of the
IR, etc
Thanks. Dmitry.
Hi
Additionally, despite the use of a Git submodule complicating things for
"everyone else," it provides a clear dependency and development
boundary, avoiding situations where the php-src version of IR drifts
from the upstream version. I think we can adjust tooling and messaging
to help folks know how to use the submodule. :-)Do not want: If the submodule repository goes away for whatever reason,
the dependency will no longer be available. IR is currently sitting in
Dmitry's personal GitHub account and it would not be the first time that
a GitHub account is suspended for good or less good reasons [1].
Yes. I agree. Everything is possible nowadays.
Bundle IR in some dedicated directory with php-src. Then updating it is
as easy as "throw away the directory and copy over the new files". We
could even automate that using GitHub actions to sync in the changes
every night or so.
I already embedded the necessary part of the IR project unde
/ext/opcache/jit/ir.
I'm going to manage mirroring manually (similar to libdate in ext/date).
Dmitry also said that he gave 'git subtree' a try. I don't know that
command myself, but it looks exactly like what is required here. I would
be interested in hearing whyy it didn't work well.
git subtree and subrepo may help mirroring but they are also not
ideal.
On one hand they can't mirror the history in a useful way, on the other
hand they can't mirror part of the project.
Thanks. Dmitry.
Hi Derick,
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.
Hello :)
Posting again, I just realized I used "reply" not "reply all"
Hi internals,
I'm glad to present a new JIT engine that is going to be used in the next
major PHP version. Now it's a real optimizing compiler with Intermediate
Representation similar to Java HotSpot server compiler.It makes a base for future improvements and eliminates many low-level
details of the existing PHP JIT. Instead of supporting assembler code for
different CPUs, now PHP generates a single IR and passes it to a
PHP-independent JIT engine.
Great work! This is a massive jump for PHP. Thank you :)
I don't have much concerns about the license etc as the ZE is already
under Zend the ZE license (never updated since Perforce acquired them,
tho'):
https://github.com/php/php-src/blob/master/Zend/LICENSE
I do really like the IR addition. This opens huge new opportunity, not
only for optimization and JIT but to move forward into bringing new
technology support to PHP (WASM f.e.). There are big challenges and I
am not sure yet it can be ever be fully possible to target WASM.
however, having the ability to do it with a subset of PHP, f.e. some
business logic classes etc., would already be amazing. I can't imagine
a php9 without taking this into account tbh. That would be kill php in
any way but that would definitively puts it in less competitive area
than others (JS, go, rust, ocaml f.e.), for another few years.
I have a simple php function working (just a small go app to parse the
IR text output and convert it. But that's not remotely a POC :). I
discussed with Dmitry and the idea would be to add a WASM target to
libIR (partial support or whatever is possible).
This is the part I would like to see more discussions or feedback as
it will define what could become possible or not. A certain level of
similarity or compatibility could make other targets much easier.
The old JIT implementation is going to be kept for a while.
I like the idea too. The sooner this work can be available as
experimental, the sooner it will get stable.
Best,
Pierre
@pierrejoye
Great work! This is a massive jump for PHP. Thank you :)
I don't have much concerns about the license etc as the ZE is already
under Zend the ZE license (never updated since Perforce acquired them,
tho'):https://github.com/php/php-src/blob/master/Zend/LICENSE
I do really like the IR addition. This opens huge new opportunity, not
only for optimization and JIT but to move forward into bringing new
technology support to PHP (WASM f.e.). There are big challenges and I
am not sure yet it can be ever be fully possible to target WASM.
Creating a new back-end for IR is significantly simpler than for old
PHP-JIT implementation.
However, I'm not sure if this will work for WASM, because PHP-JIT calls a
lot of functions from PHP itself.
I'm not sure how this should work with WASM. I just didn't research in this
area.
however, having the ability to do it with a subset of PHP, f.e. some
business logic classes etc., would already be amazing. I can't imagine
a php9 without taking this into account tbh. That would be kill php in
any way but that would definitively puts it in less competitive area
than others (JS, go, rust, ocaml f.e.), for another few years.I have a simple php function working (just a small go app to parse the
IR text output and convert it. But that's not remotely a POC :).
Really? You already use the IR Framework? :)
I discussed with Dmitry and the idea would be to add a WASM target to
libIR (partial support or whatever is possible).This is the part I would like to see more discussions or feedback as
it will define what could become possible or not. A certain level of
similarity or compatibility could make other targets much easier.The old JIT implementation is going to be kept for a while.
I like the idea too. The sooner this work can be available as
experimental, the sooner it will get stable.
Yes. I hope it's already quite stable. It passes all the nightly CI tests,
including Amp, Symfony, Laravel and Wordpress uit tests.
But it definitely will cause problems. The sooner we start the more time we
will have to release.
And keeping the old version for a while, we have a plan B.
Thanks. Dmitry.