Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:104109 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 20491 invoked from network); 4 Feb 2019 13:51:57 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 4 Feb 2019 13:51:57 -0000 To: internals@lists.php.net References: Date: Mon, 4 Feb 2019 11:32:47 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Posted-By: 46.193.65.172 Subject: Re: [PHP-DEV] [RFC] JIT From: ajf@ajf.me (Andrea Faulds) Message-ID: 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. > Hi Dmitry, Thank you for making an RFC for this. That makes it possible to have a proper discussion about the JIT idea. A concern I have with the current RFC is a lack of a good case for why it should be necessary; the case for JIT is based on performance benefits, but the examples provided are unconvincing to me because they seem too contrived. Both bench.php and drawing fractals represent a best-case example for a JIT, small programs which do heavy arithmetic and not much else. Maybe PHP being able to be used for this kind of software would be cool, but it wouldn't justify the added complexity (and for that matter security headaches) of adding a JIT to PHP given C, C++, FORTRAN and so on already exist and are better-suited to it. I guess what I am saying is that the JIT RFC could benefit from real-world examples that show a benefit to having it. The ideal application is something in between WordPress and your Mandelbrot example, one which has significant complexity (i.e. a plausible real-world application), hot code which a JIT can actually make notably faster than the current Zend VM, and is something not *too* far away from the kinds of applications people write in PHP today — even if you *could* write applications focussed on high-performance heavy number-crunching in PHP, I don't expect people would want to, even if it becomes less slow. Thanks, Andrea