# [RFC] JIT - Thread: https://externals.io/message/103903 - Original archive: https://news-web.php.net/php.internals/103903 - Started by Dmitry Stogov on 2019-01-31T09:43:55+00:00 - Messages: 107 - RFC: JIT (Implemented (PHP 8.0)) — https://externals.io/rfc/jit.md - Page 1 of 5: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/103903.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #103903 — Dmitry Stogov — 2019-01-31T09:43:55+00:00 URL: https://externals.io/message/103903#103903 Hi Internals, I'm glad to finally propose including JIT into PHP. https://wiki.php.net/rfc/jit In the current state it may be included both into PHP-8, where we are going to continue active improvement, and into PHP-7.4, as an experimental feature. Thanks. Dmitry. --- ## #103904 — Albert Casademont — 2019-01-31T10:15:58+00:00 URL: https://externals.io/message/103903#103904 · In reply to: #103903 Hi all, This is fantastic news thank you! I was going to ask if JIT would also work when Opcache is enabled with "opcache.file_cache_only". Our use case is a ReactPHP app that right now only has Opcache basically for the optimizations and we do not use the standard shared memory portion. We believe JIT could improve quite a lot these kinds of "long-running" processes that can serve multiple requests per-process. Thanks a lot! Best, > Hi Internals, > > > I'm glad to finally propose including JIT into PHP. > > > https://wiki.php.net/rfc/jit > > > In the current state it may be included both into PHP-8, where we are > going to continue active improvement, and into PHP-7.4, as an experimental > feature. > > > Thanks. Dmitry. --- ## #103905 — Benjamin Morel — 2019-01-31T10:26:22+00:00 URL: https://externals.io/message/103903#103905 · In reply to: #103903 Just want to say that this is HUGE, thanks so much for the work done here, can't wait to try it out, hopefully this will land in PHP 7.4! Ben > Hi Internals, > > > I'm glad to finally propose including JIT into PHP. > > > https://wiki.php.net/rfc/jit > > > In the current state it may be included both into PHP-8, where we are > going to continue active improvement, and into PHP-7.4, as an experimental > feature. > > > Thanks. Dmitry. --- ## #103908 — Dmitry Stogov — 2019-01-31T10:53:52+00:00 URL: https://externals.io/message/103903#103908 · In reply to: #103904 > Hi all, > > This is fantastic news thank you! I was going to ask if JIT would also > work when Opcache is enabled with "opcache.file_cache_only". Unfortunately, not yet, but we are planning to move opcache into PHP-8 core and allow optimization and JIT without caching. > Our use > case is a ReactPHP app that right now only has Opcache basically for the > optimizations and we do not use the standard shared memory portion. We > believe JIT could improve quite a lot these kinds of "long-running" > processes that can serve multiple requests per-process. Thanks a lot! Better to try and provide feedback right now. You can get sources and build PHP from the link in RFC. https://github.com/zendtech/php-src/ Thanks. Dmitry. > > Best, > > > > On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov > wrote: > > Hi Internals, > > > I'm glad to finally propose including JIT into PHP. > > > https://wiki.php.net/rfc/jit > > > In the current state it may be included both into PHP-8, where we > are going to continue active improvement, and into PHP-7.4, as an > experimental feature. > > > Thanks. Dmitry. --- ## #103910 — Marcos Passos — 2019-01-31T11:34:34+00:00 URL: https://externals.io/message/103903#103910 · In reply to: #103908 JIT, FFI, covariant return types and typed properties: what a year for PHP. Thank you all for working on making PHP better and better. - Marcos Em qui, 31 de jan de 2019 às 08:54, Dmitry Stogov escreveu: > > > > > […] > > Unfortunately, not yet, but we are planning to move opcache into PHP-8 > core and allow optimization and JIT without caching. > > > […] > > Better to try and provide feedback right now. > You can get sources and build PHP from the link in RFC. > https://github.com/zendtech/php-src/ > > Thanks. Dmitry. > > > […] --- ## #103927 — Nikita Popov — 2019-01-31T16:01:18+00:00 URL: https://externals.io/message/103903#103927 · In reply to: #103903 > Hi Internals, > > > I'm glad to finally propose including JIT into PHP. > > > https://wiki.php.net/rfc/jit > > > In the current state it may be included both into PHP-8, where we are > going to continue active improvement, and into PHP-7.4, as an experimental > feature. > > > Thanks. Dmitry. > This has been a long time on the horizon, nice to see this finally moving forward :) Here are some initial thoughts: I think that it's best to approach this issue from a cost/benefit angle. The benefits of the JIT compiler are roughly (and as already outlined in the RFC): * Significantly better performance for numerical code. * Slightly better performance for "typical" PHP web application code. * The potential to move more code from C to PHP, because PHP will now be sufficiently fast. However, there are also a number of costs, on which I'll expand in more detail: a) Maintenance: This is really my main concern. Right now there are about 3-4 people who I would trust to carry out a non-trivial language change, which will require touching the compiler, the virtual machine, the optimizer and the persistence layer. Each of those components is quite complex, in different ways. Some people who are comfortable with doing VM changes will struggle with implementing optimizer changes. Adding a JIT compiler exacerbates this issue further. Because this JIT is dynasm based, the core JIT code is essentially written in raw x86 assembly. This will further limit the pool of people who will be able to make non-trivial engine changes. Personally, I don't have any particular familiarity with writing x86 assembly, so it will likely take a while to get up to speed with this code. b) Bugs and stability: I think that everyone is aware that the initial PHP 7.3 release suffered from substantial stability issues, more than new minor version releases tend to do. I think there are multiple reasons for that (and we might want to start a conversation about our QA processes in a separate thread), but one main contributing factor were opcache optimizer bugs. Compiler optimizations are tricky and hard to verify, and we often only learn about issues once the optimizer makes contact with production codebases, which feature a much richer collection of code patterns than our test suite. One can wonder whether the relatively minor speedups we get from our optimization framework are really worth having these stability issues... Adding a JIT compiler adds a new dimension of stability issues. Next to "simple" executor bugs, and optimizer bugs, we now get additional bugs in the JIT. These are probably going to be hard to debug, as we'll have to drop down from our usual C-level tooling, down to inspecting assembly. c) Platform support: Having a JIT segregates platforms into two tiers: Those that have JIT support and those that don't. While that is not a problem per se, it does introduce some dangers. For example, if we decide to more parts of our C code into PHP because PHP is fast enough with a JIT, that will of course only be true for platforms that actually have JIT support. I'm not terribly concerned about loosing out some performance on MIPS, but we do need to make sure that all our main platforms are supported (Windows is a must there, imho). d) Debugging: I'm not sure whether or not this is an issue (maybe the RFC can clarify?), but I'm wondering if this will have an impact on things like XDebug. Will it be possible to using XDebug to accurately inspect variables at any point in time while the JIT is running? If not, that would be a big tooling regression. I think those are the main points that come to mind right now... Regards, Nikita --- ## #103933 — Dmitry Stogov — 2019-01-31T16:38:58+00:00 URL: https://externals.io/message/103903#103933 · In reply to: #103927 > On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov > wrote: > > Hi Internals, > > > I'm glad to finally propose including JIT into PHP. > > > https://wiki.php.net/rfc/jit > > > In the current state it may be included both into PHP-8, where we > are going to continue active improvement, and into PHP-7.4, as an > experimental feature. > > > Thanks. Dmitry. > > > This has been a long time on the horizon, nice to see this finally > moving forward :) > > Here are some initial thoughts: I think that it's best to approach this > issue from a cost/benefit angle. The benefits of the JIT compiler are > roughly (and as already outlined in the RFC): > >  * Significantly better performance for numerical code. >  * Slightly better performance for "typical" PHP web application code. >  * The potential to move more code from C to PHP, because PHP will now > be sufficiently fast. > > However, there are also a number of costs, on which I'll expand in more > detail: > > a) Maintenance: This is really my main concern. Right now there are > about 3-4 people who I would trust to carry out a non-trivial language > change, which will require touching the compiler, the virtual machine, > the optimizer and the persistence layer. Each of those components is > quite complex, in different ways. Some people who are comfortable with > doing VM changes will struggle with implementing optimizer changes. > > Adding a JIT compiler exacerbates this issue further. Because this JIT > is dynasm based, the core JIT code is essentially written in raw x86 > assembly. This will further limit the pool of people who will be able to > make non-trivial engine changes. Personally, I don't have any particular > familiarity with writing x86 assembly, so it will likely take a while to > get up to speed with this code. > > b) Bugs and stability: I think that everyone is aware that the initial > PHP 7.3 release suffered from substantial stability issues, more than > new minor version releases tend to do. I think there are multiple > reasons for that (and we might want to start a conversation about our QA > processes in a separate thread), but one main contributing factor were > opcache optimizer bugs. Compiler optimizations are tricky and hard to > verify, and we often only learn about issues once the optimizer makes > contact with production codebases, which feature a much richer > collection of code patterns than our test suite. One can wonder whether > the relatively minor speedups we get from our optimization framework are > really worth having these stability issues... > > Adding a JIT compiler adds a new dimension of stability issues. Next to > "simple" executor bugs, and optimizer bugs, we now get additional bugs > in the JIT. These are probably going to be hard to debug, as we'll have > to drop down from our usual C-level tooling, down to inspecting assembly. > > c) Platform support: Having a JIT segregates platforms into two tiers: > Those that have JIT support and those that don't. While that is not a > problem per se, it does introduce some dangers. For example, if we > decide to more parts of our C code into PHP because PHP is fast enough > with a JIT, that will of course only be true for platforms that actually > have JIT support. I'm not terribly concerned about loosing out some > performance on MIPS, but we do need to make sure that all our main > platforms are supported (Windows is a must there, imho). I don't see any problems with including JIT without Windows support. Windows runs PHP much slower any way. > d) Debugging: I'm not sure whether or not this is an issue (maybe the > RFC can clarify?), but I'm wondering if this will have an impact on > things like XDebug. Will it be possible to using XDebug to accurately > inspect variables at any point in time while the JIT is running? If not, > that would be a big tooling regression. XDebug may work with JIT or opcache disabled. > > I think those are the main points that come to mind right now... Anyway, I'm mostly agree with all the points. There are two options :) - take the challenge and start developing JIT together - forget about JIT, because we are afraid Thanks. Dmitry. > > Regards, > Nikita --- ## #103935 — Kalle Sommer Nielsen — 2019-01-31T16:47:44+00:00 URL: https://externals.io/message/103903#103935 · In reply to: #103933 Den tor. 31. jan. 2019 kl. 18.39 skrev Dmitry Stogov : > > > > > > […] > > I don't see any problems with including JIT without Windows support. > Windows runs PHP much slower any way. Without my usual Windows bias, I do believe it is a considerable fact like Nikita pointed out as Windows is a first class citizen in terms of operating systems we support. While PHP on Windows may not have the speed that the Unix counterpart have, it is still a very important development platform. Many developers develop on Windows and deploy on a Unix based system, being unable to test such an important feature in a development environment is also a large question mark. I'm personally interested in taking a look at it (and I'm certain Anatol does too), but simply dismissing is a no-go for me. -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #103940 — Zeev Suraski — 2019-01-31T17:04:03+00:00 URL: https://externals.io/message/103903#103940 · In reply to: #103935 > Without my usual Windows bias, I do believe it is a considerable fact > like Nikita pointed out as Windows is a first class citizen in terms > of operating systems we support. While PHP on Windows may not have the > speed that the Unix counterpart have, it is still a very important > development platform. Many developers develop on Windows and deploy on > a Unix based system, being unable to test such an important feature in > a development environment is also a large question mark. > As long as we can agree that very few actually *deploy *on Windows, I think we're on solid grounds. As the JIT implementation is likely to have at least *some* significant differences compared to Linux, I'm not sure what testing it on Windows would give you. JIT is supposed to be entirely transparent, and the performance characteristics - as well as the bug patterns - are likely to be quite different on Linux vs. Windows, at least in many cases. Is it really that important to have? I'm honestly a bit perplexed by how many people here viewing Windows support as a must have, while at the same time I think we all agree PHP is very scarcely found on production Windows servers, and JIT is a predominantly production feature. I'm personally interested in taking a look at it (and I'm certain > Anatol does too), but simply dismissing is a no-go for me. It'd be interesting to evaluate the cost associated with supporting Windows. Bare in mind, we're proposing to vote on this as a production feature for PHP 8 - which realistically means almost two years from now *at the earliest*. I'm sure we'd have Windows support a lot sooner than that if we decide that it's a must have. I agree with Nikita that the key question is in fact, do we or do we not want to introduce JIT in - with the main question being the maintenance cost. Let's tackle this question first, otherwise - why send Dmitry (and maybe others) for doing more work (Windows support) if we are likely to flush it all down the toilet? I think that if we reach the conclusion that Windows support is a must, we can condition the inclusion of JIT based on having it. Let's first agree on whether we want it in the first place. Zeev --- ## #103941 — Derick Rethans — 2019-01-31T17:08:25+00:00 URL: https://externals.io/message/103903#103941 · In reply to: #103903 > I'm glad to finally propose including JIT into PHP. > > https://wiki.php.net/rfc/jit I don't see anywhere in this RFC how it would affect thigns that do sneaky things with internals, such as Xdebug. How is that going to be affected? > In the current state it may be included both into PHP-8, where we are > going to continue active improvement, and into PHP-7.4, as an > experimental feature. I do not believe that something major like this should make it into any PHP 7.x release. Having it as experimental new feature in the master/PHP 8.0 branch makes the most sense to me. cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Like Xdebug? Consider a donation: https://xdebug.org/donate.php, or become my Patron: https://www.patreon.com/derickr twitter: @derickr and @xdebug --- ## #103942 — Dmitry Stogov — 2019-01-31T17:13:03+00:00 URL: https://externals.io/message/103903#103942 · In reply to: #103941 > > > > […] > > I don't see anywhere in this RFC how it would affect thigns that do > sneaky things with internals, such as Xdebug. How is that going to be > affected? > I suppose Xdebug should work on non-JIT-ed versions of the functions. Even JVM deoptimizes to bytecode when debugging. Thanks. Dmitry. > > […] > > I do not believe that something major like this should make it into any > PHP 7.x release. Having it as experimental new feature in the master/PHP > 8.0 branch makes the most sense to me. > > cheers, > Derick --- ## #103944 — Derick Rethans — 2019-01-31T18:12:05+00:00 URL: https://externals.io/message/103903#103944 · In reply to: #103942 > > > > > […] > > I suppose Xdebug should work on non-JIT-ed versions of the functions. > Even JVM deoptimizes to bytecode when debugging. So, in that case, I think I would need to be able to instruct the PHP JIT engine to be turned off. Perhaps through an API? Similarly, I think it might be useful for OPcache as well, as I am getting more people confused why some breakpoints don't work, or variables don't exist: https://bugs.xdebug.org/view.php?id=1609 cheers, Derick --- ## #103947 — Chase Peeler — 2019-01-31T18:30:52+00:00 URL: https://externals.io/message/103903#103947 · In reply to: #103940 > On Thu, Jan 31, 2019 at 6:47 PM Kalle Sommer Nielsen > wrote: > > > […] > > As long as we can agree that very few actually *deploy *on Windows, I think > we're on solid grounds. > As the JIT implementation is likely to have at least *some* significant > differences compared to Linux, I'm not sure what testing it on Windows > would give you. JIT is supposed to be entirely transparent, and the > performance characteristics - as well as the bug patterns - are likely to > be quite different on Linux vs. Windows, at least in many cases. > Is it really that important to have? > > I'm honestly a bit perplexed by how many people here viewing Windows > support as a must have, while at the same time I think we all agree PHP is > very scarcely found on production Windows servers, and JIT is a > predominantly production feature. > > I'm personally interested in taking a look at it (and I'm certain > > […] > > > It'd be interesting to evaluate the cost associated with supporting > Windows. Bare in mind, we're proposing to vote on this as a production > feature for PHP 8 - which realistically means almost two years from now *at > the earliest*. I'm sure we'd have Windows support a lot sooner than that > if we decide that it's a must have. I agree with Nikita that the key > question is in fact, do we or do we not want to introduce JIT in - with the > main question being the maintenance cost. Let's tackle this question > first, otherwise - why send Dmitry (and maybe others) for doing more work > (Windows support) if we are likely to flush it all down the toilet? > > Maybe we're the only ones, but we run production PHP on Windows. I have no issues with the idea of not initially having support for Windows. I can probably even live with never having support for Windows - provided that we don't find ourselves in a situation like Nikita mentioned where features start getting developed in PHP instead of C and require JIT in order to function. > I think that if we reach the conclusion that Windows support is a must, we > can condition the inclusion of JIT based on having it. Let's first agree > on whether we want it in the first place. > > Zeev > -- -- Chase chasepeeler@gmail.com --- ## #103948 — Dmitry Stogov — 2019-01-31T18:39:46+00:00 URL: https://externals.io/message/103903#103948 · In reply to: #103944 > > > > […] > > So, in that case, I think I would need to be able to instruct the PHP > JIT engine to be turned off. Perhaps through an API? > > Similarly, I think it might be useful for OPcache as well, Use zend_alter_ini_entry() to set "opcache.enable" to "0". Better to do it at RINIT. Thanks. Dmitry. > as I am > getting more people confused why some breakpoints don't work, or > variables don't exist: > https://bugs.xdebug.org/view.php?id=1609 > > cheers, > Derick --- ## #103955 — Kalle Sommer Nielsen — 2019-01-31T21:18:13+00:00 URL: https://externals.io/message/103903#103955 · In reply to: #103940 Den tor. 31. jan. 2019 kl. 19.04 skrev Zeev Suraski : > As long as we can agree that very few actually deploy on Windows, I think we're on solid grounds. > As the JIT implementation is likely to have at least some significant differences compared to Linux, I'm not sure what testing it on Windows would give you. JIT is supposed to be entirely transparent, and the performance characteristics - as well as the bug patterns - are likely to be quite different on Linux vs. Windows, at least in many cases. > Is it really that important to have? I think we can easily agree on the fact that by no means Windows is the top candidate for production. For me personally from a project standpoint, I believe it is something important that we can have a PHP that is pretty much as transparent and identical no matter what platform you are on, which is something I have tried to do myself by implementing various Linux routines for Windows natively to make PHP as platform independent as possible. > I'm honestly a bit perplexed by how many people here viewing Windows support as a must have, while at the same time I think we all agree PHP is very scarcely found on production Windows servers, and JIT is a predominantly production feature. With above being said, then I do also agree with you here, but I would like to have such functionality and improvements to our core system be as global as possible, naturally I don't think its fair either to require it so desperately upfront, but it should be a heavy consideration with the amount of work that we all have put into making Windows support one of the best among programming languages of similar category. > It'd be interesting to evaluate the cost associated with supporting Windows. Bare in mind, we're proposing to vote on this as a production feature for PHP 8 - which realistically means almost two years from now *at the earliest*. I'm sure we'd have Windows support a lot sooner than that if we decide that it's a must have. I agree with Nikita that the key question is in fact, do we or do we not want to introduce JIT in - with the main question being the maintenance cost. Let's tackle this question first, otherwise - why send Dmitry (and maybe others) for doing more work (Windows support) if we are likely to flush it all down the toilet? I don't think it would be fair either to simply dismiss the idea and many years of hard work for a detail like platform support either, and that is not the way I hope anyone would cast their vote. > I think that if we reach the conclusion that Windows support is a must, we can condition the inclusion of JIT based on having it. Let's first agree on whether we want it in the first place. Agreed. Naturally I would contribute in what I can to work on those parts (Windows). -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #103961 — Larry Garfield — 2019-02-01T00:29:28+00:00 URL: https://externals.io/message/103903#103961 · In reply to: #103947 > > > […] > Maybe we're the only ones, but we run production PHP on Windows. I have no > issues with the idea of not initially having support for Windows. I can > probably even live with never having support for Windows - provided that we > don't find ourselves in a situation like Nikita mentioned where features > start getting developed in PHP instead of C and require JIT in order to > function. Question from a non-compiler-engineer: Could we end up in a situation where future language features (in 8.3 or something) are only performant on JIT- enabled platforms? I know there were some RFCs rejected in the past on the grounds that they involved too many runtime checks (and thus a performance hit); if it were possible for a JIT to optimize some of those away, it might make the cost acceptable. However, if a JIT only works on some systems that might widen the gap between have- and have-not platforms. Is that a concern, or am I making things up? Or, is it a concern but we're legit OK with that happening (which is also an entirely valid decision to make)? --Larry Garfield --- ## #103967 — Dmitry Stogov — 2019-02-01T08:41:06+00:00 URL: https://externals.io/message/103903#103967 · In reply to: #103961 > > > […] > > Question from a non-compiler-engineer: Could we end up in a situation where > future language features (in 8.3 or something) are only performant on JIT- > enabled platforms? I know there were some RFCs rejected in the past on the > grounds that they involved too many runtime checks (and thus a performance > hit); if it were possible for a JIT to optimize some of those away, it might > make the cost acceptable. However, if a JIT only works on some systems that > might widen the gap between have- and have-not platforms. I think, JIT only approach doesn't make a lot of sense for PHP, with one of the most fast VM. And this is a trend. Even V8, starting from JIT only, switched back to VM+JIT. Thanks. Dmitry. > > Is that a concern, or am I making things up? Or, is it a concern but we're > legit OK with that happening (which is also an entirely valid decision to > make)? > > --Larry Garfield --- ## #103969 — Joe Watkins — 2019-02-01T08:55:35+00:00 URL: https://externals.io/message/103903#103969 · In reply to: #103967 Morning Dmitry, and internals, This is marvellous stuff, truly brilliant. I particularly appreciate the non-intrusive approach of setting jit'd code as the opcode handler, this makes life a little easier for hacky extension authors, I think. As others have said: I don't like the idea of omitting to support windows, less worried about fancy architectures. I'm not keen on the idea that there is no way to debug the code this generates outside of GDB, and I'm not sure how useful gdb will be: I've tried to debug JIT'd code in that before and it doesn't do so well, but I could easily have been doing it wrong. I'd be very happy to be corrected about this ? I'm not keen on the idea of merging this into 7.4, for various reasons that don't need to be repeated. Bottom line though, I love it, it's brilliant, and look forward to PHP 8. Thank you, Dmitry. Cheers Joe > > > > > […] > to > > […] > PHP is > > […] > that > > […] > work > > […] > no > > […] > that we > > […] > where > > […] > JIT- > > […] > the > > […] > performance > > […] > might > > […] > that > > […] > > I think, JIT only approach doesn't make a lot of sense for PHP, with one > of the most fast VM. And this is a trend. Even V8, starting from JIT > only, switched back to VM+JIT. > > Thanks. Dmitry. > > > […] > we're > > […] --- ## #103974 — Andrey Hristov — 2019-02-01T10:40:38+00:00 URL: https://externals.io/message/103903#103974 · In reply to: #103935 Hi, > Den tor. 31. jan. 2019 kl. 18.39 skrev Dmitry Stogov : > > […] > > Without my usual Windows bias, I do believe it is a considerable fact > like Nikita pointed out as Windows is a first class citizen in terms > of operating systems we support. While PHP on Windows may not have the > speed that the Unix counterpart have, it is still a very important > development platform. Many developers develop on Windows and deploy on > a Unix based system, being unable to test such an important feature in > a development environment is also a large question mark. in the age of CI systems it doesn't matter much what your primary local development platform is, even if it is different than the targeted platform. One creates a PR, pushes, CI triggers, checks validity, could be performance tested, and that's the real environment. And not to mention containers for local development when the code is actually run in a Linux container, no matter whether running on Win, Linux or Mac. > I'm personally interested in taking a look at it (and I'm certain > Anatol does too), but simply dismissing is a no-go for me. > Best, Andrey --- ## #103976 — Pierre Joye — 2019-02-01T11:12:30+00:00 URL: https://externals.io/message/103903#103976 · In reply to: #103933 > > > I don't see any problems with including JIT without Windows support. > Windows runs PHP much slower any way. > How so? I tend to disagree here. Except if recent changes affect Windows indirectly (as in optimization done on linux only). Also while I use php on windows less, I still see a large amount of companies using php on windows, in similar ways than on Linux. Nikita concerns are valid, PHP is and should remain a cross platform language. And some top OSes besides linux should remain a target. Easier said than done and willing to help at least for windows. I am sure msft teams will step in as well. --- ## #103981 — Andrey Hristov — 2019-02-01T11:49:20+00:00 URL: https://externals.io/message/103903#103981 · In reply to: #103976 Pierre, > > > > […] > > How so? I tend to disagree here. Except if recent changes affect Windows > indirectly (as in optimization done on linux only). > > Also while I use php on windows less, I still see a large amount of > companies using php on windows, in similar ways than on Linux. > > Nikita concerns are valid, PHP is and should remain a cross platform > language. And some top OSes besides linux should remain a target. Easier > said than done and willing to help at least for windows. I am sure msft > teams will step in as well. considering how open is Microsoft to open source nowadays it is probably a no brainer to have them help. They might only need some hinting :) > > […] > Cheers, Andrey --- ## #103982 — Nikita Popov — 2019-02-01T12:09:12+00:00 URL: https://externals.io/message/103903#103982 · In reply to: #103903 > Hi Internals, > > > I'm glad to finally propose including JIT into PHP. > > > https://wiki.php.net/rfc/jit > > > In the current state it may be included both into PHP-8, where we are > going to continue active improvement, and into PHP-7.4, as an experimental > feature. > > > Thanks. Dmitry. > I would like to check if the JIT provides an improvement for PHP-Parser. Unfortunately I'm getting a segfault when running the tests. Should be reproducible with git clone git@github.com:nikic/PHP-Parser.git cd PHP-Parser composer install php-jit vendor/bin/phpunit I tried to debug this. Unfortunately my gdb doesn't seem to work with JIT: It hangs when the script starts running, on line Zend/zend_gdb.c:84 in zend_gdb_register_code. I don't know if that's a bug or I need to do something additional here (I'm using GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git). Nikita --- ## #103983 — Nikita Popov — 2019-02-01T12:31:58+00:00 URL: https://externals.io/message/103903#103983 · In reply to: #103982 > > > > […] > > I would like to check if the JIT provides an improvement for PHP-Parser. > Unfortunately I'm getting a segfault when running the tests. Should be > reproducible with > > git clone git@github.com:nikic/PHP-Parser.git > cd PHP-Parser > composer install > php-jit vendor/bin/phpunit > > I tried to debug this. Unfortunately my gdb doesn't seem to work with JIT: > It hangs when the script starts running, on line Zend/zend_gdb.c:84 in > zend_gdb_register_code. I don't know if that's a bug or I need to do > something additional here (I'm using GNU gdb (Ubuntu 8.1-0ubuntu3) > 8.1.0.20180409-git). > > Nikita > Another project that I would like to test is amp (git@github.com:amphp/amp.git). Here I am getting a segfault only on shutdown, after tests finished running. However there are a number of test failures, all basically looking the same: 1) Amp\Test\AllTest::testPendingPromiseArray TypeError: Return value of Amp\Loop\Internal\TimerQueue::removeAndRebuild() must be an instance of Amp\Loop\Internal\TimerQueueEntry, null returned /home/nikic/amp/lib/Loop/Internal/TimerQueue.php:100 /home/nikic/amp/lib/Loop/Internal/TimerQueue.php:64 /home/nikic/amp/lib/Loop/NativeDriver.php:107 /home/nikic/amp/lib/Loop/Driver.php:134 /home/nikic/amp/lib/Loop/Driver.php:72 /home/nikic/amp/lib/Loop.php:84 /home/nikic/amp/test/AllTest.php:52 Here is the line that incorrectly gets a null: https://github.com/amphp/amp/blob/c6f8425473ecc1cfc6909cf42b39abb39a11c837/lib/Loop/Internal/TimerQueue.php#L100 Nikita --- ## #103984 — Dmitry Stogov — 2019-02-01T13:12:22+00:00 URL: https://externals.io/message/103903#103984 · In reply to: #103969 > Morning Dmitry, and internals, > > This is marvellous stuff, truly brilliant. I particularly appreciate the > non-intrusive approach of setting jit'd code as the opcode handler, this > makes life a little easier for hacky extension authors, I think. > > As others have said: > >   I don't like the idea of omitting to support windows, less worried > about fancy architectures. I can provide help to people who will going to implement JIT support for Windows. This is not going to be easy, because MSVC doesn't support "hybrid VM" and "global register variables", therefore the code is going to be more expensive. >   I'm not keen on the idea that there is no way to debug the code this > generates outside of GDB, and I'm not sure how useful gdb will be: I've > tried to debug JIT'd code in that before and it doesn't do so well, but > I could easily have been doing it wrong. I'd be very happy to be > corrected about this ? I'm not sure, what is wrong with GDB, and if any other debuggers have special API for run-time generated code. >   I'm not keen on the idea of merging this into 7.4, for various > reasons that don't need to be repeated. OK. It's not only your opinion. You may vote against, and persuade others. Thanks. Dmitry. > > Bottom line though, I love it, it's brilliant, and look forward to PHP 8. > > Thank you, Dmitry. > > Cheers > Joe > > > On Fri, 1 Feb 2019 at 09:41, Dmitry Stogov > wrote: > > > > > > […] > > wrote: > > […] > > > > […] > considerable fact > > […] > terms > > […] > have the > > […] > deploy on > > […] > feature in > > […] > Windows, I > > […] > significant > > […] > Windows > > […] > and the > > […] > likely to > > […] > Windows > > […] > agree PHP is > > […] > production > > […] > from now > > […] > than that > > […] > the key > > […] > in - with > > […] > question > > […] > more work > > […] > I have no > > […] > Windows. I can > > […] > provided that we > > […] > features > > […] > order to > > […] > situation where > > […] > performant on JIT- > > […] > past on the > > […] > performance > > […] > away, it might > > […] > systems that > > […] > > I think, JIT only approach doesn't make a lot of sense for PHP, with > one > of the most fast VM. And this is a trend. Even V8, starting from JIT > only, switched back to VM+JIT. > > Thanks. Dmitry. > > > […] > but we're > > […] > decision to > > […] --- ## #103985 — Dmitry Stogov — 2019-02-01T13:17:35+00:00 URL: https://externals.io/message/103903#103985 · In reply to: #103976 > > > On Thu, Jan 31, 2019, 11:39 PM Dmitry Stogov wrote: > > > > I don't see any problems with including JIT without Windows support. > Windows runs PHP much slower any way. > > > How so? I tend to disagree here. Except if recent changes affect Windows > indirectly (as in optimization done on linux only). More or less right. PHP uses GCC extensions, that are not available in MSVC. > Also while I use php on windows less, I still see a large amount of > companies using php on windows,  in similar ways than on Linux. > > Nikita concerns are valid, PHP is and should remain a cross platform > language. And some top OSes besides linux should remain a target. Easier > said than done and willing to help at least for windows. I am sure msft > teams will step in as well. It would be great, if MSFT team helps. I definitely, can't move JIT forward, and provide support for all platforms at the same time. Thanks. Dmitry. --- Next page: https://externals.io/message/103903.md?page=2