Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:103974 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 62504 invoked from network); 1 Feb 2019 14:00:39 -0000 Received: from unknown (HELO more.superhosting.bg) (91.196.125.214) by pb1.pair.com with SMTP; 1 Feb 2019 14:00:39 -0000 Received: from [94.156.78.222] (port=50822 helo=[192.168.20.137]) by more.superhosting.bg with esmtpa (Exim 4.91) (envelope-from ) id 1gpWFW-0008cM-4p; Fri, 01 Feb 2019 12:40:44 +0200 To: Kalle Sommer Nielsen , Dmitry Stogov Cc: Nikita Popov , PHP internals References: <8d9dffd5-ea2c-e642-b777-4a4fd76b261a@zend.com> Message-ID: Date: Fri, 1 Feb 2019 12:40:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=0.6 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - more.superhosting.bg X-AntiAbuse: Original Domain - lists.php.net X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hristov.com X-Get-Message-Sender-Via: more.superhosting.bg: authenticated_id: php@hristov.com X-Authenticated-Sender: more.superhosting.bg: php@hristov.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [PHP-DEV] [RFC] JIT From: php@hristov.com (Andrey Hristov) Hi, On 31.01.19 г. 18:47 ч., Kalle Sommer Nielsen wrote: > Den tor. 31. jan. 2019 kl. 18.39 skrev Dmitry Stogov : >> >> >> >> On 1/31/19 7:01 PM, 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). >> >> I don't see any problems with including JIT without Windows support. >> Windows runs PHP much slower any way. > > 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. in the age of CI systems it doesn't matter much what your primary local development platform is, even if it is different than the targeted platform. One creates a PR, pushes, CI triggers, checks validity, could be performance tested, and that's the real environment. And not to mention containers for local development when the code is actually run in a Linux container, no matter whether running on Win, Linux or Mac. > 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. > Best, Andrey