On 2/6/19 12:26 PM, Nikita Popov wrote: > On Mon, Feb 4, 2019 at 8:30 AM Dmitry Stogov <dmi...@zend.com > <mailto:dmi...@zend.com>> wrote: > > > > On 2/3/19 9:00 PM, Nikita Popov wrote: > > On Sun, Feb 3, 2019 at 5:16 PM Zeev Suraski <vsura...@gmail.com > <mailto:vsura...@gmail.com>> wrote: > > > >> > >>> On 3 Feb 2019, at 16:43, Jan Ehrhardt <php...@ehrhardt.nl > <mailto:php...@ehrhardt.nl>> wrote: > >>> > >>> Zeev Suraski in php.internals (Sun, 3 Feb 2019 11:02:56 +0000): > >>>> > >>>> > >>>> How is that related? > >>> > >>> It is directly related with your statement that "developers > with other > >>> host OSs still use Linux for the actual PHP development". They > don't use > >>> Linux for the actual PHP development. They are using Windows. > >> > >> That statement was in a certain context - for those who use > containers and > >> Linux VMs, which is (as mentioned) a growing trend. I think > it's clear > >> that I'm not claiming it's everyone, or even the majority - but > if it > >> wasn't clear - it should be now... > >> > >> Zeev > >> > > > > I feel like this discussion ended up going a bit astray, with a > focus on > > only the issue of Windows support... While I think that we should > endeavor > > to support at least Windows and MacOS before the JIT hits a > release version > > of PHP, at this point in time (and for the purposes of the vote) the > > questions of maintenance and stability are the most important. > > If we don't start, we definitively won't get support. > > > > Ultimately > > those questions can't really be answered until interested parties > have > > reviewed the JIT codebase. To that end it would be helpful if: > > > > a) A PR of the JIT branch could be submitted against php-src, so > there is a > > place for review comments and more technical discussions. (It > might be > > necessary to squash, as GH doesn't deal with large history well.) > > OK. Not sure about re-base. > > > b) The RFC (or some other place) is extended with some high-level > design > > information on how the JIT works on a technical level. Some notes > on how > > JIT bugs are usually debugged would also be very helpful. > > > OK. I'll try to extend RFC with some design elements. > > Thanks. Dmitry. > > > As you probably spent a lot of time profiling the JIT, I'm wondering if > you have any insights about what the main issues are right now that > prevent better performance and what some idea to improve those would be.
Real-life apps more suffer from bad data locality and data set size. One of the metric that shows, how good/bad progam is executes is CPI (Cycles per Instruction). You may measure it using Linux perf (perf stat) or estimate using callgrind. For bench.php it's 0.5, for Wordpress 1.2. This means that Wordpress waste significantly more CPU time because of different stalls. Even if we improve execution, using JIT, and reduce the amount of executed instructions, this doesn't proportionally affects CPU cycles (and time), because many data related stalls are still there. > E.g. I don't think the JIT currently does any inlining (right?) and that > might be something that could give a benefit? Absolutely. Currently JIT keeps VM state in consistency, when it calls any standard VM handler, emits error/warning, throw exception, and just call any PHP API function. But this is not necessary for most fast paths. And this is the challenge for the next JIT improvement iteration. 1) Instead of immediate JIT-ing the whole function after hot-counter triggering, we will perform low-cost initial profiling, collecting jump probabilities, real run-time types and values. 2) Then we will generate code only for fast paths, especially optimized for our cases (information, collected during profiling). This code is not going to keep the VM state and may implement inlining of PHP functions and other smart optimizations. 3) The fast-path code is going to include "guard" check for transitions to slow paths that were never executes during profiling, but that can't be eliminated by static analyses (SSA info). 4) In case of guard failure, we should jump form JIT execution to VM, restoring the VM state consistency. This process named "deoptimization". I would recommend, spend some time reading related V8 presentations. https://v8.dev/docs/turbofan Thanks. Dmitry. > > Nikita
