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> > > wrote: > > > > > Am 31.01.2019 um 18:08 schrieb Derick Rethans: > > > > 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. > > > > > > ACK > > > > > > > Does it mean that when PHP 8.0 comes out (in roughly two years' time most > > probably), we'd be saying this is experimental? Or that only in the > > meantime, for the brave folks that want to experiment PHP 8.0 ~2yrs > before > > it's released, we'd say it's experimental but will remove that tag by the > > time 8.0 is released? > > > > I don't think we can really answer that question at this point in time. > That depends on how stable and compatible the JIT is by the time PHP 8.0 > comes around. But having it as a non-experimental feature should definitely > the goal, and I also think this is possible. > Agreed. > > If it's the former - I don't think we should go in this direction. If we > > decide that it's sensible to have it - I think we should work to ensure > > that it's production ready by the time PHP 8.0 is released. Offering it > as > > something experimental (i.e. not for production) in 7.4 can help us with > > that goal, as it will make it easier for a wider range of people to > > experiment with it and provide feedback. I can't think of any > > technological downsides to including it as experimental in 7.4 - there's > a > > slight "marketing" downside (it will be less of a shiny new thing in PHP > > 8.0), but personally I think the feedback we're likely to get is worth > it. > > > > There a number of downsides to including it in PHP 7.4: > > * 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. > * 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). * 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). I'm not too worried about it finding itself into production, as long as we make it clear that it's not ready for it. People who run experimental software in production are typically quite aware of the risk they're taking, and often they are quite determined too - so they might be the ones who check out Dmitry's code as it is today without waiting for our RFCs anyway. It's also quite reasonable that an experimental feature won't work with every last extension (as long as they're not super mainstream like MySQL or curl). Either way, I think the decision whether to include it in 7.4 or not is tactical. It's gaining wider testing exposure, at the expense of losing some 'sexiness' of a shiny new feature in 8.0. I see both approaches as entirely valid. Zeev
