Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92196
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 65.55.169.106 as permitted sender)
To: Lin Yo-An <cornelius.howl@gmail.com>
References: <CAKSD0w7tznoMvvUu2WyYGvNLpw_PoHB_A0UMBKNDPrWJzQsj1g@mail.gmail.com>
 <BY2PR0201MB17846D27AD2A265308DF83F5BF9F0@BY2PR0201MB1784.namprd02.prod.outlook.com>
 <CAKSD0w6gYPepZDa+6cJmzmozxiNuHkqmctjum__cU+N__8WJZA@mail.gmail.com>
CC: Xinchen Hui <laruence@php.net>, Nikita Popov <nikic@php.net>, Bob Weinand
	<bobwei9@hotmail.com>, Joe Watkins <pthreads@pthreads.org>, internals
	<internals@lists.php.net>
Message-ID: <570BC881.8000203@zend.com>
Date: Mon, 11 Apr 2016 18:53:37 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: <CAKSD0w6gYPepZDa+6cJmzmozxiNuHkqmctjum__cU+N__8WJZA@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------090206030201000703020807"
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Apr 2016 15:53:52.2524 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1783
Subject: Re: Object getter method optimization
From: dmitry@zend.com (Dmitry Stogov)

--------------090206030201000703020807
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit

Hi Yo-An

On 04/11/2016 02:54 PM, Lin Yo-An wrote:
> Hi Dmitry,
>
> How's it going?
>
> I traversed the code of opcache extension, and just found the 
> FUNC_INFO related macros.  I guess the accessor information is more 
> like an entry that should be put in the function info.

That, FUNC_INFO is available only during optimization (it's especially 
used in inter-procedure data-flow pass).
> Or... maybe we shall move the function info related functions into the 
> core? since we might have some optimization based on the function info 
> instead of optimizing opcode only in the future.
We consider, possibility of moving the whole Optimizer into Zend, but it 
won't change a lot, because expensive optimization make sense only with 
opcache (when script is optimized once and executed many times).

>
> And I think the function info we pre-processed in the compile-time 
> would help JIT to compile the opcode a lot.
Of course. Actually, the new optimization passes introduced in "master" 
branch came from our zend-jit project and reused to generate LLVM code.
>
> By the way, would you mind to let me know the plan of implementing the 
> JIT compilation in PHP? I saw your zend-jit branch is using LLVM as 
> the backend.
We don't have special plans yet. We are going to work on JIT later, and 
now we mainly work on interpretative optimizations.
Once we start JIT, it's going to be much difficult to change something 
in VM...
>
> In my experience, LLVM compiles large code a lot of slower.  what do 
> you think of using DynASM as the JIT backend?
Right. LLVM is not suitable for JIT. It's a compiler without front-end part.
We will probably go with DynASM from LuaJIT, Low Level Interpreter from 
WebKit or our own similar approach.

> V8 compiles ast nodes into native code directly without 
> interpreting/translating the op codes, I don't know if it's a good 
> approach to try. your thoughts?
In my experience, this approach doesn't work well especially with big 
PHP applications.

Thanks. Dmitry.
>
> Cheers, Yo-An
>
>
>
>
>


--------------090206030201000703020807--