Re: [PHP-DEV] the experimental jit-branch is impressive

[li...@rhsoft.net]

Am 03.05.2017 um 05:37 schrieb Sara Golemon:

On Tue, May 2, 2017 at 10:19 PM, li...@rhsoft.net  wrote:

100% internal codebase without 3rd party libraries developed over the last
15 years and in the meantime 100% strict-types/typehints/return-types only
missing some commented nullable/void return types because i need to wait
with 7.1.x for another busy guy with some of his instances :-)


Would you mind running some numbers against "commodity
apps/frameworks" (e.g. Wordpress, ZendFramework, Laravel, etc...)  I
expect that will be far more telling (in a potentially positive way).
For example, HHVM performs best on "highly optimized code", which is
why it tends to look a bit tepid against PHP 7 when run on "normal"


sorry, all my setups have a lot of stuff in the config to kill stuff 
like wordpress/joomla/typo3 so nobody comes to the idea installing after 
that badly mainatined stuff on my machines (for our own CMS there is a 
deplyoment system maintaining 100, 200 or 1000 instances with s single 
shell command)



codebases (particularly WP, which is in many ways not JIT friendly).
I realize the proof of concept jit branch is probably missing quite a
bit of optimizations compared to where it will land, so it may not
make then same kind of difference, but hey... curiosity killed the
cat.


WP is not friendly to anything :-)

on the other hand i guess that more the code itself is bloatet the 
impact of performance improvements is bigger compared to my code where 
httpd and connection handling takes as long as the application while 20% 
of my runtime costs are database connections and queries which don't get 
faster in any case



the profiling system is our internal demo-system with every depolyable
module installed, runs the auto-testsuite inclduing refelection fuzzy-calls


Sounds very comprehensive and I'm glad you're using such a heavy
benchmarking suite. :D


well, it was more about "how do i feed 
https://software.intel.com/en-us/blogs/2015/10/09/pgo-let-it-go-php with 
as much as possible runtime informations" and later "how do i get that 
beast deployable again after rewrite the whole codebase to native PHP7 
with minimized fallout on type-errors"



so 5% is not that bad


Apologies if I gave the impression that I felt it was "bad".  My
expressed disappointment was only relative to the headline "ZOMGWTFBBQ
100% GAIN" headline (which I think most of us regarded as probably
wrong in some way due to the early-days nature of the jit branch). :)


yeah, i thought i start a party after the first result which maxed out 
at 4200/seconds after a few thousand requests on my workstation looking 
in the direction of the 12-core Xeon "and what will you do with that" :-)


what will be interesting with the JIT is how it benefits from newer CPU 
architectures, currently we optimize for sandybdrige, with next summer 
the cluster nodes will be replaced and the VMware EVC mode raised to 
skylake leading to maintain a different PHP PGP-build with -mtune=native


looking at "Use AVX instructions (if enabled and available)" 
https://github.com/zendtech/php-src/commit/d9474c784041745a455dd5be06b52c0029e40697 
there will be some space of improvement on both sides, the PHP binary 
itself as well as what code the JIT can prodcue at the end (skylake Xeon 
will intoduce AVX512 as example)


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

Re: [PHP-DEV] the experimental jit-branch is impressive

[Sara Golemon]

On Tue, May 2, 2017 at 10:19 PM, li...@rhsoft.net  wrote:
> 100% internal codebase without 3rd party libraries developed over the last
> 15 years and in the meantime 100% strict-types/typehints/return-types only
> missing some commented nullable/void return types because i need to wait
> with 7.1.x for another busy guy with some of his instances :-)
>
Would you mind running some numbers against "commodity
apps/frameworks" (e.g. Wordpress, ZendFramework, Laravel, etc...)  I
expect that will be far more telling (in a potentially positive way).
For example, HHVM performs best on "highly optimized code", which is
why it tends to look a bit tepid against PHP 7 when run on "normal"
codebases (particularly WP, which is in many ways not JIT friendly).
I realize the proof of concept jit branch is probably missing quite a
bit of optimizations compared to where it will land, so it may not
make then same kind of difference, but hey... curiosity killed the
cat.

> the profiling system is our internal demo-system with every depolyable
> module installed, runs the auto-testsuite inclduing refelection fuzzy-calls
>
Sounds very comprehensive and I'm glad you're using such a heavy
benchmarking suite. :D

> so 5% is not that bad
>
Apologies if I gave the impression that I felt it was "bad".  My
expressed disappointment was only relative to the headline "ZOMGWTFBBQ
100% GAIN" headline (which I think most of us regarded as probably
wrong in some way due to the early-days nature of the jit branch). :)

-Sara

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

Re: [PHP-DEV] the experimental jit-branch is impressive

[li...@rhsoft.net]

Am 03.05.2017 um 02:37 schrieb Sara Golemon:

On Tue, May 2, 2017 at 2:51 PM, li...@rhsoft.net  wrote:

OK, than it are "only" 5% on a highly optimized codebase


Awww... that makes me kinda sad to hear.  But perhaps with more work
that needle can be moved upwards.

One question which I didn't see answered (in my admittedly quick
scan): What codebase are you testing against?  Wordpress stock
install?


100% internal codebase without 3rd party libraries developed over the 
last 15 years and in the meantime 100% 
strict-types/typehints/return-types only missing some commented 
nullable/void return types because i need to wait with 7.1.x for another 
busy guy with some of his instances :-)


the profiling system is our internal demo-system with every depolyable 
module installed, runs the auto-testsuite inclduing refelection fuzzy-calls


* override config and switch to a clean database
* create 86 tables running the installer
* 60 unit tests (heavy sound on a RAID10 HDD system)
* 1200 reflection-fuzzy calls with random params to methdos
* calling every backend url with a configured admin user
* spider over 1600 frontend urls (curl, dom)
* controlled by a bash/php mix running also the intermediate CLI

that beast is highly optimized and the core-cms with just 4 navigation 
points and some lines of text has 12 function calls above 1% in xdebug :-)


well, the demo-install for profiling has magnitudes more running code

so 5% is not that bad - PHP 5.6 to 7.0 brought only 45% on that codebase 
while in the meantime the performance of the code got doubled at it's 
own (thanks xdebug) - hence someone heard my cry "WTF unbelievebale " 
after the first run not realize that the loaded xdebug without JIT makes 
most of the factor 2.5 difference while my epectation was 5-10% if any 
measureable improvement at all


http://corecms.thelounge.net/show_content.php?sid=2
0.0027 / 0.0013 - cuurently running on 7.0.18

0.0027: Header always set "X-Response-Time""%D us"
0.0013: microtime(true) first line versus microtime(true) final
__

3500 requests/second with 7.2-JIT on a 4-core i7 versus 4500/second with 
7.8.18 on a 12-core Xeon tells me that PHP itself is only some part of 
the runtime of the ab-benchmark given that "ab" on my testmachine eats 
nearly one of the 4 cores at it's own and even under 100% load generate 
times in the browser stays below 0.01 seconds

