gmane.comp.php.devel

Re: [PHP-DEV] php interpreter

Rasmus Lerdorf — 2012-05-24T15:49:24

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

Re: [PHP-DEV] php interpreter

Tom Boutell — 2012-05-24T15:24:17

(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 <tom< at >punkave.com> wrote:

Re: [PHP-DEV] php interpreter

Tom Boutell — 2012-05-24T15:23:49

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 <ceo< at >l-i-e.com> wrote:

Re: [PHP-DEV] zend_execute_internal hook missing from PHP 5

Stas Malyshev — 2012-05-23T14:50:13

Hi!


So in zend_vm_def.h we have:

                if (!zend_execute_internal) {
                        /* saves one function call if
zend_execute_internal is not used */

fbc->internal_function.handler(opline->extended_value, ret->var.ptr,
(fbc->common.fn_flags & ZEND_ACC_RETURN_REFERENCE) ? &ret->var.ptr :
NULL, EX(object), RETURN_VALUE_USED(opline) TSRMLS_CC);
                } else {
                        zend_execute_internal(EXECUTE_DATA,
RETURN_VALUE_USED(opline) TSRMLS_CC);
                }

But in zend_call_function it goes just:

                ((zend_internal_function *)
EX(function_state).function)->handler(fci->param_count,
*fci->retval_ptr_ptr, fci->retval_ptr_ptr, fci->object_ptr, 1 TSRMLS_CC);

So looks like the code is not consistent. You can still catch user
functions with zend_execute override but not the internal ones. No idea
why the difference exists, I'll look through commits and if I find no
reason I guess the should be synchronized.

Re: [PHP-DEV] APC benchmark

Johannes Schlüter — 2012-05-23T14:40:33

What information do you want to gain from that? A general benchmark is
not that useful for you as a user. Results heavily depend on the
application, the hardware and the usage patterns of the application. A
benchmark like "my application runs 3 times faster while serving 5-times
more users in parallel" tells nothing.

If you want to test an APC patch this depends a bit on the patch etc.
est provide the patch.

johannes

Re: [PHP-DEV] PHP governance question?

Florian Anderiasch — 2012-05-23T09:48:35

It might be worth mentioning that PHP doesn't have a governing body
(like the Python Software Software, PSF) in the background, only the PHP
Group (see phpinfo() -> Credits or what Pierre said) - but with
different goals (someone else might want to step in to clarify).

Greetings,
Florian

Re: [PHP-DEV] php interpreter

Stas Malyshev — 2012-05-23T02:11:45

Hi!


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.

Re: [PHP-DEV] Catchable - marking methods just like static?

Richard Lynch — 2012-05-22T21:32:15

If I understand set_exception_handler correctly, you could simply make
anything that reaches that state simply not return at all, and exit.

If you are that serious about the problem, the code expecting a result
and not an exception won't get anything at all.

And code with proper exception handling will do the right thing,
assuming you have written all your exception handlers at every layer
correctly.

Personally, try/catch and throw always felt like "GOTO" to me, and the
larger the codebase, the harder I found it to track down who was the
thrower and who was the catcher.

Reminded me of the old Abbot and Costello baseball routine.

Re: [PHP-DEV] 2/3 = ??? Re: [PHP-DEV] [VOTE] Vote change for empty() RFC

Sanford Whiteman — 2012-05-22T21:29:31

It does seem long-winded toward the top. I guess it's notable that in
all that text, it doesn't even note the floor/ceiling concept. I
interpret the absence as because it's obvious, but you could argue
(given the inanity of the Ask.com answers) that isn't obvious enough
to be left out of the "'pedia of record." Maybe someone on Internals
is also an active Wiki editor.

Re: [PHP-DEV] 2/3 = ??? Re: [PHP-DEV] [VOTE] Vote change for empty() RFC

Richard Lynch — 2012-05-22T21:00:05

I should have been more clear:

Whether that article addresses rounding up, down or sideways, it's an
awfully long article for what should be a fairly simple thing...

I know I started zoning out long before the halfway mark.

I certainly didn't do the math for every example from every
country/quorum/entity...

Actually, if we used the "abstain == no" logic of some bodies, I don't
think any of our RFCs would pass :-)

Re: [PHP-DEV] 2/3 = ??? Re: [PHP-DEV] [VOTE] Vote change for empty() RFC

Sanford Whiteman — 2012-05-22T19:05:26


I agree, don't see any relevant edges.

From what I can see in the "bylaws for writing bylaws" world, it is
understood that you must have whole persons unless you *specifically*
make an exception that you will use the ceiling.

Re: [PHP-DEV] 2/3 = ??? Re: [PHP-DEV] [VOTE] Vote change for empty() RFC

