On 2/1/19 4:23 PM, Nikita Popov wrote: > On Fri, Feb 1, 2019 at 2:12 PM Dmitry Stogov <dmi...@zend.com > <mailto:dmi...@zend.com>> wrote: > > > > On 2/1/19 11:55 AM, Joe Watkins wrote: > > 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 think an important point here is that this issue affects not only > Windows: It also affects any platform that uses clang as their compiler. > Notably this includes MacOS. > > Clang theoretically supports global registers, but only for > non-allocatable regs (rsp and rbp), which I think is not very useful for > this purpose.
We will have to provide a patch for CLANG, implementing PHP VM calling convention (HHVM, Erlang, Haskel did this). Thanks. Dmitry. > > So this problem needs to be solved not just for Windows support, but > also for MacOS support (and also FreeBSD and other clang-using platforms). > > Nikita > > > 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 <dmi...@zend.com > <mailto:dmi...@zend.com> > > <mailto:dmi...@zend.com <mailto: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 <mailto:z...@php.net> > > <mailto:z...@php.net <mailto:z...@php.net>>> wrote: > > >>> On Thu, Jan 31, 2019 at 6:47 PM Kalle Sommer Nielsen > > <ka...@php.net <mailto:ka...@php.net> <mailto:ka...@php.net > <mailto: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 > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
