Re: [PHP-DEV] Runtime-JIT, the whole enchilada
After some off-list discussion with Pierre and Rasmus, I think we should move forward with the approach of JITting the whole array at once (similar to how it's done now, except at runtime). It seems to be the least of all evils and allows the flexibility of choosing encoding at runtime. What code changes need to be done for this? -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Runtime-JIT, the whole enchilada
Your proposal was to have a couple of separate functions that people would use to access GPC data and retrieve it in Unicode form, no? -Andrei On Jan 30, 2007, at 8:39 AM, Pierre wrote: On 1/30/07, Andrei Zmievski <[EMAIL PROTECTED]> wrote: Of course we won't drop it, but it would contain raw binary data (as opposed to the rest of the PHP environment in unicode semantics mode). IMO, it is inconsistent and confusing to the end user. I do not follow you. Why would it contain raw binary data? --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Runtime-JIT, the whole enchilada
On 1/30/07, Andrei Zmievski <[EMAIL PROTECTED]> wrote: Of course we won't drop it, but it would contain raw binary data (as opposed to the rest of the PHP environment in unicode semantics mode). IMO, it is inconsistent and confusing to the end user. I do not follow you. Why would it contain raw binary data? --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Runtime-JIT, the whole enchilada
Of course we won't drop it, but it would contain raw binary data (as opposed to the rest of the PHP environment in unicode semantics mode). IMO, it is inconsistent and confusing to the end user. -A On Jan 29, 2007, at 3:20 PM, Pierre wrote: Please, who said we will *drop* the GPC array? That's exactly what I try to avoid. What I say is to __add__ something like that, not to replace gpc. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Runtime-JIT, the whole enchilada
On 1/29/07, Richard Lynch <[EMAIL PROTECTED]> wrote: On Sat, January 27, 2007 5:16 am, Pierre wrote: > On 1/27/07, Andrei Zmievski <[EMAIL PROTECTED]> wrote: >> Good luck trying to retrain millions of programmers to use a CGI >> object or a function to retrieve GPC values. > > You will be surprised, really :) I doubt it. We haven't even gotten everybody to get rid of register_globals and switch to $_GET['foo'] instead of $foo yet. The register_globals change at least had a clear Security reasoning behind it, once one understood the problem. [Though I confess I was in denial for ages since I always initialize variables.] If we change this around yet again, it will be disastrous, imho. Please, who said we will *drop* the GPC array? That's exactly what I try to avoid. What I say is to __add__ something like that, not to replace gpc. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Runtime-JIT, the whole enchilada
On Sat, January 27, 2007 5:16 am, Pierre wrote: > On 1/27/07, Andrei Zmievski <[EMAIL PROTECTED]> wrote: >> Good luck trying to retrain millions of programmers to use a CGI >> object or a function to retrieve GPC values. > > You will be surprised, really :) I doubt it. We haven't even gotten everybody to get rid of register_globals and switch to $_GET['foo'] instead of $foo yet. The register_globals change at least had a clear Security reasoning behind it, once one understood the problem. [Though I confess I was in denial for ages since I always initialize variables.] If we change this around yet again, it will be disastrous, imho. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Runtime-JIT, the whole enchilada
On 1/29/07, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: > Oh! It was not a +1 from me for this patch, I still prefer my simpler > solution (which has to be written ;). However, as a temporary/test > code Sara's patch can do it for now no? What's the reason to commit "temporary test code" to CVS? If one wants to play with it, one can always apply a patch. There's no reason for the code to be in the CVS unless you mean it to stay. I agree for 99% of the commits in head. But given that unicode is very experimental (no offense), both from an implementation and needs point of view, I do not have problems to commit a solution even if it is not perfect. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Runtime-JIT, the whole enchilada
Oh! It was not a +1 from me for this patch, I still prefer my simpler solution (which has to be written ;). However, as a temporary/test code Sara's patch can do it for now no? What's the reason to commit "temporary test code" to CVS? If one wants to play with it, one can always apply a patch. There's no reason for the code to be in the CVS unless you mean it to stay. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Runtime-JIT, the whole enchilada
Hi Andi, On 1/27/07, Andi Gutmans <[EMAIL PROTECTED]> wrote: s during PHP 5 where I warned that they might introduce bugs in other areas but it's hard to forsee. No one believed me because I couldn't give a concrete enough example and we had quite a few of those bugs afterwards. Given the state of PHP5 when it was released, everyone sane should believe (I would say trust) you, even if you were the one pushing php5 final release :) As some point the platform has to be the one that grows and not the language. So if we need to evolve it to have a different way of fetching input variables that's what we should do. Exactly my point (again :-/), it is my goal for filter. That's also why I asked you (I still wait the answer by the way) earlier this year what are your needs about filters and what do you mean in your post, as you were saying that we did not do a good job. I, and I'm the only one in the active filter maintainers, changed my mind (more open) and I really think that we should provide a OO way to fetch the inputs. It can be type oriented (::getInteger()), variable oriented (::get($name), and/or both. But the needs are definitively here and I will do my best to push that in (a cgi-like object is one solution). You don't see other languages change every day because of a higher level requirement. And have no doubt, PHP 6 will take a long time to truly stabilize and make consistent because there've been huge changes. I 100% agree. No matter how much efforts are pushed into its development, I cannot imagine a first stable release in a near future, next year at best. By stable I mean a release not marked RC and something with at least a beta quality and not alpha like 5.0.0. Nobody will expect 6.0.0 to be perfect, but we should not make the same mistake again. Regards, --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Runtime-JIT, the whole enchilada
Sorry for the spam (I'm a bit behind). I agree 100% with Dmitry. Guys (n'girls), I don't know if you've realized but the engine has become much involved. We've added a lot of new features in PHP 5 and beyond, Unicode has muliplied that by 2, we added some performance features and we've just more or less managed to solve some of the ugly issues with return by reference and overloaded properties. I think we need to move into a state of mind now that adding additional implementation complexity is a last and not a first resort. Otherwise it'll end up being impossible to maintain all the interdependencies. I said the same with past features during PHP 5 where I warned that they might introduce bugs in other areas but it's hard to forsee. No one believed me because I couldn't give a concrete enough example and we had quite a few of those bugs afterwards. As some point the platform has to be the one that grows and not the language. So if we need to evolve it to have a different way of fetching input variables that's what we should do. You don't see other languages change every day because of a higher level requirement. And have no doubt, PHP 6 will take a long time to truly stabilize and make consistent because there've been huge changes. Andi > -Original Message- > From: Dmitry Stogov [mailto:[EMAIL PROTECTED] > Sent: Saturday, January 27, 2007 3:51 AM > To: 'Pierre'; 'Andrei Zmievski' > Cc: 'Sara Golemon'; internals@lists.php.net; 'Andi Gutmans'; > 'Zeev Suraski'; 'Stanislav Malyshev' > Subject: RE: [PHP-DEV] Runtime-JIT, the whole enchilada > > > -Original Message- > > From: Pierre [mailto:[EMAIL PROTECTED] > > Sent: Saturday, January 27, 2007 2:16 PM > > To: Andrei Zmievski > > Cc: Dmitry Stogov; Sara Golemon; internals@lists.php.net; Andi > > Gutmans; Zeev Suraski; Stanislav Malyshev > > Subject: Re: [PHP-DEV] Runtime-JIT, the whole enchilada > > > > > > Hello Andrei, > > > > On 1/27/07, Andrei Zmievski <[EMAIL PROTECTED]> wrote: > > > Good luck trying to retrain millions of programmers to use a CGI > > > object or a function to retrieve GPC values. > > > > You will be surprised, really :) > > > > > Really, how much of a > > > performance hit is Sara's patch going to be, compared to > > other things > > > in PHP 6? > > > > It is to early to argue about performance problems in my humble > > opinion. My point was more about the complexity. > > Agree 100%. The slowdown is not large (may be 1%), but > internal dependencies are to complex. > This solution may be similar to "indirect modification of > overloaded properties" or "return by reference", then > mistakes give hundreds of bug reports and takes years for > completely fix. > > > That's why I prefer the other solution which simply moves > the JIT to > > runtime without other changes but a function to get the encoding > > error. > > > > To be honest, I do not understand the resistance to commit > > experimental code in head. For what really matters, we need > a working > > solution. It does not need to be perfert, it needs to work (more or > > less). We still have plenty of time to improve it until 6 > is out (not > > going to happen in the next months anyway). > > I cannot restrict commits, I only tell my opinion. > If the patch will be fixed for opcode caches, and most of > developers will vote for it, it can go. > > Dmitry. > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Runtime-JIT, the whole enchilada
Btw, having a request object was one of the #1 requests in framework :) People actually really like encapsulating this because it also makes unit testing easier down the road... Just mentioning this because I don't think we should be too set with our ways esp. for people who need to accomplish more functionality. Andi > -Original Message- > From: Pierre [mailto:[EMAIL PROTECTED] > Sent: Saturday, January 27, 2007 3:16 AM > To: Andrei Zmievski > Cc: Dmitry Stogov; Sara Golemon; internals@lists.php.net; > Andi Gutmans; Zeev Suraski; Stanislav Malyshev > Subject: Re: [PHP-DEV] Runtime-JIT, the whole enchilada > > Hello Andrei, > > On 1/27/07, Andrei Zmievski <[EMAIL PROTECTED]> wrote: > > Good luck trying to retrain millions of programmers to use a CGI > > object or a function to retrieve GPC values. > > You will be surprised, really :) > > > Really, how much of a > > performance hit is Sara's patch going to be, compared to > other things > > in PHP 6? > > It is to early to argue about performance problems in my > humble opinion. My point was more about the complexity. > That's why I prefer the other solution which simply moves the > JIT to runtime without other changes but a function to get > the encoding error. > > To be honest, I do not understand the resistance to commit > experimental code in head. For what really matters, we need a > working solution. It does not need to be perfert, it needs to > work (more or less). We still have plenty of time to improve > it until 6 is out (not going to happen in the next months anyway). > > --Pierre > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Runtime-JIT, the whole enchilada
On 1/27/07, Dmitry Stogov <[EMAIL PROTECTED]> wrote: > -Original Message- > From: Pierre [mailto:[EMAIL PROTECTED] > Sent: Saturday, January 27, 2007 2:16 PM > To: Andrei Zmievski > Cc: Dmitry Stogov; Sara Golemon; internals@lists.php.net; > Andi Gutmans; Zeev Suraski; Stanislav Malyshev > Subject: Re: [PHP-DEV] Runtime-JIT, the whole enchilada > > > Hello Andrei, > > On 1/27/07, Andrei Zmievski <[EMAIL PROTECTED]> wrote: > > Good luck trying to retrain millions of programmers to use a CGI > > object or a function to retrieve GPC values. > > You will be surprised, really :) > > > Really, how much of a > > performance hit is Sara's patch going to be, compared to > other things > > in PHP 6? > > It is to early to argue about performance problems in my > humble opinion. My point was more about the complexity. Agree 100%. The slowdown is not large (may be 1%), but internal dependencies are to complex. This solution may be similar to "indirect modification of overloaded properties" or "return by reference", then mistakes give hundreds of bug reports and takes years for completely fix. > That's why I prefer the other solution which simply moves the > JIT to runtime without other changes but a function to get > the encoding error. > > To be honest, I do not understand the resistance to commit > experimental code in head. For what really matters, we need a > working solution. It does not need to be perfert, it needs to > work (more or less). We still have plenty of time to improve > it until 6 is out (not going to happen in the next months anyway). I cannot restrict commits, I only tell my opinion. If the patch will be fixed for opcode caches, and most of developers will vote for it, it can go. Oh! It was not a +1 from me for this patch, I still prefer my simpler solution (which has to be written ;). However, as a temporary/test code Sara's patch can do it for now no? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Runtime-JIT, the whole enchilada
> -Original Message- > From: Pierre [mailto:[EMAIL PROTECTED] > Sent: Saturday, January 27, 2007 2:16 PM > To: Andrei Zmievski > Cc: Dmitry Stogov; Sara Golemon; internals@lists.php.net; > Andi Gutmans; Zeev Suraski; Stanislav Malyshev > Subject: Re: [PHP-DEV] Runtime-JIT, the whole enchilada > > > Hello Andrei, > > On 1/27/07, Andrei Zmievski <[EMAIL PROTECTED]> wrote: > > Good luck trying to retrain millions of programmers to use a CGI > > object or a function to retrieve GPC values. > > You will be surprised, really :) > > > Really, how much of a > > performance hit is Sara's patch going to be, compared to > other things > > in PHP 6? > > It is to early to argue about performance problems in my > humble opinion. My point was more about the complexity. Agree 100%. The slowdown is not large (may be 1%), but internal dependencies are to complex. This solution may be similar to "indirect modification of overloaded properties" or "return by reference", then mistakes give hundreds of bug reports and takes years for completely fix. > That's why I prefer the other solution which simply moves the > JIT to runtime without other changes but a function to get > the encoding error. > > To be honest, I do not understand the resistance to commit > experimental code in head. For what really matters, we need a > working solution. It does not need to be perfert, it needs to > work (more or less). We still have plenty of time to improve > it until 6 is out (not going to happen in the next months anyway). I cannot restrict commits, I only tell my opinion. If the patch will be fixed for opcode caches, and most of developers will vote for it, it can go. Dmitry. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Runtime-JIT, the whole enchilada
Hello Andrei, On 1/27/07, Andrei Zmievski <[EMAIL PROTECTED]> wrote: Good luck trying to retrain millions of programmers to use a CGI object or a function to retrieve GPC values. You will be surprised, really :) Really, how much of a performance hit is Sara's patch going to be, compared to other things in PHP 6? It is to early to argue about performance problems in my humble opinion. My point was more about the complexity. That's why I prefer the other solution which simply moves the JIT to runtime without other changes but a function to get the encoding error. To be honest, I do not understand the resistance to commit experimental code in head. For what really matters, we need a working solution. It does not need to be perfert, it needs to work (more or less). We still have plenty of time to improve it until 6 is out (not going to happen in the next months anyway). --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Runtime-JIT, the whole enchilada
Good luck trying to retrain millions of programmers to use a CGI object or a function to retrieve GPC values. Really, how much of a performance hit is Sara's patch going to be, compared to other things in PHP 6? -Andrei On Jan 26, 2007, at 3:38 PM, Pierre wrote: That's somehow my thoughts too. My initial proposal was to have a simple JIT for GPC at runtime (which is not that hard to implement but not easy either ;) and then use filter (as it exists for this exact purpose!). Another approach I really like is the cgi object, see perl or python for nice implementations examples. --Pierre ps: we are running in circle, I said that already many times already... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Runtime-JIT, the whole enchilada
On 1/27/07, Dmitry Stogov <[EMAIL PROTECTED]> wrote: Hi Sara, > -Original Message- > From: Sara Golemon [mailto:[EMAIL PROTECTED] > Sent: Friday, January 26, 2007 8:11 PM > To: Dmitry Stogov > Cc: internals@lists.php.net; 'Andi Gutmans'; 'Andrei > Zmievski'; Zeev Suraski; Stanislav Malyshev > Subject: Re: [PHP-DEV] Runtime-JIT, the whole enchilada > > > > I fixed one error in your patch, so now it passes all tests. > > > Which error? I notice some changes related to minimizing performance > impact, but I'm not seeing what I did wrong. Just curious for my own > benefit on that one. During combination of ZEND_FETCH, ZEND_FETCH_OBJ into one ZEND_FETCH_OBJ with IS_CV you didn't check for first check type. So you could combine fetch of static (or global) variable into CV. You can just run "make test" with your and my patch and see difference. > > BTW I am against this patch. > > > Fair enough. > > > 1) It adds sloppily built functionality into the core > Well, you sure know how to sweet-talk a gal. My English isn't good and I spent some time with dictionary to write that I think :) Really, I think that you use the most complicated way to solve HTTP input encoding problem. May be we no longer need for autoglobals at all and can use simple functions like http_get_var($name). That's somehow my thoughts too. My initial proposal was to have a simple JIT for GPC at runtime (which is not that hard to implement but not easy either ;) and then use filter (as it exists for this exact purpose!). Another approach I really like is the cgi object, see perl or python for nice implementations examples. --Pierre ps: we are running in circle, I said that already many times already... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Runtime-JIT, the whole enchilada
Hi Sara, > -Original Message- > From: Sara Golemon [mailto:[EMAIL PROTECTED] > Sent: Friday, January 26, 2007 8:11 PM > To: Dmitry Stogov > Cc: internals@lists.php.net; 'Andi Gutmans'; 'Andrei > Zmievski'; Zeev Suraski; Stanislav Malyshev > Subject: Re: [PHP-DEV] Runtime-JIT, the whole enchilada > > > > I fixed one error in your patch, so now it passes all tests. > > > Which error? I notice some changes related to minimizing performance > impact, but I'm not seeing what I did wrong. Just curious for my own > benefit on that one. During combination of ZEND_FETCH, ZEND_FETCH_OBJ into one ZEND_FETCH_OBJ with IS_CV you didn't check for first check type. So you could combine fetch of static (or global) variable into CV. You can just run "make test" with your and my patch and see difference. > > BTW I am against this patch. > > > Fair enough. > > > 1) It adds sloppily built functionality into the core > Well, you sure know how to sweet-talk a gal. My English isn't good and I spent some time with dictionary to write that I think :) Really, I think that you use the most complicated way to solve HTTP input encoding problem. May be we no longer need for autoglobals at all and can use simple functions like http_get_var($name). Thanks. Dmitry. > and slowdowns EACH > > dimension or property fetch both at run-time and > compilation-time. I think > > it is a big cost for $_GET/$_POST encoding-conversion, but > it is only my > > opinion. > > > For disarmed callbacks, it amounts to a vector lookup and a couple > integer compares, I'd hardly call that a "big cost". As to armed > callbacks, well, if they're still armed then they still have > some work > to do. Refer to prior posts in the thread as to why this work would > (and should) be deferred. > > > 2) It adds pointer to zend_auto_global into > zend_compiled_variable. This > > makes troubles for opcode caches - > zend_compiled_variable(s) may lay in > > shared memory, so they cannot point to process specific > data. I think this > > issue can be fixed using indirect pointer (index). > > > Excellent point. That will need to be addressed > > > Why did you reject auto-globals as overloaded arrays? > > > See earlier posts in this thread, such as the one I sent you > less than a > week ago and to which you replied indicating you understood it. > > If you thinking breaking BC is preferable to this "sloppy" approach, > then we can reexamine that. If you have a better, third > approach, which > solves all of the issues already outlined, then I'd love to hear it. > > -Sara > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Runtime-JIT, the whole enchilada
I fixed one error in your patch, so now it passes all tests. Which error? I notice some changes related to minimizing performance impact, but I'm not seeing what I did wrong. Just curious for my own benefit on that one. BTW I am against this patch. Fair enough. 1) It adds sloppily built functionality into the core Well, you sure know how to sweet-talk a gal. and slowdowns EACH dimension or property fetch both at run-time and compilation-time. I think it is a big cost for $_GET/$_POST encoding-conversion, but it is only my opinion. For disarmed callbacks, it amounts to a vector lookup and a couple integer compares, I'd hardly call that a "big cost". As to armed callbacks, well, if they're still armed then they still have some work to do. Refer to prior posts in the thread as to why this work would (and should) be deferred. 2) It adds pointer to zend_auto_global into zend_compiled_variable. This makes troubles for opcode caches - zend_compiled_variable(s) may lay in shared memory, so they cannot point to process specific data. I think this issue can be fixed using indirect pointer (index). Excellent point. That will need to be addressed Why did you reject auto-globals as overloaded arrays? See earlier posts in this thread, such as the one I sent you less than a week ago and to which you replied indicating you understood it. If you thinking breaking BC is preferable to this "sloppy" approach, then we can reexamine that. If you have a better, third approach, which solves all of the issues already outlined, then I'd love to hear it. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Runtime-JIT, the whole enchilada
I fixed one error in your patch, so now it passes all tests. Which error? I notice some changes related to minimizing performance impact, but I'm not seeing what I did wrong. Just curious for my own benefit on that one. BTW I am against this patch. Fair enough. 1) It adds sloppily built functionality into the core Well, you sure know how to sweet-talk a gal. and slowdowns EACH dimension or property fetch both at run-time and compilation-time. I think it is a big cost for $_GET/$_POST encoding-conversion, but it is only my opinion. For disarmed callbacks, it amounts to a vector lookup and a couple integer compares, I'd hardly call that a "big cost". As to armed callbacks, well, if they're still armed then they still have some work to do. Refer to prior posts in the thread as to why this work would (and should) be deferred. 2) It adds pointer to zend_auto_global into zend_compiled_variable. This makes troubles for opcode caches - zend_compiled_variable(s) may lay in shared memory, so they cannot point to process specific data. I think this issue can be fixed using indirect pointer (index). Excellent point. That will need to be addressed Why did you reject auto-globals as overloaded arrays? See earlier posts in this thread, such as the one I sent you less than a week ago and to which you replied indicating you understood it. If you thinking breaking BC is preferable to this "sloppy" approach, then we can reexamine that. If you have a better, third approach, which solves all of the issues already outlined, then I'd love to hear it. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Runtime-JIT, the whole enchilada
Hi Dmitry, On 1/26/07, Dmitry Stogov <[EMAIL PROTECTED]> wrote: Hi Sara, I fixed one error in your patch, so now it passes all tests. BTW I am against this patch. 1) It adds sloppily built functionality into the core and slowdowns EACH dimension or property fetch both at run-time and compilation-time. I think it is a big cost for $_GET/$_POST encoding-conversion, but it is only my opinion. 2) It adds pointer to zend_auto_global into zend_compiled_variable. This makes troubles for opcode caches - zend_compiled_variable(s) may lay in shared memory, so they cannot point to process specific data. I think this issue can be fixed using indirect pointer (index). I would prefer rollback "auto-globals CV" patch and commit (or not) the whole patch after conclusion. Why did you reject auto-globals as overloaded arrays? As I already told you in my initial proposal (which is simpler than this solution), they do not work in all cases (check the various bugs about them) and they will bring a huge breakage as is_array($objarray) returns false. The later is certainly fixable (with slowness too), I'm not sure about the other issues. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Runtime-JIT, the whole enchilada
Hi Sara,
I fixed one error in your patch, so now it passes all tests.
BTW I am against this patch.
1) It adds sloppily built functionality into the core and slowdowns EACH
dimension or property fetch both at run-time and compilation-time. I think
it is a big cost for $_GET/$_POST encoding-conversion, but it is only my
opinion.
2) It adds pointer to zend_auto_global into zend_compiled_variable. This
makes troubles for opcode caches - zend_compiled_variable(s) may lay in
shared memory, so they cannot point to process specific data. I think this
issue can be fixed using indirect pointer (index).
I would prefer rollback "auto-globals CV" patch and commit (or not) the
whole patch after conclusion.
Why did you reject auto-globals as overloaded arrays?
Thanks. Dmitry.
> -Original Message-
> From: Sara Golemon [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 24, 2007 10:58 PM
> To: internals@lists.php.net; Dmitry Stogov; Andi Gutmans;
> Andrei Zmievski
> Subject: [PHP-DEV] Runtime-JIT, the whole enchilada
>
>
> Dmitry-
>
>You asked for it, you get it :) Hopefully it'll be
> self-explanatory,
> the one part I hope you don't notice is that I put the
> auto_global check
> back into fetch_simple_variable_ex in order to force direct access to
> autoglobals ($foo = $_GET;foreach($_POST as ...) etc...) as
> non-auto-globals. Ultimately this made catching the
> difference between
> a whole var access and a dim/obj access much more
> straight-forward and
> computationally cheap. It comes at a slight cost for those
> fetches, but
> hopefully they're in the minority.
>
> Bench numbers with this patch:
> simple 0.461
> simplecall 1.985
> simpleucall2.900
> simpleudcall 3.488
> mandel 2.136
> mandel23.192
> ackermann(7) 3.490
> ary(5) 0.154
> ary2(5)0.137
> ary3(2000) 1.076
> fibo(30) 9.766
> hash1(5) 0.423
> hash2(500) 0.307
> heapsort(2)0.799
> matrix(20) 0.526
> nestedloop(12) 0.866
> sieve(30) 0.630
> strcat(20) 0.303
>
> Total 32.639
>
> -Sara
>
>
Index: main/php_variables.c
===
RCS file: /repository/php-src/main/php_variables.c,v
retrieving revision 1.136
diff -u -p -d -r1.136 php_variables.c
--- main/php_variables.c1 Jan 2007 09:29:35 - 1.136
+++ main/php_variables.c26 Jan 2007 10:23:11 -
@@ -628,9 +628,9 @@ void _php_import_environment_variables(z
}
}
-zend_bool php_std_auto_global_callback(char *name, uint name_len TSRMLS_DC)
+zend_bool php_std_auto_global_callback(zend_auto_global *auto_global, int
stage, zval *ag_val, int fetch_op, zval *member TSRMLS_DC)
{
- zend_printf("%s\n", name);
+ zend_printf("%s\n", auto_global->name);
return 0; /* don't rearm */
}
@@ -802,9 +802,13 @@ static void php_autoglobal_merge(HashTab
}
/* }}} */
-static zend_bool php_auto_globals_create_server(char *name, uint name_len
TSRMLS_DC);
-static zend_bool php_auto_globals_create_env(char *name, uint name_len
TSRMLS_DC);
-static zend_bool php_auto_globals_create_request(char *name, uint name_len
TSRMLS_DC);
+static zend_auto_global *php_server_auto_global = NULL;
+static zend_auto_global *php_env_auto_global = NULL;
+static zend_auto_global *php_request_auto_global = NULL;
+
+static zend_bool php_auto_globals_create_server(zend_auto_global *auto_global,
int stage, zval *ag_val, int fetch_op, zval *member TSRMLS_DC);
+static zend_bool php_auto_globals_create_env(zend_auto_global *auto_global,
int stage, zval *ag_val, int fetch_op, zval *member TSRMLS_DC);
+static zend_bool php_auto_globals_create_request(zend_auto_global
*auto_global, int stage, zval *ag_val, int fetch_op, zval *member TSRMLS_DC);
/* {{{ php_hash_environment
*/
@@ -861,16 +865,14 @@ int php_hash_environment(TSRMLS_D)
case 'e':
case 'E':
if (!jit_initialization && !_gpc_flags[3]) {
- zend_auto_global_disable_jit("_ENV",
sizeof("_ENV")-1 TSRMLS_CC);
- php_auto_globals_create_env("_ENV",
sizeof("_ENV")-1 TSRMLS_CC);
+ php_env_auto_global->armed =
php_auto_globals_create_env(php_env_auto_global, ZEND_RT, NULL, ZEND_FETCH_R,
NULL TSRMLS_CC);
_gpc_flags[3] = 1;
}
break;
case 's':
Re: [PHP-DEV] Runtime-JIT, the whole enchilada
What are the numbers before the patch?
On 24-Jan-07, at 2:58 PM, Sara Golemon wrote:
Dmitry-
You asked for it, you get it :) Hopefully it'll be self-
explanatory, the one part I hope you don't notice is that I put the
auto_global check back into fetch_simple_variable_ex in order to
force direct access to autoglobals ($foo = $_GET;foreach($_POST
as ...) etc...) as non-auto-globals. Ultimately this made
catching the difference between a whole var access and a dim/obj
access much more straight-forward and computationally cheap. It
comes at a slight cost for those fetches, but hopefully they're in
the minority.
Bench numbers with this patch:
simple 0.461
simplecall 1.985
simpleucall2.900
simpleudcall 3.488
mandel 2.136
mandel23.192
ackermann(7) 3.490
ary(5) 0.154
ary2(5)0.137
ary3(2000) 1.076
fibo(30) 9.766
hash1(5) 0.423
hash2(500) 0.307
heapsort(2)0.799
matrix(20) 0.526
nestedloop(12) 0.866
sieve(30) 0.630
strcat(20) 0.303
Total 32.639
-Sara
Index: Zend/zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.736
diff -u -p -r1.736 zend_compile.c
--- Zend/zend_compile.c 20 Jan 2007 20:36:55 - 1.736
+++ Zend/zend_compile.c 24 Jan 2007 19:50:52 -
@@ -290,7 +290,8 @@ static int lookup_cv(zend_op_array *op_a
op_array->vars[i].name = name; /* estrndup(name, name_len); */
op_array->vars[i].name_len = name_len;
op_array->vars[i].hash_value = hash_value;
- op_array->vars[i].fetch_type = zend_u_is_auto_global(type, name,
name_len TSRMLS_CC) ? ZEND_FETCH_GLOBAL : ZEND_FETCH_LOCAL;
+ op_array->vars[i].auto_global = NULL;
+ op_array->vars[i].fetch_type = zend_u_is_auto_global(type, name,
name_len, &(op_array->vars[i].auto_global) TSRMLS_CC) ?
ZEND_FETCH_GLOBAL : ZEND_FETCH_LOCAL;
return i;
}
@@ -383,6 +384,7 @@ void fetch_simple_variable_ex(znode *res
Z_TYPE(varname->u.constant) == IS_UNICODE) &&
!(Z_UNILEN(varname->u.constant) == (sizeof("this")-1) &&
ZEND_U_EQUAL(Z_TYPE(varname->u.constant), Z_UNIVAL(varname-
>u.constant), Z_UNILEN(varname->u.constant), "this", sizeof
("this")-1)) &&
+ !zend_u_is_auto_global(Z_TYPE(varname->u.constant), Z_UNIVAL
(varname->u.constant), Z_UNILEN(varname->u.constant), NULL
TSRMLS_CC) &&
(CG(active_op_array)->last == 0 ||
CG(active_op_array)->opcodes[CG(active_op_array)-
>last-1].opcode != ZEND_BEGIN_SILENCE)) {
result->op_type = IS_CV;
@@ -410,7 +412,7 @@ void fetch_simple_variable_ex(znode *res
if (varname->op_type == IS_CONST &&
(Z_TYPE(varname->u.constant) == IS_STRING ||
Z_TYPE(varname->u.constant) == IS_UNICODE)) {
- if (zend_u_is_auto_global(Z_TYPE(varname->u.constant), Z_UNIVAL
(varname->u.constant), Z_UNILEN(varname->u.constant) TSRMLS_CC)) {
+ if (zend_u_is_auto_global(Z_TYPE(varname->u.constant), Z_UNIVAL
(varname->u.constant), Z_UNILEN(varname->u.constant), NULL
TSRMLS_CC)) {
opline_ptr->op2.u.EA.type = ZEND_FETCH_GLOBAL;
}
}
@@ -492,6 +494,29 @@ void fetch_array_dim(znode *result, znod
zend_op opline;
zend_llist *fetch_list_ptr;
+ zend_stack_top(&CG(bp_stack), (void **) &fetch_list_ptr);
+ if (fetch_list_ptr->count == 1) {
+ zend_llist_element *le = fetch_list_ptr->head;
+ zend_op *parentop = (zend_op*)le->data;
+
+ if (parentop && parentop->opcode == ZEND_FETCH_W &&
+ parent->op_type == IS_VAR && parentop->result.op_type == IS_VAR
&& parent->u.var == parentop->result.u.var &&
+ parentop->op1.op_type == IS_CONST &&
+ (Z_TYPE(parentop->op1.u.constant) == IS_STRING || Z_TYPE
(parentop->op1.u.constant) == IS_UNICODE) &&
+ !(Z_UNILEN(parentop->op1.u.constant) == (sizeof("this")-1) &&
ZEND_U_EQUAL(Z_TYPE(parentop->op1.u.constant), Z_UNIVAL(parentop-
>op1.u.constant), Z_UNILEN(parentop->op1.u.constant), "this", sizeof
("this")-1)) ) {
+ /* Recompile CV and rewrite previous op to direct
FETCH_DIM */
+ zval tmp = parentop->op1.u.constant;
+ parentop->opcode = ZEND_FETCH_DIM_W;
+ parentop->op1.op_type = IS_CV;
+ parentop->op1.u.var = lookup_cv(CG(active_op_array), Z_TYPE
(tmp), Z_UNIVAL(tmp), Z_UNILEN(tmp) TSRMLS_CC);
+ parentop->op1.u.EA.type = 0;
+ parentop->op2 = *dim;
+ parentop->extended_value = ZEND_FETCH_STANDARD;
+ *result = parentop->result;
+ return;
+ }
+ }
+
init_op(&opline TSRMLS_CC);
o
[PHP-DEV] Runtime-JIT, the whole enchilada
Dmitry-
You asked for it, you get it :) Hopefully it'll be self-explanatory,
the one part I hope you don't notice is that I put the auto_global check
back into fetch_simple_variable_ex in order to force direct access to
autoglobals ($foo = $_GET;foreach($_POST as ...) etc...) as
non-auto-globals. Ultimately this made catching the difference between
a whole var access and a dim/obj access much more straight-forward and
computationally cheap. It comes at a slight cost for those fetches, but
hopefully they're in the minority.
Bench numbers with this patch:
simple 0.461
simplecall 1.985
simpleucall2.900
simpleudcall 3.488
mandel 2.136
mandel23.192
ackermann(7) 3.490
ary(5) 0.154
ary2(5)0.137
ary3(2000) 1.076
fibo(30) 9.766
hash1(5) 0.423
hash2(500) 0.307
heapsort(2)0.799
matrix(20) 0.526
nestedloop(12) 0.866
sieve(30) 0.630
strcat(20) 0.303
Total 32.639
-Sara
Index: Zend/zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.736
diff -u -p -r1.736 zend_compile.c
--- Zend/zend_compile.c 20 Jan 2007 20:36:55 - 1.736
+++ Zend/zend_compile.c 24 Jan 2007 19:50:52 -
@@ -290,7 +290,8 @@ static int lookup_cv(zend_op_array *op_a
op_array->vars[i].name = name; /* estrndup(name, name_len); */
op_array->vars[i].name_len = name_len;
op_array->vars[i].hash_value = hash_value;
- op_array->vars[i].fetch_type = zend_u_is_auto_global(type, name,
name_len TSRMLS_CC) ? ZEND_FETCH_GLOBAL : ZEND_FETCH_LOCAL;
+ op_array->vars[i].auto_global = NULL;
+ op_array->vars[i].fetch_type = zend_u_is_auto_global(type, name,
name_len, &(op_array->vars[i].auto_global) TSRMLS_CC) ? ZEND_FETCH_GLOBAL :
ZEND_FETCH_LOCAL;
return i;
}
@@ -383,6 +384,7 @@ void fetch_simple_variable_ex(znode *res
Z_TYPE(varname->u.constant) == IS_UNICODE) &&
!(Z_UNILEN(varname->u.constant) == (sizeof("this")-1) &&
ZEND_U_EQUAL(Z_TYPE(varname->u.constant),
Z_UNIVAL(varname->u.constant), Z_UNILEN(varname->u.constant), "this",
sizeof("this")-1)) &&
+ !zend_u_is_auto_global(Z_TYPE(varname->u.constant),
Z_UNIVAL(varname->u.constant), Z_UNILEN(varname->u.constant), NULL TSRMLS_CC) &&
(CG(active_op_array)->last == 0 ||
CG(active_op_array)->opcodes[CG(active_op_array)->last-1].opcode
!= ZEND_BEGIN_SILENCE)) {
result->op_type = IS_CV;
@@ -410,7 +412,7 @@ void fetch_simple_variable_ex(znode *res
if (varname->op_type == IS_CONST &&
(Z_TYPE(varname->u.constant) == IS_STRING ||
Z_TYPE(varname->u.constant) == IS_UNICODE)) {
- if (zend_u_is_auto_global(Z_TYPE(varname->u.constant),
Z_UNIVAL(varname->u.constant), Z_UNILEN(varname->u.constant) TSRMLS_CC)) {
+ if (zend_u_is_auto_global(Z_TYPE(varname->u.constant),
Z_UNIVAL(varname->u.constant), Z_UNILEN(varname->u.constant), NULL TSRMLS_CC)) {
opline_ptr->op2.u.EA.type = ZEND_FETCH_GLOBAL;
}
}
@@ -492,6 +494,29 @@ void fetch_array_dim(znode *result, znod
zend_op opline;
zend_llist *fetch_list_ptr;
+ zend_stack_top(&CG(bp_stack), (void **) &fetch_list_ptr);
+ if (fetch_list_ptr->count == 1) {
+ zend_llist_element *le = fetch_list_ptr->head;
+ zend_op *parentop = (zend_op*)le->data;
+
+ if (parentop && parentop->opcode == ZEND_FETCH_W &&
+ parent->op_type == IS_VAR && parentop->result.op_type
== IS_VAR && parent->u.var == parentop->result.u.var &&
+ parentop->op1.op_type == IS_CONST &&
+ (Z_TYPE(parentop->op1.u.constant) == IS_STRING ||
Z_TYPE(parentop->op1.u.constant) == IS_UNICODE) &&
+ !(Z_UNILEN(parentop->op1.u.constant) ==
(sizeof("this")-1) && ZEND_U_EQUAL(Z_TYPE(parentop->op1.u.constant),
Z_UNIVAL(parentop->op1.u.constant), Z_UNILEN(parentop->op1.u.constant), "this",
sizeof("this")-1)) ) {
+ /* Recompile CV and rewrite previous op to direct
FETCH_DIM */
+ zval tmp = parentop->op1.u.constant;
+ parentop->opcode = ZEND_FETCH_DIM_W;
+ parentop->op1.op_type = IS_CV;
+ parentop->op1.u.var = lookup_cv(CG(active_op_array),
Z_TYPE(tmp), Z_UNIVAL(tmp), Z_UNILEN(tmp) TSRMLS_CC);
+ parentop->op1.u.EA.type = 0;
+ parentop->op2 = *dim;
+ parentop->extended_value = ZEND_FETCH_STANDARD;
+ *result = parentop->result;
+ return;
+ }
+ }
+
init_op(&opline TS