__

250 sequentiell curl requests parsing the "X-Response-Time" average with 
identical content


DYNAMIC CMS: 2382 us
STATIC HTM:  242 us
STATIC PHP:  288 us

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

Re: [PHP-DEV] [RFC] concept: further improvement of filter extension, "generalising" filter definitons while adding new callback filter type

[Martin "eto" Misuth]

On Fri, 28 Apr 2017 11:06:10 +0100
Dan Ackroyd  wrote:

> On 28 April 2017 at 03:49, Martin "eto" Misuth  wrote:
> 
> > would make maintaining such library much easier  
> 
> No. Maintaining stuff in PHP core is much more difficult than
> maintaining it in userland. 'Maintaining' doesn't just mean fixing
> bugs, it includes thinking about how any changes to APIs get rolled
> out to users, while minimising BC problems, and keeping code
> up-to-date with the PHP engine.
Got it. So this is to minimize php team maintenaince burden. Makes sense.
 
> These things are much easier to do in userland than they are in PHP core.
> 
> > It would be immensely valuable to me, if we could have filter extension
> > just intelligent enough, that it would process all request data
> > according to template, from each input source in succession, **on it's
> > own**, **in one go**  
> 
> While I can see that could be useful to you the question, again, is
> why can't this be done in userland?
Understood. Still, from my point of view, filter is missing tiny nudges that
have to be done on module side. 

> > Even if I store "form definition" arrays in some memory cache (I tried apcu
> > and ramdisk), so that their instantiation is relatively quick,  
> 
> If you want data/code to be retrieved very quickly, I'd recommend
> generating PHP code, and then letting OPCache, cache that code, as
> well as possibly use a classloader that is a good fit for your use
> case, like this one: https://github.com/Danack/LowMemoryClassloader/
> rather than a generic classloader. It loads classes that are already
> present in OPCache with zero system calls.
Thank you, I will investigate that suggestion as well.
 
> Well, that sounds like a real problem, but it's really not obvious how
> your RFC would solve that problem.
I believe, my approach provides scaffolding, that will allow filter to 
be extended later, to advance through definition arrays on it's own, 
without need to wrap initial "walk" of definition array, into userland
"iterators" (functions that unpack data from custom definition arrays 
and transform them into form suitable for filter consumption). 

> To be honest, I kind of faded out in the middle, but I'm back now.
> 
> You might want to consider the phrase "I'm sorry I wrote you such a
> long letter; I didn't have time to write a short one". This list is
> distributed to thousands of people. Spending some time editing your
> email down to a concise one, makes it much more likely to be read.
> Also, it's disappointing that you wrote so many words, but didn't
> (imho) actually answer why this needs to be in core rather than a
> userland library.

This might sound like void excuse, but I projected my personal experience
with new hires (who all left after very short time working with our codebase) 
onto you. After observing that several time, I came to understand, our
system is "shomehow weird" and needs thorough explanation. I had to explain 
the system again and again, and got caught up in this loop. I will refrain from
ever doing this again, from now on. 

> If it _really_ can't be done in userland, then possibly writing it as
> a PECL extension would be a good way to prove that it is a useful
> thing that other people would want to use, as well as being a good way
> of iterating the API until it fits everyone's use-cases, rather than
> hoping to get the API correct on the first version in PHP core.

Can I interpret that paragraph this way:
- it's okay for me to take ext/filter with my modifications 
  (even though they modify only part of the extension) 
- and publish them somewhere else (like github for example)
- while refining the api further to be "perfect"
- while adding intended usecases and examples
- and only after that ask for evaluation by others and attempt RFC again

1. Correct?

If yes, there is one thing I don't know what to do about, and need your advice.

2. What about module name clash?

I would prefer, for this alternative module, to be named filter as well 
(as there is intent to get modifications back into core, eventually). 

Or it's should I go and rename thing to something like filteri ("filter
improved") or filtero ("filter other"), even though big parts of code are
original filter still? I would like to avoid doing that.

> cheers
> Dan
Thank you for your advice.

> p.s.
> 
> > I am reminding this is happening on "ouput" side of things, where there is
> > no reason to burn cycles in generating markup, unless form is completely
> > validated (for confirmation display).  
> 
> It's hard to know for sure, without seeing your actual code, but this
> also sounds like a problem that varnish cache, with edge side includes
> is designed solve.
Ah, well form pages are "static" (aka first client render). Form handlers
that actually deal with dynamic part of those forms, and are tied to "private"
user sessions. I fail to see, how can I reliably and securely cache those, if

Re: [PHP-DEV] the experimental jit-branch is impressive

[Sara Golemon]

On Tue, May 2, 2017 at 2:51 PM, li...@rhsoft.net  wrote:
> OK, than it are "only" 5% on a highly optimized codebase
>
Awww... that makes me kinda sad to hear.  But perhaps with more work
that needle can be moved upwards.

One question which I didn't see answered (in my admittedly quick
scan): What codebase are you testing against?  Wordpress stock
install?

-Sara

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

Re: [PHP-DEV] RFC karma?

[Hannes Magnusson]

I've added that user to the rfc group.

I've also added you to the wiki admin group.

-Hannes


On Tue, Mar 21, 2017 at 9:29 PM, Sara Golemon  wrote:

> The author of https://github.com/php/php-src/pull/1927 wants RFC karma
> to propose some dynamic variable enhancements.  Could someone with
> karma karma help them out?
>
> -Sara
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] BAD Benchmark Results for PHP Master 2017-05-01

[lp_benchmark_robot]

Results for project PHP master, build date 2017-05-01 19:25:50-07:00
commit: c0e9c21
previous commit:2bce801
revision date:  2017-05-01 18:07:05+02: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.32%  0.87%  
  7.04%
:-|   Drupal 7.36 cgi -T1  0.18% -0.12%  0.32%  
  4.23%
:-|   MediaWiki 1.23.9 cgi -T5000  0.14%  0.00%  1.54%  
  3.22%