Kris Craig — 2012-05-22T18:56:54

On Tue, May 22, 2012 at 11:51 AM, Sanford Whiteman <
swhitemanlistens-software< at >cypressintegrated.com> wrote:

I'm not sure I understand where the conflict is.  2/3 * 50 == 33 1/3.
 Therefore, 33 states would be just below the required 2/3, while 34 states
would be just above it.  So the 34 figure you quoted seems to match this
perfectly.

The article does mention some ambiguity, but that's pertaining to whether
the "total" includes everyone who *can* vote or just everyone who *did*
vote.  As far as I know, that's not relevant to this discussion.

--Kris

Re: [PHP-DEV] 2/3 = ??? Re: [PHP-DEV] [VOTE] Vote change for empty() RFC

Sanford Whiteman — 2012-05-22T18:51:09


Can you point to where there's any suggestion of using the ceiling
(rounding up) instead of requiring whole persons? In fact, the
Wikipedia page matter-of-factly says "...two thirds (currently 34) of
the states...."

Re: [PHP-DEV] APC benchmark

Tom Boutell — 2012-05-22T17:42:55

Including Wordpress in your test does sound fairly realistic actually,
but it's a good sign that something else becomes the bottleneck with
APC enabled (:

On Tue, May 22, 2012 at 12:46 PM, Mohammad Saleh <msaleh811< at >hotmail.com> wrote:

RE: [PHP-DEV] APC benchmark

Mohammad Saleh — 2012-05-22T16:46:49

Thank you for the feedback Tom.

I actually created a simulated test with jmeter and wordpress and was testing that with and without apc (simulation of a set of authors and readers).
Once I turned on APC, I realized my db server became a bottleneck and I was not able to test the max throughput.

Your scenario removes the db and focuses strictly on the cached pages, so I will give that a try.

Thanks and if there are any other suggestions, please do let me know!

- Mohammad

Re: [PHP-DEV] APC benchmark

Tom Boutell — 2012-05-22T15:38:56

You might be better off testing a nontrivial case like a framework
based web application's homepage with and without APC turned on for
100 fetches. That's where APC really shines.

On Tue, May 22, 2012 at 11:18 AM, Mohammad Saleh <msaleh811< at >hotmail.com> wrote:

[PHP-DEV] APC benchmark

Mohammad Saleh — 2012-05-22T15:18:13

All,

I was looking for a standard benchmark script that I could run with and without apc caching to see the general gains.
Is there something that is used by the internals team for such tests?
If not, are there any recommendations?


Thanks,
Mohammad

Re: [PHP-DEV] php interpreter

Richard Lynch — 2012-05-22T15:00:31


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 :-)

[PHP-DEV] 2/3 = ??? Re: [PHP-DEV] [VOTE] Vote change for empty() RFC

Richard Lynch — 2012-05-22T14:46:43

Regarding the 2/3 super-majority rule...

I thought I'd check the non-authorative but always interesting
wikipedia article...

Apparently, we are not the only ones confused by edge cases:

http://en.wikipedia.org/wiki/Supermajority

Re: [PHP-DEV] Re: [VOTE] Vote change for empty() RFC

Richard Lynch — 2012-05-22T14:35:01

I had voted none.

I really don't care about empty, because it has changed edge cases in
every major release, so I can't use it.

Therefore and herewith, I officially change my "none" vote to "empty
only"

Please put a fork in it and call it done.

Re: [PHP-DEV] memory usage ouchy

Tom Boutell — 2012-05-22T14:06:46

Actually, I just updated Rasmus' demo program to use assocative arrays
instead of objects.

In PHP 5.4.x, the associative array version uses more memory than the
object oriented version.

That's because PHP 5.4.x is using a flat array for predeclared
properties, as was mentioned earlier by Gustavo.

Associative arrays:

524288 bytes

Objects:

262144 bytes

The object-oriented version is also faster, by about 20%.

Interestingly these results don't change much if I make the property
names/keys much shorter. Probably there's a minimum allocation of 64
bytes for these or something.

It would appear there is no longer a penalty simply for using many
objects vs. many associative arrays in PHP 5.4. The opposite, in fact.
I'm sure arrays didn't get slower, but objects now take advantage of
some optimizations that become possible when properties are
predeclared.

However this doesn't mean that calling lots of setters will
necessarily be as fast as direct property access... oh what the heck,
let's test that too:

Calling dead-simple setters for the four properties rather than
setting them directly slows down the OOP version to the point where it
runs at just about the same speed as the associative array version.
That's not terrible. Direct property access is still fastest (after
all that's what the setters do after they pay the overhead of the
function call).

On Mon, May 21, 2012 at 9:23 PM, Richard Lynch <ceo< at >l-i-e.com> wrote: