Re: [PHP-DEV] A new JIT engine for PHP-8.4/9
On Sat, Sep 16, 2023 at 12:46 PM Hans Henrik Bergan 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 submodules``are 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.
Re: [PHP-DEV] A new JIT engine for PHP-8.4/9
On Sat, Sep 16, 2023 at 1:22 AM Tim Düsterhus wrote: > Hi > > On 9/15/23 17:50, Ben Ramsey wrote: > > 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.
Re: [PHP-DEV] A new JIT engine for PHP-8.4/9
On Mon, Sep 18, 2023 at 8:01 AM Pierre Joye wrote: > 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.
Re: [PHP-DEV] A new JIT engine for PHP-8.4/9
Hi Ben, On Fri, Sep 15, 2023 at 6:50 PM Ben Ramsey wrote: > On 9/15/23 09:35, Derick Rethans wrote: > > > 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. > As I said, I'm going to publish a presentation (in October). I'm not sure if we should have an RFC that will repeat it. Anyway, if you like to understand how PHP-JIT-IR works and explain this to others, I would appreciate this. I'm ready to answer any questions. > 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? > Pierre thinks about WASM backend. I like to write a C front-end and something similar to Truffle. > 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! > The IR project was developed under the "Zend by Perforce" umbrella. It paid for development, it has the copyright, but we choose the most permissive license. The main goal is the improvement of PHP, but we also like to involve non-PHP experts. Thanks. Dmitry.
Re: [PHP-DEV] A new JIT engine for PHP-8.4/9
Hi Derick, On Fri, Sep 15, 2023 at 5:35 PM Derick Rethans wrote: > 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.
Re: [PHP-DEV] A new JIT engine for PHP-8.4/9
On Fri, Sep 15, 2023 at 4:03 PM Juliette Reinders Folmer < php-internals_nos...@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.
Re: [PHP-DEV] A new JIT engine for PHP-8.4/9
Hello :) Posting again, I just realized I used "reply" not "reply all" On Mon, Sep 11, 2023 at 4:29 PM Dmitry Stogov 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] A new JIT engine for PHP-8.4/9
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~) On Sat, Sep 16, 2023, 00:22 Tim Düsterhus wrote: > Hi > > On 9/15/23 17:50, Ben Ramsey wrote: > > 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/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
Re: [PHP-DEV] A new JIT engine for PHP-8.4/9
Hi On 9/15/23 17:50, Ben Ramsey wrote: 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] A new JIT engine for PHP-8.4/9
On 9/15/23 09:35, Derick Rethans wrote: 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 OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] A new JIT engine for PHP-8.4/9
Hi Dmitry, On Fri, 15 Sep 2023, Dmitry Stogov wrote: > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] A new JIT engine for PHP-8.4/9
On 15-9-2023 12:15, Dmitry Stogov wrote: 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 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/12079 Thanks. 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
Re: [PHP-DEV] A new JIT engine for PHP-8.4/9
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 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/12079 > > Thanks. Dmitry. >
Re: [PHP-DEV] A new JIT engine for PHP-8.4/9
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/12079 Thanks. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] A new JIT engine for PHP-8.4/9
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.