:-(   bench.php cgi -T100  0.10% -2.22% 36.81%  
  0.17%
:-(  micro_bench.php cgi -T10  0.01% -5.60% 10.45%  
  5.40%
:-(  mandelbrot.php cgi -T100  0.16% -8.27% 29.58%  
  4.03%
---

* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/bad-benchmark-results-for-php-master-2017-05-01/

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] Re: [Discussion] Dots and spaces in GPC variable names

[Andrea Faulds]

Hey Andrey,

Andrey Andreev wrote:

I'm not surprised by the suggestion for targeting 8.0, but perhaps we
could think of a way to conditionally disable the mangling in 7.x and
then remove it entirely in 8?
I hate to say INI directives, but that's surely one way for a smoother
transition.


Another approach I'd previously thought of was to keep in memory 
whatever information would be needed to undo the mangling process for 
the superglobals, and provide a function which would undo it. Then in 
8.x it could become a no-op.


That wouldn't really help for parse_str, though. But for that function 
it could just be a flag.


Thanks for bringing this up again!

--
Andrea Faulds
https://ajf.me/

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

Re: [PHP-DEV] the experimental jit-branch is impressive

[li...@rhsoft.net]

Am 02.05.2017 um 21:12 schrieb Nikita Popov:
On Tue, May 2, 2017 at 9:04 PM, li...@rhsoft.net 


You have xdebug enabled...


loaded, but not enabled

xdebug.default_enable = 0
xdebug.profiler_enable = 0
xdebug.profiler_enable_trigger = 1

7.1.5: Requests per second: 136.46
7.1.5 opcache: Requests per second: 316.77
7.2.0 JIT PGO: Requests per second: 925.96
7.2.0 JIT NON-PGO: Requests per second: 849.99

around 8% are the difference with or without PGO, no idea how much
strict-types and a 100% typehinted codebase makes a difference to
the JIT operations

This is a common misconception. If you have loaded xdebug you will incur 
a major performance hit, regardless of ini settings. 
xdebug.default_enable is a badly named option, which controls display of 
stack traces, not whether xdebug is enabled. As far as I know, there is 
no way to disable xdebug once it has been loaded.


Please unload xdebug and try again


argh - when the trigger is set to generate profiling files runtime is 
doubled compared with xdebug just loaded but indeed xdebug has a massive 
impact


7.1.5 PGO: Requests per second: 886.63
7.2.0 JIT PGO: Requests per second: 925.96

OK, than it are "only" 5% on a highly optimized codebase

interesting is the impact of PGO-profiling which has likely a 
code-coverage nearly to 95% and that without xdebug our cms-system seems 
to be that efficient that it nearly runs as fast on a quad-core i7 from 
2011 than on a 12-core Xeon from 2015.


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

[PHP-DEV] Re: [Discussion] Dots and spaces in GPC variable names

[Andrey Andreev]

Hi,

On Tue, May 2, 2017 at 5:07 PM, Christoph M. Becker  wrote:
> On 02.05.2017 at 12:56, Andrey Andreev wrote:
>
>> With parse_str() usage without a second parameter being deprecated, I
>> was looking to possibly drop the behavior where it replaces spaces and
>> dots with underscores in the result array, and ... As it often turns
>> out - it's not that simple, because it re-uses the code that handles
>> GPC vars.
>>
>> I didn't even know this mangling happened with GPC vars. I can only
>> assume that's legacy from the the register_global days, as I certainly
>> don't see a reason for it now. Am I missing something?
>>
>> And more importantly, can we change that? It's a significant BC break,
>> yes, but the current behavior is horribly broken IMO.
>
> This issue has been already brought to the list quite a while ago[1].
> IMHO, the big problem is the subtle BC break.
>
> [1] 
>

Thanks for linking that. It's encouraging as I'd expect a previous
discussion to have gathered mostly negative opinions due to the BC
break.

That old thread is from just the time when 7.0 was supposed to be
released, so it was certainly an opportunity missed by a few months.
I'm not surprised by the suggestion for targeting 8.0, but perhaps we
could think of a way to conditionally disable the mangling in 7.x and
then remove it entirely in 8?
I hate to say INI directives, but that's surely one way for a smoother
transition.

Cheers,
Andrey.

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

Re: [PHP-DEV] the experimental jit-branch is impressive

[Nikita Popov]

On Tue, May 2, 2017 at 9:04 PM, li...@rhsoft.net  wrote:

>
> Am 02.05.2017 um 20:53 schrieb Nikita Popov:
>
>> These results are very unlikely. I'm 95% sure your benchmark is
>> broken. My first guess would be that you're benchmarking PHP +
>> JIT against PHP without opcache. Please share the relevant
>> (opcache-related) portion of the php.inis you used
>>
>> no they are not - since i build RPM packages and even the whole
>> spec-file is unchanged, only the tarball changed and the build is
>> highly optimized i can assure you for 100% that i compare PHP
>> 7.1.5RC1 with https://github.com/zendtech/php-src
>>  downloaded today
>>
>> maybe the PGO-profiling running autotests and fuzzy-calls on the
>> whole application as well as 2000 cms-requests combined with the
>> compiler flags improves the JIT itself
>>
>> without opcache the results for 7.1.5 are *dramatically* slower
>>
>> and i repeated the test upgrade/downgrade packages and run "ab"
>> multiple times on that machine - attached the "php.spec" which is
>> used for the build
>>
>> in just downloaded the zip from https://github.com/zendtech/php-src
>> , renamed it to "php-7.2.0",
>> made a tar.xz archive, changed the version on teh frist line in the
>> spec file and fired the build/profiling - nothing else changed
>>
> >
>
>> You have xdebug enabled...
>>
>
> loaded, but not enabled
>
> xdebug.default_enable = 0
> xdebug.profiler_enable = 0
> xdebug.profiler_enable_trigger = 1
>
> 7.1.5: Requests per second: 136.46
> 7.1.5 opcache: Requests per second: 316.77
> 7.2.0 JIT PGO: Requests per second: 925.96
> 7.2.0 JIT NON-PGO: Requests per second: 849.99
>
> around 8% are the difference with or without PGO, no idea how much
> strict-types and a 100% typehinted codebase makes a difference to the JIT
> operations
>

This is a common misconception. If you have loaded xdebug you will incur a
major performance hit, regardless of ini settings. xdebug.default_enable is
a badly named option, which controls display of stack traces, not whether
xdebug is enabled. As far as I know, there is no way to disable xdebug once
it has been loaded.

Please unload xdebug and try again.

Nikita

Re: [PHP-DEV] the experimental jit-branch is impressive

[li...@rhsoft.net]

Am 02.05.2017 um 20:53 schrieb Nikita Popov:

These results are very unlikely. I'm 95% sure your benchmark is
broken. My first guess would be that you're benchmarking PHP +
JIT against PHP without opcache. Please share the relevant
(opcache-related) portion of the php.inis you used

no they are not - since i build RPM packages and even the whole
spec-file is unchanged, only the tarball changed and the build is
highly optimized i can assure you for 100% that i compare PHP
7.1.5RC1 with https://github.com/zendtech/php-src
 downloaded today

maybe the PGO-profiling running autotests and fuzzy-calls on the
whole application as well as 2000 cms-requests combined with the
compiler flags improves the JIT itself

without opcache the results for 7.1.5 are *dramatically* slower

and i repeated the test upgrade/downgrade packages and run "ab"
multiple times on that machine - attached the "php.spec" which is
used for the build

in just downloaded the zip from https://github.com/zendtech/php-src
, renamed it to "php-7.2.0",
made a tar.xz archive, changed the version on teh frist line in the
spec file and fired the build/profiling - nothing else changed

>

You have xdebug enabled...


loaded, but not enabled

xdebug.default_enable = 0
xdebug.profiler_enable = 0
xdebug.profiler_enable_trigger = 1

7.1.5: Requests per second: 136.46
7.1.5 opcache: Requests per second: 316.77
7.2.0 JIT PGO: Requests per second: 925.96
7.2.0 JIT NON-PGO: Requests per second: 849.99

around 8% are the difference with or without PGO, no idea how much 
strict-types and a 100% typehinted codebase makes a difference to the 
JIT operations




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

Re: [PHP-DEV] the experimental jit-branch is impressive

[Nikita Popov]

On Tue, May 2, 2017 at 8:12 PM, li...@rhsoft.net  wrote:

>
>
> Am 02.05.2017 um 20:02 schrieb Nikita Popov:
>
>> On Tue, May 2, 2017 at 7:14 PM, li...@rhsoft.net 
>> > wrote:
>>
>> and with a demo-page containing all sort of modules and bloat the
>> difference is even greater - can't wait to see that in production
>>
>> is there anything known when it is expected to arrive in the
>> official tree or does Zend even hold it back until the point when
>> they can suprise with a "we are done, all tests are fine and we can
>> merge it" announce?
>>
>> PHP 7.1:
>> Requests per second: 316.77 [#/sec] (mean)
>> Time per request: 157.844 [ms] (mean)
>> Time per request: 3.157 [ms] (mean, across all concurrent requests)
>> Transfer rate: 12604.11 [Kbytes/sec] received
>>
>> PHP 7.2 JIT:
>> Requests per second: 925.96 [#/sec] (mean)
>> Time per request: 53.998 [ms] (mean)
>> Time per request: 1.080 [ms] (mean, across all concurrent requests)
>> Transfer rate: 36842.68 [Kbytes/sec] received
>>
>> These results are very unlikely. I'm 95% sure your benchmark is broken.
>> My first guess would be that you're benchmarking PHP + JIT against PHP
>> without opcache. Please share the relevant (opcache-related) portion of the
>> php.inis you used
>>
>
> no they are not - since i build RPM packages and even the whole spec-file
> is unchanged, only the tarball changed and the build is highly optimized i
> can assure you for 100% that i compare PHP 7.1.5RC1 with
> https://github.com/zendtech/php-src downloaded today
>
> maybe the PGO-profiling running autotests and fuzzy-calls on the whole
> application as well as 2000 cms-requests combined with the compiler flags
> improves the JIT itself
>
> without opcache the results for 7.1.5 are *dramatically* slower
>
> and i repeated the test upgrade/downgrade packages and run "ab" multiple
> times on that machine - attached the "php.spec" which is used for the build
>
> in just downloaded the zip from https://github.com/zendtech/php-src,
> renamed it to "php-7.2.0", made a tar.xz archive, changed the version on
> teh frist line in the spec file and fired the build/profiling - nothing
> else changed
> ___
>
> phpinfo() of the test machine
>
> PHP Version 7.1.5RC1
> Build Date May 2 2017 12:19:59
>
> This program makes use of the Zend Scripting Language Engine: Zend Engine
> v3.1.0, Copyright  (c)  1998-2017  Zend  Technologies with  Zend  OPcache
> v7.1.5RC1, Copyright  (c)  1999-2017, by  Zend  Technologies with  Xdebug
> v2.5.3, Copyright  (c)  2002-2017, by  Derick  Rethans
>
> Directive   Local Value Master Value
> opcache.blacklist_filename  no valueno value
> opcache.consistency_checks  0   0
> opcache.dups_fixOff Off
> opcache.enable  On  On
> opcache.enable_cli  Off Off
> opcache.enable_file_overrideOn  On
> opcache.error_log   /var/log/php_error.log  /var/log/php_error.log
> opcache.fast_shutdown   1   1
> opcache.file_update_protection  2   2
> opcache.force_restart_timeout   180 180
> opcache.huge_code_pages On  On
> opcache.inherited_hack  On  On
> opcache.interned_strings_buffer 8   8
> opcache.lockfile_path   /tmp/tmp
> opcache.log_verbosity_level 1   1
> opcache.max_accelerated_files   10001000
> opcache.max_file_size   327680  327680
> opcache.max_wasted_percentage   5   5
> opcache.memory_consumption  128 128
> opcache.opt_debug_level 0   0
> opcache.optimization_level  0x7FFFBFFF  0x7FFFBFFF
> opcache.preferred_memory_model  no valueno value
> opcache.protect_memory  0   0
> opcache.restrict_api/usr/share/php/zendoptimizer.php
> /usr/share/php/zendoptimizer.php
> opcache.revalidate_freq 5   5
> opcache.revalidate_path Off Off
> opcache.save_comments   0   0
> opcache.use_cwd On  On
> opcache.validate_permission Off Off
> opcache.validate_root   Off Off
> opcache.validate_timestamps On
>

You have xdebug enabled...

Re: [PHP-DEV] the experimental jit-branch is impressive

[li...@rhsoft.net]

and BTW: for the 7.2.0 build i have not built pecl-extensions so the 
application is runnign witout APCu which means loading a single template 
in a core-cms-setup takes 1.6% versus 0.06% of the whole page


maybe one missing relevant information:

* no 3rd party code and micro-optimized to death over months
* 100% declare(strict_types=1); after some months of works
* 99.9% of all functions are using type-hints for all params

could be that the JIT has some benefit from that combined with the 
PGP-profiling and heavily CPU optimizations - i will give it a try and 
leave out the PGO-profiling and compare if the gain stays similar


Am 02.05.2017 um 20:21 schrieb li...@rhsoft.net:

that would be the numbers of 7.1.5RC1 *without* opcache

Requests per second:136.46 [#/sec] (mean)
Time per request:   366.405 [ms] (mean)
Time per request:   7.328 [ms] (mean, across all concurrent requests)
Transfer rate:  5429.78 [Kbytes/sec] received

7.1.5: Requests per second: 136.46
7.1.5 opcache: Requests per second: 316.77
7.2.0 JIT: Requests per second: 925.96

same hardware, same scripts, httpd hard restarted
ab -c 50 -n 2

believe it or not - i know my php environemt and what i benchmark :-)

Am 02.05.2017 um 20:12 schrieb li...@rhsoft.net:

Am 02.05.2017 um 20:02 schrieb Nikita Popov:
On Tue, May 2, 2017 at 7:14 PM, li...@rhsoft.net 
 > wrote:


and with a demo-page containing all sort of modules and bloat the
difference is even greater - can't wait to see that in production

is there anything known when it is expected to arrive in the
official tree or does Zend even hold it back until the point when
they can suprise with a "we are done, all tests are fine and we can
merge it" announce?

PHP 7.1:
Requests per second: 316.77 [#/sec] (mean)
Time per request: 157.844 [ms] (mean)
Time per request: 3.157 [ms] (mean, across all concurrent requests)
Transfer rate: 12604.11 [Kbytes/sec] received

PHP 7.2 JIT:
Requests per second: 925.96 [#/sec] (mean)
Time per request: 53.998 [ms] (mean)
Time per request: 1.080 [ms] (mean, across all concurrent requests)
Transfer rate: 36842.68 [Kbytes/sec] received

These results are very unlikely. I'm 95% sure your benchmark is 
broken. My first guess would be that you're benchmarking PHP + JIT 
against PHP without opcache. Please share the relevant 
(opcache-related) portion of the php.inis you used


no they are not - since i build RPM packages and even the whole 
spec-file is unchanged, only the tarball changed and the build is 
highly optimized i can assure you for 100% that i compare PHP 7.1.5RC1 
with https://github.com/zendtech/php-src downloaded today


maybe the PGO-profiling running autotests and fuzzy-calls on the whole 
application as well as 2000 cms-requests combined with the compiler 
flags improves the JIT itself


without opcache the results for 7.1.5 are *dramatically* slower

and i repeated the test upgrade/downgrade packages and run "ab" 
multiple times on that machine - attached the "php.spec" which is used 
for the build


in just downloaded the zip from https://github.com/zendtech/php-src, 
renamed it to "php-7.2.0", made a tar.xz archive, changed the version 
on teh frist line in the spec file and fired the build/profiling - 
nothing else changed

___

phpinfo() of the test machine

PHP Version 7.1.5RC1
Build Date May 2 2017 12:19:59

This program makes use of the Zend Scripting Language Engine: Zend 
Engine  v3.1.0, Copyright  (c)  1998-2017  Zend  Technologies with  
Zend   OPcache  v7.1.5RC1, Copyright  (c)  1999-2017, by  Zend  
Technologies with  Xdebug  v2.5.3, Copyright  (c)  2002-2017, by  
Derick  Rethans


DirectiveLocal ValueMaster Value
opcache.blacklist_filenameno valueno value
opcache.consistency_checks00
opcache.dups_fixOffOff
opcache.enableOnOn
opcache.enable_cliOffOff
opcache.enable_file_overrideOnOn
opcache.error_log/var/log/php_error.log/var/log/php_error.log
opcache.fast_shutdown11
opcache.file_update_protection22
opcache.force_restart_timeout180180
opcache.huge_code_pagesOnOn
opcache.inherited_hackOnOn
opcache.interned_strings_buffer88
opcache.lockfile_path/tmp/tmp
opcache.log_verbosity_level11
opcache.max_accelerated_files10001000
opcache.max_file_size327680327680
opcache.max_wasted_percentage55
opcache.memory_consumption128128
opcache.opt_debug_level00
opcache.optimization_level0x7FFFBFFF0x7FFFBFFF
opcache.preferred_memory_modelno valueno value
opcache.protect_memory00
opcache.restrict_api/usr/share/php/zendoptimizer.php 
/usr/share/php/zendoptimizer.php

opcache.revalidate_freq55
opcache.revalidate_pathOffOff

Re: [PHP-DEV] the experimental jit-branch is impressive

[li...@rhsoft.net]

that would be the numbers of 7.1.5RC1 *without* opcache

Requests per second:136.46 [#/sec] (mean)
Time per request:   366.405 [ms] (mean)
Time per request:   7.328 [ms] (mean, across all concurrent requests)
Transfer rate:  5429.78 [Kbytes/sec] received

7.1.5: Requests per second: 136.46
7.1.5 opcache: Requests per second: 316.77
7.2.0 JIT: Requests per second: 925.96

same hardware, same scripts, httpd hard restarted
ab -c 50 -n 2

believe it or not - i know my php environemt and what i benchmark :-)

Am 02.05.2017 um 20:12 schrieb li...@rhsoft.net:

Am 02.05.2017 um 20:02 schrieb Nikita Popov:
On Tue, May 2, 2017 at 7:14 PM, li...@rhsoft.net 
 > 
wrote:


and with a demo-page containing all sort of modules and bloat the
difference is even greater - can't wait to see that in production

is there anything known when it is expected to arrive in the
official tree or does Zend even hold it back until the point when
they can suprise with a "we are done, all tests are fine and we can
merge it" announce?

PHP 7.1:
Requests per second: 316.77 [#/sec] (mean)
Time per request: 157.844 [ms] (mean)
Time per request: 3.157 [ms] (mean, across all concurrent requests)
Transfer rate: 12604.11 [Kbytes/sec] received

PHP 7.2 JIT:
Requests per second: 925.96 [#/sec] (mean)
Time per request: 53.998 [ms] (mean)
Time per request: 1.080 [ms] (mean, across all concurrent requests)
Transfer rate: 36842.68 [Kbytes/sec] received

These results are very unlikely. I'm 95% sure your benchmark is 
broken. My first guess would be that you're benchmarking PHP + JIT 
against PHP without opcache. Please share the relevant 
(opcache-related) portion of the php.inis you used


no they are not - since i build RPM packages and even the whole 
spec-file is unchanged, only the tarball changed and the build is highly 
optimized i can assure you for 100% that i compare PHP 7.1.5RC1 with 
https://github.com/zendtech/php-src downloaded today


maybe the PGO-profiling running autotests and fuzzy-calls on the whole 
application as well as 2000 cms-requests combined with the compiler 
flags improves the JIT itself


without opcache the results for 7.1.5 are *dramatically* slower

and i repeated the test upgrade/downgrade packages and run "ab" multiple 
times on that machine - attached the "php.spec" which is used for the build


in just downloaded the zip from https://github.com/zendtech/php-src, 
renamed it to "php-7.2.0", made a tar.xz archive, changed the version on 
teh frist line in the spec file and fired the build/profiling - nothing 
else changed

___

phpinfo() of the test machine

PHP Version 7.1.5RC1
Build Date May 2 2017 12:19:59

This program makes use of the Zend Scripting Language Engine: Zend 
Engine  v3.1.0, Copyright  (c)  1998-2017  Zend  Technologies with  Zend 
  OPcache  v7.1.5RC1, Copyright  (c)  1999-2017, by  Zend  Technologies 
with  Xdebug  v2.5.3, Copyright  (c)  2002-2017, by  Derick  Rethans


DirectiveLocal ValueMaster Value
opcache.blacklist_filenameno valueno value
opcache.consistency_checks00
opcache.dups_fixOffOff
opcache.enableOnOn
opcache.enable_cliOffOff
opcache.enable_file_overrideOnOn
opcache.error_log/var/log/php_error.log/var/log/php_error.log
opcache.fast_shutdown11
opcache.file_update_protection22
opcache.force_restart_timeout180180
opcache.huge_code_pagesOnOn
opcache.inherited_hackOnOn
opcache.interned_strings_buffer88
opcache.lockfile_path/tmp/tmp
opcache.log_verbosity_level11
opcache.max_accelerated_files10001000
opcache.max_file_size327680327680
opcache.max_wasted_percentage55
opcache.memory_consumption128128
opcache.opt_debug_level00
opcache.optimization_level0x7FFFBFFF0x7FFFBFFF
opcache.preferred_memory_modelno valueno value
opcache.protect_memory00
opcache.restrict_api/usr/share/php/zendoptimizer.php 
/usr/share/php/zendoptimizer.php

opcache.revalidate_freq55
opcache.revalidate_pathOffOff
opcache.save_comments00
opcache.use_cwdOnOn
opcache.validate_permissionOffOff
opcache.validate_rootOffOff
opcache.validate_timestampsOn



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

Re: [PHP-DEV] the experimental jit-branch is impressive

[li...@rhsoft.net]

Am 02.05.2017 um 20:02 schrieb Nikita Popov:
On Tue, May 2, 2017 at 7:14 PM, li...@rhsoft.net 
 > 
wrote:


and with a demo-page containing all sort of modules and bloat the
difference is even greater - can't wait to see that in production

is there anything known when it is expected to arrive in the
official tree or does Zend even hold it back until the point when
they can suprise with a "we are done, all tests are fine and we can
merge it" announce?

PHP 7.1:
Requests per second: 316.77 [#/sec] (mean)
Time per request: 157.844 [ms] (mean)
Time per request: 3.157 [ms] (mean, across all concurrent requests)
Transfer rate: 12604.11 [Kbytes/sec] received

PHP 7.2 JIT:
Requests per second: 925.96 [#/sec] (mean)
Time per request: 53.998 [ms] (mean)
Time per request: 1.080 [ms] (mean, across all concurrent requests)
Transfer rate: 36842.68 [Kbytes/sec] received

These results are very unlikely. I'm 95% sure your benchmark is broken. 
My first guess would be that you're benchmarking PHP + JIT against PHP 
without opcache. Please share the relevant (opcache-related) portion of 
the php.inis you used


no they are not - since i build RPM packages and even the whole 
spec-file is unchanged, only the tarball changed and the build is highly 
optimized i can assure you for 100% that i compare PHP 7.1.5RC1 with 
https://github.com/zendtech/php-src downloaded today


maybe the PGO-profiling running autotests and fuzzy-calls on the whole 
application as well as 2000 cms-requests combined with the compiler 
flags improves the JIT itself


without opcache the results for 7.1.5 are *dramatically* slower

and i repeated the test upgrade/downgrade packages and run "ab" multiple 
times on that machine - attached the "php.spec" which is used for the build


in just downloaded the zip from https://github.com/zendtech/php-src, 
renamed it to "php-7.2.0", made a tar.xz archive, changed the version on 
teh frist line in the spec file and fired the build/profiling - nothing 
else changed

___

phpinfo() of the test machine

PHP Version 7.1.5RC1
Build Date May 2 2017 12:19:59

This program makes use of the Zend Scripting Language Engine: Zend 
Engine  v3.1.0, Copyright  (c)  1998-2017  Zend  Technologies with  Zend 
 OPcache  v7.1.5RC1, Copyright  (c)  1999-2017, by  Zend  Technologies 
with  Xdebug  v2.5.3, Copyright  (c)  2002-2017, by  Derick  Rethans


Directive   Local Value Master Value
opcache.blacklist_filename  no valueno value
opcache.consistency_checks  0   0
opcache.dups_fixOff Off
opcache.enable  On  On
opcache.enable_cli  Off Off
opcache.enable_file_overrideOn  On
opcache.error_log   /var/log/php_error.log  /var/log/php_error.log
opcache.fast_shutdown   1   1
opcache.file_update_protection  2   2
opcache.force_restart_timeout   180 180
opcache.huge_code_pages On  On
opcache.inherited_hack  On  On
opcache.interned_strings_buffer 8   8
opcache.lockfile_path   /tmp/tmp
opcache.log_verbosity_level 1   1
opcache.max_accelerated_files   10001000
opcache.max_file_size   327680  327680
opcache.max_wasted_percentage   5   5
opcache.memory_consumption  128 128
opcache.opt_debug_level 0   0
opcache.optimization_level  0x7FFFBFFF  0x7FFFBFFF
opcache.preferred_memory_model  no valueno value
opcache.protect_memory  0   0
opcache.restrict_api	/usr/share/php/zendoptimizer.php 
/usr/share/php/zendoptimizer.php

opcache.revalidate_freq 5   5
opcache.revalidate_path Off Off
opcache.save_comments   0   0
opcache.use_cwd On  On
opcache.validate_permission Off Off
opcache.validate_root   Off Off
opcache.validate_timestamps On
___
Version: 7.1.5

# command 'rpmbuild -bb php.spec --with production' will tune for current hardware while default stays 'sandybridge'
# macro 'php_debug_build' is global (/home/builduser/.rpmmacros) and re-used for pecl-builds while 'debug_build' is local

%global dist  fc%fedora.%(echo $(/usr/bin/date +%Y%m%d.%H%M)).rh
%global phpver7
%global runselftest   0
%global pgo_build 1
%global lto_build 0
%global break_build   0
%global debug_build   0
%global extension_dir %{_libdir}/%{name}/modules

%if %{?_with_production:1}%{!?_with_production:0}
 %global mtune native
 %global rpmsuffix native
 %global php_native_release 1
%else
 %global mtune sandybridge
 %global rpmsuffix sandybridge
 %global php_native_release 0
%endif

%if %php_debug_build
 %global _include_minidebuginfo 1
 %global RH_GCC_DEBUG_OPTION -g3
 %global RH_CONFIGURE_DEBUG_OPTION enable-debug
 %global RH_STRIP_BINARY 0
 %global pgo_build 0
 %global lto_build 0
%else
 %if %debug_build
  %global _include_minidebuginfo 1
  %global 

Re: [PHP-DEV] the experimental jit-branch is impressive

[Nikita Popov]

On Tue, May 2, 2017 at 7:14 PM, li...@rhsoft.net  wrote:

> and with a demo-page containing all sort of modules and bloat the
> difference is even greater - can't wait to see that in production
>
> is there anything known when it is expected to arrive in the official tree
> or does Zend even hold it back until the point when they can suprise with a
> "we are done, all tests are fine and we can merge it" announce?
>
> PHP 7.1:
> Requests per second: 316.77 [#/sec] (mean)
> Time per request: 157.844 [ms] (mean)
> Time per request: 3.157 [ms] (mean, across all concurrent requests)
> Transfer rate: 12604.11 [Kbytes/sec] received
>
> PHP 7.2 JIT:
> Requests per second: 925.96 [#/sec] (mean)
> Time per request: 53.998 [ms] (mean)
> Time per request: 1.080 [ms] (mean, across all concurrent requests)
> Transfer rate: 36842.68 [Kbytes/sec] received


These results are very unlikely. I'm 95% sure your benchmark is broken. My
first guess would be that you're benchmarking PHP + JIT against PHP without
opcache. Please share the relevant (opcache-related) portion of the
php.inis you used.

Nikita


> Am 02.05.2017 um 18:00 schrieb li...@rhsoft.net:
>
>> https://github.com/zendtech/php-src/tree/jit-dynasm/ext/opcache/jit
>>
>> that below is a "ab -c 50 -n 10" on a Intel(R) Core(TM) i7-3770 CPU @
>> 3.40GHz on our core cms (pgo-build with heavy compiler optimizations, only
>> the source tarball deifferent)
>>
>> currently our production 2x6 core machine with two Intel(R) Xeon(R) CPU
>> E5-2643 v3 @ 3.40GHz and the same setup is around 4000-5000 per second
>> which is nearly reached by the 6 years old i7 with the JIT
>>
>> impressive!
>>
>> JIT:
>> Requests per second: 3526.56 [#/sec] (mean)
>> Time per request: 14.178 [ms] (mean)
>> Time per request: 0.284 [ms] (mean, across all concurrent requests)
>>
>> 7.1:
>> Requests per second: 1419.87 [#/sec] (mean)
>> Time per request: 35.214 [ms] (mean)
>> Time per request: 0.704 [ms] (mean, across all concurrent requests)
>>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] the experimental jit-branch is impressive

[li...@rhsoft.net]

and with a demo-page containing all sort of modules and bloat the 
difference is even greater - can't wait to see that in production


is there anything known when it is expected to arrive in the official 
tree or does Zend even hold it back until the point when they can 
suprise with a "we are done, all tests are fine and we can merge it" 
announce?


PHP 7.1:
Requests per second: 316.77 [#/sec] (mean)
Time per request: 157.844 [ms] (mean)
Time per request: 3.157 [ms] (mean, across all concurrent requests)
Transfer rate: 12604.11 [Kbytes/sec] received

PHP 7.2 JIT:
Requests per second: 925.96 [#/sec] (mean)
Time per request: 53.998 [ms] (mean)
Time per request: 1.080 [ms] (mean, across all concurrent requests)
Transfer rate: 36842.68 [Kbytes/sec] received

Am 02.05.2017 um 18:00 schrieb li...@rhsoft.net:

https://github.com/zendtech/php-src/tree/jit-dynasm/ext/opcache/jit

that below is a "ab -c 50 -n 10" on a Intel(R) Core(TM) i7-3770 CPU 
@ 3.40GHz on our core cms (pgo-build with heavy compiler optimizations, 
only the source tarball deifferent)


currently our production 2x6 core machine with two Intel(R) Xeon(R) CPU 
E5-2643 v3 @ 3.40GHz and the same setup is around 4000-5000 per second 
which is nearly reached by the 6 years old i7 with the JIT


impressive!

JIT:
Requests per second: 3526.56 [#/sec] (mean)
Time per request: 14.178 [ms] (mean)
Time per request: 0.284 [ms] (mean, across all concurrent requests)

7.1:
Requests per second: 1419.87 [#/sec] (mean)
Time per request: 35.214 [ms] (mean)
Time per request: 0.704 [ms] (mean, across all concurrent requests)


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

[PHP-DEV] the experimental jit-branch is impressive

[li...@rhsoft.net]

https://github.com/zendtech/php-src/tree/jit-dynasm/ext/opcache/jit

that below is a "ab -c 50 -n 10" on a Intel(R) Core(TM) i7-3770 CPU 
@ 3.40GHz on our core cms (pgo-build with heavy compiler optimizations, 
only the source tarball deifferent)


currently our production 2x6 core machine with two Intel(R) Xeon(R) CPU 
E5-2643 v3 @ 3.40GHz and the same setup is around 4000-5000 per second 
which is nearly reached by the 6 years old i7 with the JIT


impressive!

JIT:
Requests per second: 3526.56 [#/sec] (mean)
Time per request: 14.178 [ms] (mean)
Time per request: 0.284 [ms] (mean, across all concurrent requests)

7.1:
Requests per second: 1419.87 [#/sec] (mean)
Time per request: 35.214 [ms] (mean)
Time per request: 0.704 [ms] (mean, across all concurrent requests)

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

[PHP-DEV] Re: [Discussion] Dots and spaces in GPC variable names

[Christoph M. Becker]

On 02.05.2017 at 12:56, Andrey Andreev wrote:

> With parse_str() usage without a second parameter being deprecated, I
> was looking to possibly drop the behavior where it replaces spaces and
> dots with underscores in the result array, and ... As it often turns
> out - it's not that simple, because it re-uses the code that handles
> GPC vars.
> 
> I didn't even know this mangling happened with GPC vars. I can only
> assume that's legacy from the the register_global days, as I certainly
> don't see a reason for it now. Am I missing something?
> 
> And more importantly, can we change that? It's a significant BC break,
> yes, but the current behavior is horribly broken IMO.

This issue has been already brought to the list quite a while ago[1].
IMHO, the big problem is the subtle BC break.

[1] 

-- 
Christoph M. Becker

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

Re: [PHP-DEV] Add is_vectorlike($array) function

[Rowan Collins]

On 02/05/2017 11:53, Giovanni Giacobbi wrote:
Wouldn't be better to introduce a new native type "vector"? I know it 
sounds obnoxious introducing a new basic data type, but I think having 
a workaround like is_vectorlike() wouldn't completely address the problem.

...

function do_something_ex(vector $a) {
  // do something with $a
}


I can certainly sympathise with the desire to have this built into the 
type hint, but I think it leads to awkward questions about what kind of 
"type" this would be.


If it was a "real" type, that would imply users could explicitly 
construct it in some way, presumably with a new keyword. Indeed, in 
strict_types mode, they would presumably be *obliged* to do so, or cast 
their values, leading to noise like do_something_ex( (vector)$some_array );


It would be better in that case to have generics and a built-in List 
type, so we could type hint for List without the performance hit of 
checking the member types on every function call.



If, on the other hand, it was a pseudo-type only available in type 
hints, then it raises the question of why this particular check gets a 
keyword but others don't. For instance, positiveInt, nonNegativeInt, 
nonEmptyString, finiteFloat, etc, would all be similar in 
implementation: "assert type is X and condition Y is true". If not a 
real type, then "vector" is fundamentally a constrained domain of 
"array" values.



I also wouldn't call is_vectorlike() a workaround, as it serves a 
different use case and would be necessary even if we had a vector type 
hint. You can't choose a code path based on a type hint, since we don't 
have function overloading (which is probably sensible in a dynamic type 
system). We can always add the type hint later, as happened with the 
"callable" type hint.




  $a = [ "a", "b", "c" ];
  is_vector($a); // true
  is_array($a); // true
  unset($a[1]);
  is_vector($a); // false
  is_array($a); // true



Other than the name of the function, this is exactly how the proposed 
function would behave. Note that in this example, "vector" doesn't 
behave like a type, since is_array() returns true, and gettype() would 
still return 'array'.


Regards,

--
Rowan Collins
[IMSoP]


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

[PHP-DEV] [Discussion] Dots and spaces in GPC variable names

[Andrey Andreev]

Hi all,

With parse_str() usage without a second parameter being deprecated, I
was looking to possibly drop the behavior where it replaces spaces and
dots with underscores in the result array, and ... As it often turns
out - it's not that simple, because it re-uses the code that handles
GPC vars.

I didn't even know this mangling happened with GPC vars. I can only
assume that's legacy from the the register_global days, as I certainly
don't see a reason for it now. Am I missing something?

And more importantly, can we change that? It's a significant BC break,
yes, but the current behavior is horribly broken IMO.

Cheers,
Andrey.

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

Re: [PHP-DEV] Add is_vectorlike($array) function

[Giovanni Giacobbi]

On 2 May 2017 at 11:55, Rowan Collins  wrote:

> On 02/05/2017 10:13, Jesse Schalken wrote:
>
>> Related to the optimisation made by Sara Golemon here:
>> https://github.com/php/php-src/commit/c74bc87c74f48bc55541b3
>> bf2fc67d595f58a3b5
>>
>> I often define a function like this, which checks if an array is "vector
>> like" i.e. has keys 0,1,2..N:
>>
>> function is_vectorlike(array $a): bool {
>>$i = 0;
>>foreach ($a as $k => $v) {
>>  if ($k !== $i++) {
>>return false;
>>  }
>>}
>>return true;
>> }
>>
>>
> +1, I've been thinking of making a similar suggestion. We can bikeshed the
> name (it should certainly start with "array_"), but I think there's a very
> good case for having an optimised implementation built in, given the
> opportunities for short-cutting based on representation details.
>
>
Wouldn't be better to introduce a new native type "vector"? I know it
sounds obnoxious introducing a new basic data type, but I think having a
workaround like is_vectorlike() wouldn't completely address the problem.

Other than serializations I also felt, many many times, the need to also
type-hint the input parameters with vector:

function do_something(array $a) {
  if (!is_vectorlike($a))
throw new Exception("I don't like the input");
  // do something with $a
}

I feel like going back to the dark ages when I had to manually check for
is_string(), is_int() on the input parameters. Think how much better it
would be to be able to:

function do_something_ex(vector $a) {
  // do something with $a
}

Also it would be perfectly acceptable to implicitly cast a vector to an
array, since a vector is basically a packed array.

How does it sound? Complete madness?

  $a = [ "a", "b", "c" ];
  is_vector($a); // true
  is_array($a); // true
  unset($a[1]);
  is_vector($a); // false
  is_array($a); // true

Re: [PHP-DEV] Add is_vectorlike($array) function

[Rowan Collins]

On 02/05/2017 10:13, Jesse Schalken wrote:

Related to the optimisation made by Sara Golemon here:
https://github.com/php/php-src/commit/c74bc87c74f48bc55541b3bf2fc67d595f58a3b5

I often define a function like this, which checks if an array is "vector
like" i.e. has keys 0,1,2..N:

function is_vectorlike(array $a): bool {
   $i = 0;
   foreach ($a as $k => $v) {
 if ($k !== $i++) {
   return false;
 }
   }
   return true;
}

The problem is that this function is O(n), but in PHP7 an array that is
vector-like is likely to be packed and without holes (HT_IS_PACKED(x) &&
HT_IS_WITHOUT_HOLES(x)), in which case it is known to be vector-like
without needing to iterate over it, but PHP code can't check for this (nor
should it be able to, since it's really an implementation detail).

Would it be a good idea to define this is_vectorlike() function in the PHP
runtime, so it can short circuit to return true on packed arrays without
holes? The above code would be a suitable polyfill.



+1, I've been thinking of making a similar suggestion. We can bikeshed 
the name (it should certainly start with "array_"), but I think there's 
a very good case for having an optimised implementation built in, given 
the opportunities for short-cutting based on representation details.


As an example use case, serialization formats often dynamically switch 
between an "array"/"vector"/"list", and a "hash"/"dictionary"/"table". I 
came upon this example recently: 
https://github.com/php-amqplib/php-amqplib/blob/master/PhpAmqpLib/Wire/AMQPAbstractCollection.php#L218


Regards,

--
Rowan Collins
[IMSoP]


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

[PHP-DEV] Add is_vectorlike($array) function

[Jesse Schalken]

Related to the optimisation made by Sara Golemon here:
https://github.com/php/php-src/commit/c74bc87c74f48bc55541b3bf2fc67d595f58a3b5

I often define a function like this, which checks if an array is "vector
like" i.e. has keys 0,1,2..N:

function is_vectorlike(array $a): bool {
  $i = 0;
  foreach ($a as $k => $v) {
if ($k !== $i++) {
  return false;
}
  }
  return true;
}

The problem is that this function is O(n), but in PHP7 an array that is
vector-like is likely to be packed and without holes (HT_IS_PACKED(x) &&
HT_IS_WITHOUT_HOLES(x)), in which case it is known to be vector-like
without needing to iterate over it, but PHP code can't check for this (nor
should it be able to, since it's really an implementation detail).

Would it be a good idea to define this is_vectorlike() function in the PHP
runtime, so it can short circuit to return true on packed arrays without
holes? The above code would be a suitable polyfill.

[PHP-DEV] variables_order issue with run-test.php

[Matt Ficken]

Hi,

I noticed that php.ini-development now sets variables_order="GPCS" instead
of "EGPCS".

run-test.php uses $_ENV to read environment variables and will set those on
all the child processes it creates. However, if variables_order="GPCS",
$_ENV will be empty and the environment variables table on the child
process will be empty, at least on Windows, the only env variables the
child then gets are PATH and COMSPEC. Importantly, TEMP or TMP is not
available, which causes a problem for generating temporary file names, and
on Windows, that breaks OpCache.

Often, php.ini-development will just be renamed to php.ini. Since $_ENV
isn't preferred anymore, run-test.php shouldn't be dependent on it.

I can fix this myself, but would like to know the preferred solution.

I suggest any of these fixes:

1. die if variables_order doesn't include "E"
2. die if $_ENV is empty: lots of tests will be false fails if no env vars
are set, so prevent getting to that point.
3. use getenv() to read common environment variables(TEMP or TMP) at
least.  getenv() doesn't provide a list of environment variable names, and
ideally it would just copy all of them, so try to use $_ENV and only use
getenv() if TEMP or TMP is not set.and then die if $_ENV is still empty.


Regards
-M

[PHP-DEV] Introduction

[Peter]

Hello

New to PHP internals. Keen on fixing a bug or two where I can.

Warm Regards

Peter Chaula