On 2/14/19 2:38 PM, Zeev Suraski wrote: > On Thu, Feb 14, 2019 at 12:19 PM Nikita Popov <nikita....@gmail.com> wrote: >> On Thu, Feb 14, 2019 at 10:43 AM Zeev Suraski <z...@php.net> wrote: >>> On Thu, Feb 14, 2019 at 10:20 AM Sebastian Bergmann <sebast...@php.net>
>> * First and foremost for me: Maintenance. We are only shortly after >> branching, and the PHP 7.4 and PHP 8.0 branches already have some >> significant divergences (e.g. in object handler APIs). I don't expect that >> this is going to be get as bad as PHP 5 vs PHP 7 internals, but I would >> also very much prefer not having to maintain a new large and complex chunk >> of code against two different major engine versions. >> > > That's a valid point, but given we're only a few months away from > feature-completing 7.4, as well as the general direction that most probably > more substantial changes will make it into 8.0 - I don't know that the > initial investment in a 7.4 version of JIT (and the marginal cost of then > maintaining it) would be too big. I believe Dmitry's proposing that while > realizing the bulk of the work will fall on his shoulders if we decide to > do it. Currently, I'm keeping in consistency two JIT branches. For master and PHP-7.4 (links in RFC). In case 7.4 don't pass, I stop its support. >> * Marketing: As you already mentioned yourself, adding a JIT is a great >> marketing point. I think that PHP 7 was quite successful from a marketing >> perspective, because it had a nice blend of major performance wins, some >> long-awaited features and a few incompatibilities. It would be great if we >> could repeat this with PHP 8, and I think that having a JIT and some major >> language feature (say generics) would be a great drive to upgrade. Adding >> the JIT earlier as an experimental feature would dilute this a lot. >> > > We both agree that if we include JIT in 7.4 it will dilute from the 'shiny > new thing' aspect of it when it's available in 8.0. That said - > realistically, it seems that JIT will not be as revolutionary as phpng was > in terms of real world performance impact, so if I had to guess - migration > to 8 it would be a lot slower than the migration to 7 (the motivation to > upgrade to 7 in the vast majority of companies I came across was > predominantly around performance; new features were a nice bonus). Marketing is simple :) We like to make good JIT in PHP-8, and we need feedback to really do it. The more interest we get to JIT in PHP-7.4 the better JIT might be implemented in PHP-8. > * Stability / Compatibility: While we can mark features as experimental all >> we want, let's fact it: If it exists, it's going to end up in production. I >> would prefer to only publicize the JIT once it is stable, and also >> importantly, has good integration with 3rd party extensions. Basically >> "just works". I know that Joe has been testing some of this exts (like pcov >> and pthreads) and their interaction with the JIT, and also been talking to >> some other maintainers of "low-level" extensions like profilers. From what >> I understood, quite some work will be needed to allow integration (beyond >> just disabling the JIT). Again, the early we know problems, the better. Most people will start testing PHP-8 with their third-party extension only after release. Then we will start getting reports about problems, and the solutions might need serious API or design changes, that are not allowed in minor releases... Thanks. Dmitry.
