Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:103998 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 6767 invoked from network); 1 Feb 2019 21:06:14 -0000 Received: from unknown (HELO mail-lf1-f43.google.com) (209.85.167.43) by pb1.pair.com with SMTP; 1 Feb 2019 21:06:14 -0000 Received: by mail-lf1-f43.google.com with SMTP id i26so5720837lfc.0 for ; Fri, 01 Feb 2019 09:46:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jCk/9oClFTk/o/sHCMwQnN0WjUszZ9H58cOdUsuk8zc=; b=ftSRADpKhcwOFyRGI6NG8q1vWC3PTeikt0sDuI4l+cydX+0SEG0YKs+MO+ET1xw6Ls rLyG4WmWNuMRpj7nBokRI3auqaZu58JJDHkeXAh3t8cRH0sK0R/BueP134TVzvB8qCZL C5CICAyf3fLwdYckf18MkBayAq7R62GV1JUg4sGB89ZGklOHOX6W2zrfXcBnF+vVf8gx aq52iGbyJU77nHd6gExYXmLTaAOwu8lKFz3Xe/JWKCVmABnTHX9Bid0caBDFSl/VTGBx rKjSUwtM4cnEJBVvNwjy5qHmUdVrHXPbkl4DshP+jiPTtFq5DOmrkkYXBjH8uzkE84eW 7Hww== X-Gm-Message-State: AJcUukcyQObR8r9jNnOLn6HK7TKOxvyhdg03e16UacRsFsT7Mmjil/zq 2V84pnylKLuqIcv/uaT5zIfovvkwk1kyK6bXt+4= X-Google-Smtp-Source: ALg8bN7vvoHJp6FPv/LGluwKUkxJ0NwJYocKtH3C74Jn2F83TE8aIKL3AGCaX2EjqICGGjGcanv4eropxOEtsf8Z8F4= X-Received: by 2002:a19:4cc3:: with SMTP id z186mr30384660lfa.37.1549043184787; Fri, 01 Feb 2019 09:46:24 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 1 Feb 2019 10:46:06 -0700 Message-ID: To: Nikita Popov Cc: Dmitry Stogov , PHP internals Content-Type: text/plain; charset="UTF-8" Subject: Re: [PHP-DEV] [RFC] JIT From: levim@php.net (Levi Morrison) On Thu, Jan 31, 2019 at 9:01 AM Nikita Popov wrote: > > On Thu, Jan 31, 2019 at 10:44 AM Dmitry Stogov wrote: > > > Hi Internals, > > > > > > I'm glad to finally propose including JIT into PHP. > > > > > > https://wiki.php.net/rfc/jit > > > > > > In the current state it may be included both into PHP-8, where we are > > going to continue active improvement, and into PHP-7.4, as an experimental > > feature. > > > > > > Thanks. Dmitry. > > > > This has been a long time on the horizon, nice to see this finally moving > forward :) > > Here are some initial thoughts: I think that it's best to approach this > issue from a cost/benefit angle. The benefits of the JIT compiler are > roughly (and as already outlined in the RFC): > > * Significantly better performance for numerical code. > * Slightly better performance for "typical" PHP web application code. > * The potential to move more code from C to PHP, because PHP will now be > sufficiently fast. > > However, there are also a number of costs, on which I'll expand in more > detail: > > a) Maintenance: This is really my main concern. Right now there are about > 3-4 people who I would trust to carry out a non-trivial language change, > which will require touching the compiler, the virtual machine, the > optimizer and the persistence layer. Each of those components is quite > complex, in different ways. Some people who are comfortable with doing VM > changes will struggle with implementing optimizer changes. > > Adding a JIT compiler exacerbates this issue further. Because this JIT is > dynasm based, the core JIT code is essentially written in raw x86 assembly. > This will further limit the pool of people who will be able to make > non-trivial engine changes. Personally, I don't have any particular > familiarity with writing x86 assembly, so it will likely take a while to > get up to speed with this code. > > b) Bugs and stability: I think that everyone is aware that the initial PHP > 7.3 release suffered from substantial stability issues, more than new minor > version releases tend to do. I think there are multiple reasons for that > (and we might want to start a conversation about our QA processes in a > separate thread), but one main contributing factor were opcache optimizer > bugs. Compiler optimizations are tricky and hard to verify, and we often > only learn about issues once the optimizer makes contact with production > codebases, which feature a much richer collection of code patterns than our > test suite. One can wonder whether the relatively minor speedups we get > from our optimization framework are really worth having these stability > issues... > > Adding a JIT compiler adds a new dimension of stability issues. Next to > "simple" executor bugs, and optimizer bugs, we now get additional bugs in > the JIT. These are probably going to be hard to debug, as we'll have to > drop down from our usual C-level tooling, down to inspecting assembly. > > c) Platform support: Having a JIT segregates platforms into two tiers: > Those that have JIT support and those that don't. While that is not a > problem per se, it does introduce some dangers. For example, if we decide > to more parts of our C code into PHP because PHP is fast enough with a JIT, > that will of course only be true for platforms that actually have JIT > support. I'm not terribly concerned about loosing out some performance on > MIPS, but we do need to make sure that all our main platforms are supported > (Windows is a must there, imho). > > d) Debugging: I'm not sure whether or not this is an issue (maybe the RFC > can clarify?), but I'm wondering if this will have an impact on things like > XDebug. Will it be possible to using XDebug to accurately inspect variables > at any point in time while the JIT is running? If not, that would be a big > tooling regression. > > I think those are the main points that come to mind right now... > > Regards, > Nikita I strongly with Nikita's points on cost/benefit analysis. I have written a lot but thrown it away because I think this point is so important: It appears that the JIT does not work on Clang or MSVC compilers. As such, I consider this dead on arrival, even if it's considered experimental. There are cross-platform JIT's out there -- how do they manage it? I think that's the next critical step.