[PHP-DEV] NEUTRAL Benchmark Results for PHP Master 2015-12-30
Results for project PHP master, build date 2015-12-30 06:30:31+02:00 commit: 65e456f previous commit:8a6f905 revision date: 2015-12-29 23:14:53+01:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB mem:128 GB os: CentOS 7.1 kernel: Linux 3.10.0-229.4.2.el7.x86_64 Baseline results were generated using release php-7.0.0, with hash 60fffd2 from 2015-12-01 04:16:47+00:00 --- benchmark relative change since change since current rev run std_dev* last run baseline with PGO --- :-| Wordpress 4.2.2 cgi -T1 0.10% -0.09% 0.18% 7.02% :-| Drupal 7.36 cgi -T1 0.22% 0.30% 0.09% 4.12% :-| MediaWiki 1.23.9 cgi -T5000 0.13% 0.03% 1.50% 2.92% :-| bench.php cgi -T100 0.02% 0.68% 1.40% 4.62% :-| micro_bench.php cgi -T10 0.03% -0.61% -0.03% 4.36% :-| mandelbrot.php cgi -T100 0.49% -0.15%-12.14% -2.07% --- * Relative Standard Deviation (Standard Deviation/Average) Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in fetches/second while all others are measured in seconds. More details on measurements methodology at: https://01.org/lp/documentation/php-environment-setup. Subject Label Legend: Attributes are determined based on the performance evolution of the workloads compared to the previous measurement iteration. NEUTRAL: performance did not change by more than 1% for any workload GOOD: performance improved by more than 1% for at least one workload and there is no regression greater than 1% BAD: performance dropped by more than 1% for at least one workload and there is no improvement greater than 1% UGLY: performance improved by more than 1% for at least one workload and also dropped by more than 1% for at least one workload Our lab does a nightly source pull and build of the PHP project and measures performance changes against the previous stable version and the previous nightly measurement. This is provided as a service to the community so that quality issues with current hardware can be identified quickly. Intel technologies' features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Number Format Separator
Hi internals! I'd like to propose for the inclusion of a digit separator in PHP. This will help to promote the readability of numerical literals in code by enabling for the underscore character to be used in between digits. RFC: https://wiki.php.net/rfc/number_format_separator PR: https://github.com/php/php-src/pull/1699 Thanks, Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Line numbers for "finally"
Hi!
While investigating an issue with Xdebug and fast_call/fast_ret, I
noticed that the opcodes "associated" with the "finally" statement, are
rolled up in the previous line.
The code:
1
Produces:
line #* E I O op fetch ext return
operands
-
5 0 E > ECHO
'try%0A'
1 > JMP ->7
6 2 E > > CATCH
'Catch1', !0, ->5
7 3> ECHO
'catch1%0A'
4 > JMP ->7
8 5 E > > CATCH
'Catch2', !0
9 6> ECHO
'catch2%0A'
7> > FAST_CALL->9
8* JMP ->11
11 9> ECHO
'finally%0A'
10 > FAST_RET
1311> ECHO
'end%0A'
1412 > RETURN null
The FAST_CALL/JMP instructions should really be linked to line 10. Not
doing so produces confusing results while doing code coverage, where it now
shows that the "echo catch2\n" on line 9 is executed. This is of course not
the case, but the linking of FAST_CALL and JMP to line 9 makes it look like
this. Is it possible to change this so thta the FAST_CALL and JMP are linked
to line 10 instead?
And secondly, I am struggeling with where FAST_CALL and FAST_RET can jump to.
Right now, I have:
https://github.com/derickr/vld/commit/9cf01bba0a1aeef6a261c6c85b238552215a9f0b#diff-286f7620179e1ee0a20e81523d91ff24R1036
+#if PHP_VERSION_ID >= 50500
+ } else if (opcode.opcode == ZEND_FAST_CALL) {
+#if PHP_VERSION_ID >= 7
+ *jmp1 = VLD_ZNODE_JMP_LINE(opcode.op1, position, base_address);
+#else
+ *jmp1 = ((long) VLD_ZNODE_ELEM(opcode.op1, jmp_addr) - (long)
base_address) / sizeof(zend_op);
+#endif
+ if (opcode.extended_value) {
+ *jmp2 = VLD_ZNODE_ELEM(opcode.op2, opline_num);
+ }
+ return 1;
+ } else if (opcode.opcode == ZEND_FAST_RET) {
+ *jmp1 = position + 1;
+ if (opcode.extended_value) {
+ *jmp2 = VLD_ZNODE_ELEM(opcode.op2, opline_num);
+ }
+ return 1;
+#endif
Which seems to work, although I am unsure about the "+ 1" for FAST_RET.
I also never see anything for opcode.extended_value, and hence the *jmp is
unset. This also returns dumping opcodes with this bit of code (code slightly
lifted from dbg):
https://github.com/derickr/vld/commit/9cf01bba0a1aeef6a261c6c85b238552215a9f0b#diff-286f7620179e1ee0a20e81523d91ff24R684
+#if PHP_VERSION_ID >= 50600
+ switch (op.opcode) {
+ case ZEND_FAST_RET:
+ if (op.extended_value == ZEND_FAST_RET_TO_FINALLY) {
+ fetch_type = "to_finally";
+ } else if (op.extended_value == ZEND_FAST_RET_TO_CATCH)
{
+ fetch_type = "to_catch";
+ }
+ break;
+ case ZEND_FAST_CALL:
+ if (op.extended_value == ZEND_FAST_CALL_FROM_FINALLY)
{
+ fetch_type = "from_finally";
+ }
+ break;
+ }
+#endif
+
Any hints?
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] What's up with gcov.php.net?
Hi everyone, If any of you have looked at http://gcov.php.net any time in the last three years, you'll probably have noticed an alarming and inexplicably high number of test failures. And if you've looked at Travis, you'll have seen much more reasonable numbers (i.e. usually zero). So, I'd like to ask, why does gcov.php.net always show such high numbers, and apparently has things that are fixed show up as broken, and secondly, since we use Travis for continuous integration these days, why is the box even still running? Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Better HashDos protection
Hey, some time ago we had a discussion about HashDos protection initiated by Nikita. There just was one major flaw that it still allowed to crash (fatal error) background processes with no chance to intercept these. Hence, an exception is thrown instead in array functions respectively (parse_str and json_decode) the function is properly failed. There still is a path reaching the fatal error, but it should never be reached under normal operation via external input, and if it does, then it should be fixed too. The pull request is found at https://github.com/php/php-src/pull/1706 This hopefully should eliminate this DoS vector completely. Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Number Format Separator
You mention no support for numeric strings, but how will settype($string, int|float), intval(), floatval(), is_numeric() and ctype_digit() work with this change? I do think if you don't change the semantics for strings to number conversion (which I agree you can't due to BC breaks) there should be an explicit way to support "1_000_000" => (int) 1_000_000. This should be part of the RFC. I presume that if you were to go from numeric to string the underscores would be stripped? What about a way not to do that? What will var_dump() etc. show? On Wed, Dec 30, 2015 at 5:26 PM, Thomas Punt wrote: > Hi internals! > > I'd like to propose for the inclusion of a digit separator in PHP. This > will > help to promote the readability of numerical literals in code by enabling > for > the underscore character to be used in between digits. > > RFC: https://wiki.php.net/rfc/number_format_separator > PR: https://github.com/php/php-src/pull/1699 > > Thanks, > Tom > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
[PHP-DEV] Re: Line numbers for "finally"
On Wed, Dec 30, 2015 at 8:55 PM, Derick Rethans wrote:
> Hi!
>
> While investigating an issue with Xdebug and fast_call/fast_ret, I
> noticed that the opcodes "associated" with the "finally" statement, are
> rolled up in the previous line.
>
> The code:
>
> 12 function extractFile()
> 3 {
> 4 try {
> 5 echo "try\n";
> 6 } catch (Catch1 $e) {
> 7 echo "catch1\n";
> 8 } catch (Catch2 $e) {
> 9 echo "catch2\n";
> 10 } finally {
> 11 echo "finally\n";
> 12 }
> 13 echo "end\n";
> 14 }
> 15
> 16 extractFile();
> 17 ?>
>
>
> Produces:
>
> line #* E I O op fetch ext return
> operands
>
> -
>5 0 E > ECHO
> 'try%0A'
> 1 > JMP
> ->7
>6 2 E > > CATCH
> 'Catch1', !0, ->5
>7 3> ECHO
> 'catch1%0A'
> 4 > JMP
> ->7
>8 5 E > > CATCH
> 'Catch2', !0
>9 6> ECHO
> 'catch2%0A'
> 7> > FAST_CALL
> ->9
> 8* JMP
> ->11
> 11 9> ECHO
> 'finally%0A'
> 10 > FAST_RET
> 1311> ECHO
> 'end%0A'
> 1412 > RETURN
> null
>
>
> The FAST_CALL/JMP instructions should really be linked to line 10. Not
> doing so produces confusing results while doing code coverage, where it now
> shows that the "echo catch2\n" on line 9 is executed. This is of course not
> the case, but the linking of FAST_CALL and JMP to line 9 makes it look like
> this. Is it possible to change this so thta the FAST_CALL and JMP are
> linked
> to line 10 instead?
>
Yeah, you're right. Should be fixed with
https://github.com/php/php-src/commit/b3afeeabefc4777ec4797a7e2c3688e9e20be4cc
.
> And secondly, I am struggeling with where FAST_CALL and FAST_RET can jump
> to.
> Right now, I have:
>
>
> https://github.com/derickr/vld/commit/9cf01bba0a1aeef6a261c6c85b238552215a9f0b#diff-286f7620179e1ee0a20e81523d91ff24R1036
>
> +#if PHP_VERSION_ID >= 50500
> + } else if (opcode.opcode == ZEND_FAST_CALL) {
> +#if PHP_VERSION_ID >= 7
> + *jmp1 = VLD_ZNODE_JMP_LINE(opcode.op1, position,
> base_address);
> +#else
> + *jmp1 = ((long) VLD_ZNODE_ELEM(opcode.op1, jmp_addr) -
> (long) base_address) / sizeof(zend_op);
> +#endif
> + if (opcode.extended_value) {
> + *jmp2 = VLD_ZNODE_ELEM(opcode.op2, opline_num);
> + }
> + return 1;
> + } else if (opcode.opcode == ZEND_FAST_RET) {
> + *jmp1 = position + 1;
> + if (opcode.extended_value) {
> + *jmp2 = VLD_ZNODE_ELEM(opcode.op2, opline_num);
> + }
> + return 1;
> +#endif
>
> Which seems to work, although I am unsure about the "+ 1" for FAST_RET.
>
For PHP 7 only: FAST_CALL always jumps to op1. op2 is not a jmp addr, it's
a try_catch_array offset. For FAST_RET there are no jump addresses encoded
in the opline. It will either jump back to one past the invoking FAST_CALL
(of which there may be multiple), or (if finally is executed due to an
uncaught exception) it will jump back to the next applicable catch or
finally or leave the function.
Nikita
> I also never see anything for opcode.extended_value, and hence the *jmp is
> unset. This also returns dumping opcodes with this bit of code (code
> slightly
> lifted from dbg):
>
>
> https://github.com/derickr/vld/commit/9cf01bba0a1aeef6a261c6c85b238552215a9f0b#diff-286f7620179e1ee0a20e81523d91ff24R684
>
> +#if PHP_VERSION_ID >= 50600
> + switch (op.opcode) {
> + case ZEND_FAST_RET:
> + if (op.extended_value == ZEND_FAST_RET_TO_FINALLY)
> {
> + fetch_type = "to_finally";
> + } else if (op.extended_value ==
> ZEND_FAST_RET_TO_CATCH) {
> + fetch_type = "to_catch";
> + }
> + break;
> + case ZEND_FAST_CALL:
> + if (op.extended_value ==
> ZEND_FAST_CALL_FROM_FINALLY)
> {
> + fetch_type = "from_finally";
> + }
> + break;
> + }
> +#endif
> +
>
> Any hints?
>
> cheers,
> Derick
> --
> http://derickrethans.nl | http://xdebug.org
> Like Xdebug? Consider a donation: http://xdebug.org/donate.php
> twitter: @derickr and @xdebug
> Posted with an email client that doesn't mangle email: alpine
>
Re: [PHP-DEV] [RFC] Number Format Separator
On Wed, Dec 30, 2015 at 11:00:55PM +, Davey Shafik wrote: > You mention no support for numeric strings, but how will settype($string, > int|float), intval(), floatval(), is_numeric() and ctype_digit() work with > this change? > > I do think if you don't change the semantics for strings to number > conversion (which I agree you can't due to BC breaks) there should be an > explicit way to support "1_000_000" => (int) 1_000_000. This should be part > of the RFC. > > I presume that if you were to go from numeric to string the underscores > would be stripped? What about a way not to do that? What will var_dump() > etc. show? I think that he is just talking about numeric constants in programs; he is not talking about run time strings (eg read from a file/form) being allowed to contain '_'. Perl does exactly what Thomas is proposing, it does improve readability. There is not a BC problem since today something like 1_000 is illegal as a constant in a program. I think that it is a good idea. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Testing HTTP/2 support in PHP
Hey all, In the PR for adding HTTP/2 Server Push support to curl, Julien raises the question of adding tests for this feature [1]. This is currently very difficult. While we have the cli-server, it currently only supports HTTP/1.x. This means we need another httpd to test against that supports both HTTP/2 and server push — currently that means something like a node script using node-http2, or nghttpd (both of which have been what I tested the patch against). While I have a docker container for testing, this obviously doesn't fit well into `make tests`. The simplest solution along those lines is to check for `node` and run a node daemon, but it doesn't scale well to lots of use cases, and is purely for testing. However, Rasmus raised the possibility of adding HTTP/2 support to the cli-server [2], and (someone? @php-pulls) suggested we pull in a third party lib to do the heavy lifting [3]. My recommendation would be to use libnghttp2 [4] which curl also uses — however, as this adds a new dependency, I think it should be optional (e.g. --with-nghttp2-dir=[PATH]), with it falling back to the current HTTP/1.x implementation. We could also add a flag (e.g. --[no-]http2) on the CLI for enabling/disabling it — this would be helpful for testing HTTP/2 client fallback when it's not supported. This is a much more useful tool than relying on node for make tests, and allows us to test adding HTTP/2 support to ext/curl, the HTTP stream (which could also use libnghttp2…), userland HTTP/2 clients, pecl_http (if that's still a thing), etc. Now, I don't think I have the ability to achieve this, but I'm willing to give it a go. At the very least, I'm more than happy to write up the RFC and work with someone on this. Thoughts? - Davey [1] https://github.com/php/php-src/pull/1692#issuecomment-166935246 [2] https://github.com/php/php-src/pull/1692#issuecomment-166972540 [3] https://github.com/php/php-src/pull/1692#issuecomment-166997465 [4] https://nghttp2.org
Re: [PHP-DEV] [RFC] Number Format Separator
On 30 December 2015 at 23:00, Davey Shafik wrote: > how will settype($string, int|float), intval(), floatval(), is_numeric() > and ctype_digit() work with this change? My understanding is that those functions will continue to work as they do currently. The numeric literals are resolved by the compiler into numbers when the code is compiled, so there will be no difference. i.e. this RFC does not affect PHP at runtime at all, only the compile step. > What will var_dump() etc. show? var_dump(1_000_000) will have the same output as var_dump(100) > there should be an explicit way to support "1_000_000" => (int) 1_000_000. > This > should be part of the RFC. I don't think it should be part of this RFC. That sounds like a completely different RFC, or is covered by NumberFormatter::parse(). cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Line numbers for "finally"
Hi!
On Thu, 31 Dec 2015, Nikita Popov wrote:
> On Wed, Dec 30, 2015 at 8:55 PM, Derick Rethans wrote:
>
> > While investigating an issue with Xdebug and fast_call/fast_ret, I
> > noticed that the opcodes "associated" with the "finally" statement, are
> > rolled up in the previous line.
> > The FAST_CALL/JMP instructions should really be linked to line 10.
> > Not doing so produces confusing results while doing code coverage,
> > where it now shows that the "echo catch2\n" on line 9 is executed.
> > This is of course not the case, but the linking of FAST_CALL and JMP
> > to line 9 makes it look like this. Is it possible to change this so
> > thta the FAST_CALL and JMP are linked to line 10 instead?
> >
>
> Yeah, you're right. Should be fixed with
> https://github.com/php/php-src/commit/b3afeeabefc4777ec4797a7e2c3688e9e20be4cc
>
> .
Thanks — I'll give that a shot tomorrow. Did you merge that to 7.0 too?
> > And secondly, I am struggeling with where FAST_CALL and FAST_RET can
> > jump to. Right now, I have:
> >
> > https://github.com/derickr/vld/commit/9cf01bba0a1aeef6a261c6c85b238552215a9f0b#diff-286f7620179e1ee0a20e81523d91ff24R1036
> >
> > +#if PHP_VERSION_ID >= 50500
> > + } else if (opcode.opcode == ZEND_FAST_CALL) {
> > +#if PHP_VERSION_ID >= 7
> > + *jmp1 = VLD_ZNODE_JMP_LINE(opcode.op1, position,
> > base_address);
> > +#else
> > + *jmp1 = ((long) VLD_ZNODE_ELEM(opcode.op1, jmp_addr) -
> > (long) base_address) / sizeof(zend_op);
> > +#endif
> > + if (opcode.extended_value) {
> > + *jmp2 = VLD_ZNODE_ELEM(opcode.op2, opline_num);
> > + }
> > + return 1;
> > + } else if (opcode.opcode == ZEND_FAST_RET) {
> > + *jmp1 = position + 1;
> > + if (opcode.extended_value) {
> > + *jmp2 = VLD_ZNODE_ELEM(opcode.op2, opline_num);
> > + }
> > + return 1;
> > +#endif
> >
> > Which seems to work, although I am unsure about the "+ 1" for FAST_RET.
> >
>
> For PHP 7 only: FAST_CALL always jumps to op1. op2 is not a jmp addr, it's
> a try_catch_array offset. For FAST_RET there are no jump addresses encoded
> in the opline. It will either jump back to one past the invoking FAST_CALL
> (of which there may be multiple), or (if finally is executed due to an
> uncaught exception) it will jump back to the next applicable catch or
> finally or leave the function.
Hmm, that's more complicated than I thought. How would I fix that code?
(PR welcome :D )
cheers,
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
