Re: [PHP-DEV] php interpreter
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 c...@l-i-e.com 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-xclickhosted_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
Re: [PHP-DEV] php interpreter
(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 t...@punkave.com 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 c...@l-i-e.com 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-xclickhosted_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
Re: [PHP-DEV] php interpreter
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
Re: [PHP-DEV] Question about parser implementation details
On Sun, April 1, 2012 7:19 am, Florian Anderiasch wrote: I'd appreciate any hints on how to tackle this serious concern. If this actually wasn't an April Fool's joke... Never ignore the user contributed notes after doing a search like: http://php.net/roman http://us3.php.net/manual/en/function.base-convert.php#105414 Those notes may be 90% [bleep], but there are always hidden gems in some of them :-) Actually, even if it WAS an April Fool's joke, my second sentence still has merit. Sorry to reply so late, but nobody who took it seriously pointed this one out... PS No idea what spqr is, but 0r would probably be more appropriate. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
