Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:84014 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 84576 invoked from network); 27 Feb 2015 15:23:24 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Feb 2015 15:23:24 -0000 Authentication-Results: pb1.pair.com header.from=bobwei9@hotmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=bobwei9@hotmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.116.49 as permitted sender) X-PHP-List-Original-Sender: bobwei9@hotmail.com X-Host-Fingerprint: 65.55.116.49 blu004-omc1s38.hotmail.com Received: from [65.55.116.49] ([65.55.116.49:60780] helo=BLU004-OMC1S38.hotmail.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 38/C4-32582-8EB80F45 for ; Fri, 27 Feb 2015 10:23:23 -0500 Received: from BLU436-SMTP203 ([65.55.116.9]) by BLU004-OMC1S38.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Fri, 27 Feb 2015 07:22:22 -0800 X-TMN: [TZSx69FVY13eucRUbw0wyzeXy6g10d0O] X-Originating-Email: [bobwei9@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) In-Reply-To: Date: Fri, 27 Feb 2015 16:22:17 +0100 CC: PHP Internals , Dmitry Stogov Content-Transfer-Encoding: quoted-printable References: To: Xinchen Hui X-Mailer: Apple Mail (2.2070.6) X-OriginalArrivalTime: 27 Feb 2015 15:22:19.0392 (UTC) FILETIME=[2D1E5800:01D052A1] Subject: Re: [PHP-DEV] Re: About optimization for compiler From: bobwei9@hotmail.com (Bob Weinand) > Am 27.02.2015 um 16:12 schrieb Xinchen Hui : >=20 > On Fri, Feb 27, 2015 at 11:08 PM, Bob Weinand = wrote: >> Am 27.02.2015 um 07:53 schrieb Xinchen Hui : >>=20 >> Hey: >>=20 >> On Fri, Feb 27, 2015 at 2:22 PM, Xinchen Hui = wrote: >>=20 >> Hey Internals: >>=20 >> I was looking Bob's switch optimization.. >>=20 >> And, I am not against this switch optimization.. >>=20 >> I referring it to show where is my concerns came from >>=20 >> thanks >>=20 >>=20 >> then I start to worry about where is the place optimization = should >> goes.. >>=20 >> in generally, PHP is a interpreted language. IMO, it should >> compiler the PHP codes to opcode without any optimization(of course, >> we did some, but they won't change a lots of opcodes which should be >> generated).. >>=20 >> and, since 5.5, we already have opcache bundled in.. >>=20 >> thus, I am proposing a principle, that is: >>=20 >> in the future, we only do optimization in opcache side, and keep >> Zend Compiler without any optimization... considering Zend Compiler = do >> things in -O0. >>=20 >> since, optimization always are dangerous.. if we only do them in >> opcache, user can still run them codes with disable opcache, or at >> least disable some optimization level which cause that.. >>=20 >> what do you think? >>=20 >> thanks >>=20 >> -- >> Xinchen Hui >> @Laruence >> http://www.laruence.com/ >>=20 >>=20 >>=20 >>=20 >> -- >> Xinchen Hui >> @Laruence >> http://www.laruence.com/ >>=20 >>=20 >> Hmm. I'm not sure, but do we really want to have the optimizations = depending >> on opcache? >>=20 >> I'd rather shift to slowly adding the optimizations into Zend/, in = separate >> compiler steps you can (like in opcache too) enable and disable. >> It's actually a bit weird to have to include opcache just for its >> optimizations. Opcache should do what its name says: the sole task of > Actually, it was called ZendOptimizerPlus... I know, but still, it's better when an extension only does one thing and = not two. >> caching the op_arrays. >> We need to change an extension for nearly every little change in = Zend/. That >> shouldn't be the case either. >>=20 >> But just to say, it's not only a minor optimization, in a real world >> stateful parser it makes a difference of a few percent. >> And also, this optimization only adds a ZEND_SWITCH opcode, nothing = more. >> (except in case we can determine at compile-time where the switch = land, then >> it will be optimized out to a simple JMP) >>=20 > as I said, I am not against this change... I just want to setup a > rule, for where thoese optimization, which could also be done in > opcache. Doing it in opcache would currently need to play with extension-defined = opcodes etc. I'd rather not be so invasive in opcache that after the = optimizations it cannot run in a normal Zend VM anymore. (also a reason = why integrating into Zend would be a good idea) > or, maybe, we could embed opcache(Optimizer) into Zend later... but of > course, it only can happen in next major version... Do we really need a major version for this? It doesn't involve major = ABI/API breaks. The compiler step is usually also rather left untouched = by most extensions. If we want to do this, we could target 7.1 without = major issues. >=20 > thanks >> Bob >=20 >=20 >=20 > --=20 > Xinchen Hui > @Laruence > http://www.laruence.com/ Bob