[PHP-DEV] php interpreter

Hello

I am new to php runtime. i am doing some research on runtime
interpreter. can anyone please tell me where the interpreter of the
php runtime is ? which file ? and does the php runtime has a JIT
compiler ?

Thanks

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On Wed, May 9, 2012 5:05 pm, Xin Tong wrote:

> I am new to php runtime. i am doing some research on runtime
> interpreter. can anyone please tell me where the interpreter of the
> php runtime is ? which file ? and does the php runtime has a JIT
> compiler ?

I believe the interpreter is built out of bison/yacc files, so you
could start with those to find out where they put it.

The php runtime is a JIT parser/compiler to a bytecode, which is then
run by the Zend Engine (see above).

Actually, that last statement might imply the the zend directory would
also be a good place to look.

Finally, it should be noted that APC and other caching mechanisms save
a great deal of time by not hitting the disk to load the script, but
keeping it in RAM, if possible.

As "gravy" on top of that, the bytecode is saved in cache instead of
source, so it is not a JIT if one of those caches is in use.

Psuedo code to describe the difference the APC (or other cache) makes:


//save hitting the hard disk
if ( $source_code = in_cache($path)){
}
else{
//super-duper slow!!!
$source_code = file_get_contents($path);
}
$bytecode = zend_parse($source_code);
zend_execute($bytecode);

//save hitting the hard disk
//and a small bonus, cache the bytecode, not source:

if ($bytecode = in_cache($path)){
//do nothing
}
else{
$source_code = file_get_contents($path);
$bytecode = zend_parse($source_code);
}
zend_execute($bytecode);


The savings from parsing is chump change compared to disk I/O.

It's also trivial chump change to implement.

Ever ounce counts :-)

--
brain cancer update:
http://richardlynch.blogspot.com/search/label/brain%20tumor
Donate:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Hi!

>> I am new to php runtime. i am doing some research on runtime
>> interpreter. can anyone please tell me where the interpreter of the
>> php runtime is ? which file ? and does the php runtime has a JIT
>> compiler ?

PHP compiles source code into Zend Engine bytecode - this is done by the
compiler in zend_language_scanner.l, zend_language_parser.y and
zend_compile.c. This code is the executed by the opcode engine in
zend_execute.c and zend_vm_execute.h. The latter is generated from
zend_vm_def.h by means of the script zend_vm_gen.php.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

I've seen this statement before about the impact of caching the actual
compilation (or mere tokenization?) to bytecode being very small
compared to the impact of avoiding disk access. I am curious if there
are any measurements breaking this down. Read-only access to code in
files already buffered by the OS (not files read for the first time)
ought to be very fast.

On Tue, May 22, 2012 at 11:00 AM, Richard Lynch <[email protected]> wrote:
> On Wed, May 9, 2012 5:05 pm, Xin Tong wrote:
>
>> I am new to php runtime. i am doing some research on runtime
>> interpreter. can anyone please tell me where the interpreter of the
>> php runtime is ? which file ? and does the php runtime has a JIT
>> compiler ?
>
> I believe the interpreter is built out of bison/yacc files, so you
> could start with those to find out where they put it.
>
> The php runtime is a JIT parser/compiler to a bytecode, which is then
> run by the Zend Engine (see above).
>
> Actually, that last statement might imply the the zend directory would
> also be a good place to look.
>
> Finally, it should be noted that APC and other caching mechanisms save
> a great deal of time by not hitting the disk to load the script, but
> keeping it in RAM, if possible.
>
> As "gravy" on top of that, the bytecode is saved in cache instead of
> source, so it is not a JIT if one of those caches is in use.
>
> Psuedo code to describe the difference the APC (or other cache) makes:
>
>
> //save hitting the hard disk
> if ( $source_code = in_cache($path)){
> }
> else{
>  //super-duper slow!!!
>  $source_code = file_get_contents($path);
> }
> $bytecode = zend_parse($source_code);
> zend_execute($bytecode);
>
> //save hitting the hard disk
> //and a small bonus, cache the bytecode, not source:
>
> if ($bytecode = in_cache($path)){
>  //do nothing
> }
> else{
>  $source_code = file_get_contents($path);
>  $bytecode = zend_parse($source_code);
> }
> zend_execute($bytecode);
>
>
> The savings from parsing is chump change compared to disk I/O.
>
> It's also trivial chump change to implement.
>
> Ever ounce counts :-)
>
> --
> brain cancer update:
> http://richardlynch.blogspot.com/search/label/brain%20tumor
> Donate:
> https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>



--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

