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 On Fri, 1 Feb 2019 at 09:41, Dmitry Stogov <dmi...@zend.com> wrote: > > > On 2/1/19 3:29 AM, Larry Garfield wrote: > > On Thursday, January 31, 2019 12:30:52 PM CST Chase Peeler wrote: > >> On Thu, Jan 31, 2019 at 12:04 PM Zeev Suraski <z...@php.net> wrote: > >>> On Thu, Jan 31, 2019 at 6:47 PM Kalle Sommer Nielsen <ka...@php.net> > >>> > >>> wrote: > >>>> 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? > >>> > >> 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. > > 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 > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