(I'm not questioning that APC makes an enormous difference. That's
painfully obvious from 100 miles away on our servers (: )

On Thu, May 24, 2012 at 11:23 AM, Tom Boutell <[email protected]> wrote:
> I've seen this statement before about the impact of caching the actual
> compilation (or mere tokenization?) to bytecode being very small
> compared to the impact of avoiding disk access. I am curious if there
> are any measurements breaking this down. Read-only access to code in
> files already buffered by the OS (not files read for the first time)
> ought to be very fast.
>
> On Tue, May 22, 2012 at 11:00 AM, Richard Lynch <[email protected]> wrote:
>> On Wed, May 9, 2012 5:05 pm, Xin Tong wrote:
>>
>>> I am new to php runtime. i am doing some research on runtime
>>> interpreter. can anyone please tell me where the interpreter of the
>>> php runtime is ? which file ? and does the php runtime has a JIT
>>> compiler ?
>>
>> I believe the interpreter is built out of bison/yacc files, so you
>> could start with those to find out where they put it.
>>
>> The php runtime is a JIT parser/compiler to a bytecode, which is then
>> run by the Zend Engine (see above).
>>
>> Actually, that last statement might imply the the zend directory would
>> also be a good place to look.
>>
>> Finally, it should be noted that APC and other caching mechanisms save
>> a great deal of time by not hitting the disk to load the script, but
>> keeping it in RAM, if possible.
>>
>> As "gravy" on top of that, the bytecode is saved in cache instead of
>> source, so it is not a JIT if one of those caches is in use.
>>
>> Psuedo code to describe the difference the APC (or other cache) makes:
>>
>>
>> //save hitting the hard disk
>> if ( $source_code = in_cache($path)){
>> }
>> else{
>>  //super-duper slow!!!
>>  $source_code = file_get_contents($path);
>> }
>> $bytecode = zend_parse($source_code);
>> zend_execute($bytecode);
>>
>> //save hitting the hard disk
>> //and a small bonus, cache the bytecode, not source:
>>
>> if ($bytecode = in_cache($path)){
>>  //do nothing
>> }
>> else{
>>  $source_code = file_get_contents($path);
>>  $bytecode = zend_parse($source_code);
>> }
>> zend_execute($bytecode);
>>
>>
>> The savings from parsing is chump change compared to disk I/O.
>>
>> It's also trivial chump change to implement.
>>
>> Ever ounce counts :-)
>>
>> --
>> brain cancer update:
>> http://richardlynch.blogspot.com/search/label/brain%20tumor
>> Donate:
>> https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=FS9NLTNEEKWBE
>>
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
>
>
> --
> Tom Boutell
> P'unk Avenue
> 215 755 1330
> punkave.com
> window.punkave.com



--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

On 05/24/2012 08:23 AM, Tom Boutell wrote:
> I've seen this statement before about the impact of caching the actual
> compilation (or mere tokenization?) to bytecode being very small
> compared to the impact of avoiding disk access. I am curious if there
> are any measurements breaking this down. Read-only access to code in
> files already buffered by the OS (not files read for the first time)
> ought to be very fast.

I don't think anyone has any hard numbers on what percentage is gained
from each of the optimizations that APC brings. There are actually 3
separate areas, not 2. The obvious skip-compile and skip-disk-read, but
also the fact that non-conditional functions and classes are cached and
the compiled op arrays modified to NOP out the DECLARE_FUNCTION and
DECLARE_CLASS opcodes.

The percentage gains are going to different depending on the
characteristics of your code. If you have thousands of functions and
classes but your code is relatively compact, then the function/class
caching might be more significant.

-Rasmus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Hi!

> I've seen this statement before about the impact of caching the actual
> compilation (or mere tokenization?) to bytecode being very small
> compared to the impact of avoiding disk access. I am curious if there
> are any measurements breaking this down. Read-only access to code in
> files already buffered by the OS (not files read for the first time)
> ought to be very fast.

We did some measurements a long time ago at Zend, but I don't have the
numbers right now and anyway the engine changed so much since then they
are probably irrelevant anyway. However, the main gist is right - time
saved on compilation is not that much. One of the reasons to that is
that some of the data structures that are used by the engine are dynamic
(class tables, class variables, static variables, etc.) which means a
lot of data needs still to be handled to make script stored in SHM
runnable. Which greatly decreases savings from not compiling it. The
disk read however is still saved, and since unlike compilation it's a
system call and talks to potentially very slow (compared to memory)
device, the savings are significant. Even with OS cache, you still have
context switches and copying the data, etc. With some work I think it is
possible to make PHP script to run with zero system calls spent on
loading script files.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php