Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
Following the discussion at the end of last week, I prepared a draft RFC for the inclusion of Optimizer+ in PHP. In parallel we’re in the process of prepping the source code for independent public consumption, which I hope we can be done with by the end of next week, hopefully sooner.
Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP distribution
On 29/01/13 08:03, Zeev Suraski wrote: Following the discussion at the end of last week, I prepared a draft RFC for the inclusion of Optimizer+ in PHP. In parallel we’re in the process of prepping the source code for independent public consumption, which I hope we can be done with by the end of next week, hopefully sooner. It's great news that Zend Technologies has decided to open-source Optimizer+ and given that it is now the end of next week I look forward to seeing on this code any day. So thanks to you for this decision. But now to specific comments on your RFC. 1. Scope of the RFC. IMO, the RFC covers four separate issues that would be easier to review, refine and agree if they were kept separate: a. Zend's decision to OS+. This is entirely within Zend Technology Inc. and outside the scope of any RFC. b. The establishment and proper architecture and support of an opcode-cache interface within the Zend Execution Engine (EE). I will discuss this below. c. The decision to include Optimizer+ as a core extension within the PHP project. However as at the time of this draft only Zend employees -- and selected Zend-approved 2nd parties who have signed the appropriate NDAs -- have access to the Optimizer+ source and are therefore able to review its content. Surely such open access is a precondition, and it makes no sense to issue an RFC to inform this decision until at least a few months after the source has been made widely available for review. d. The project decision to give any specific opcode-cache extension a preferred status over the alternative opcode-caches. Such a decision is going to be contentious and -- unless carefully, transparently and fairly managed -- could lead to conflict within the project. Not good. So I would suggest that the RFC limit itself to non-contentious claims relating to one optimizer performance over another. 2. The Detailed Content The Introduction will need redrafting depending on the proposed / revised scope of this RFC. Some form of definition / description of both a PHP opcode-cache and PHP data-cache needs including in the PHP wiki, but this would sit better under the https://wiki.php.net/internals hierarchy. This RFC should simply wiki-link to this page on the first use of [[opcode cache]]. The Interaction with other extensions and plugins section is surely a general statement of requirement that should apply to _any_ opcode cache and not just Optmizer+, so again this content belongs in separate Wiki a document with a wiki-link here. The Alternatives is really a Comparison of APC and Optimizer+ and I suggest that some points are contentious. The same point applies to the remaining sections. Surely this sort of comparison only becomes necessary when we've reach a stage where we are asking voters to choose a preferred cache, and in that case wouldn't be more appropriate to agree the selection / assessment criteria first before carrying out a selection exercise? 3. Why do I suggest an Opcode-Cache interface RFC? The current Zend 2.x engines provide some hooks which enable the main opcode caches -- including Optimizer+ and APC -- to deliver accelerated performance for many application usecases. However, some aspects of hooking an opcode cache into the Zend EE remain a somewhat of a compromise. These include: a. The management of early vs. late binding and the work-arounds that opcode caches must do to back-out unwanted early binding. b. Some essential functions that the caches must hook into are not exposed as hooks (like zend_compile_file) and are sometime implemented using static functions, leading to the cache needing to reimplement chunks of zend code. c. There should be a clear scoping separation of what the (cached) compile does and what the EE does. An example of where this is mixed is in the ZEND_INCLUDE_OR_EVAL_xxx_HANDLER functions which resolve paths and open source files in the case of the xxx_once functions. This file access is usually unnecessary in the case of cached files as the op-code cache has already cached the relevant information. Given that opcode caches are now core to PHP performance, it should be possible to implement a cache using hooks and interfaces exported through a Zend header file and without recoding bits of the engine. Optimizer+ should be an exemplar of such an approach. Regards Terry Ellison
[PHP-DEV] double val to long val conversion issue
About
http://git.php.net/?p=php-src.git;a=commitdiff;h=79956330fe17cfd5f60de456497541b21a89bddf
(For now, I have reverted this fix)
Here some explanations.
LONG_MAX is 9223372036854775807 (0x7fff)
double representation of LONG_MAX is 9223372036854775808
(d LONG_MAX) is evaluated in double space.
So is false for double which have the same value than (double)LONG_MAX.
So, for (double)LONG_MAX the cast used is
(long)d
9223372036854775807 on ppc64
9223372036854775808 on x86_64 (gcc without optimization)
9223372036854775807 on x86_64 (gcc -O2)
PHP expected value is 9223372036854775808
(Btw, I don't understand why PHP, build on x86_64, with -O2, gives the
good result, some environment mystery)
Obviously, we could have different result on different platform,
compiler, architecture.
I will be very interested by result on other platform (mac, windows),
compiler (Visual C), architecture.
If we switch to the unsigned cast:
(long)(unsigned long)d;
The result is always 9223372036854775808 (which is expected)
So my proposal, is to use the unsigned cast for (double)LONG_MAX value.
- if (d LONG_MAX) {
+ if (d = LONG_MAX) {
From my tests, this doesn't change anything on x86_64, and improves
ppc64 (same result, so at least 9 unit tests succeed)
Any comments ?
If you agree, I will apply this patch again.
Regards,
Remi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] double val to long val conversion issue
Le 09/02/2013 16:10, Remi Collet a écrit : http://git.php.net/?p=php-src.git;a=commitdiff;h=79956330fe17cfd5f60de456497541b21a89bddf Also see https://bugs.php.net/bug.php?id=64142 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] double val to long val conversion issue
hi Remi On Sat, Feb 9, 2013 at 4:10 PM, Remi Collet r...@fedoraproject.org wrote: About http://git.php.net/?p=php-src.git;a=commitdiff;h=79956330fe17cfd5f60de456497541b21a89bddf (For now, I have reverted this fix) Here some explanations. LONG_MAX is 9223372036854775807 (0x7fff) double representation of LONG_MAX is 9223372036854775808 (d LONG_MAX) is evaluated in double space. So is false for double which have the same value than (double)LONG_MAX. So, for (double)LONG_MAX the cast used is (long)d 9223372036854775807 on ppc64 9223372036854775808 on x86_64 (gcc without optimization) 9223372036854775807 on x86_64 (gcc -O2) PHP expected value is 9223372036854775808 (Btw, I don't understand why PHP, build on x86_64, with -O2, gives the good result, some environment mystery) Obviously, we could have different result on different platform, compiler, architecture. I will be very interested by result on other platform (mac, windows), compiler (Visual C), architecture. If we switch to the unsigned cast: (long)(unsigned long)d; Any comments ? IIRC, on windows/visualC, no matter if it is x86 or x64, long is always 32bits, so it won't change the size of long. Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] patch for pdo_stmt and other pdo drivers
I need a review for this patch , it is correct or the right way https://bugs.php.net/bug.php?id=63356 ps: i asked to break the patch in multiple patches so it can be easier to be applied and reviewed -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] double val to long val conversion issue
On 09/02/13 15:47, Pierre Joye wrote: hi Remi On Sat, Feb 9, 2013 at 4:10 PM, Remi Collet r...@fedoraproject.org wrote: About http://git.php.net/?p=php-src.git;a=commitdiff;h=79956330fe17cfd5f60de456497541b21a89bddf (For now, I have reverted this fix) Here some explanations. LONG_MAX is 9223372036854775807 (0x7fff) double representation of LONG_MAX is 9223372036854775808 (d LONG_MAX) is evaluated in double space. So is false for double which have the same value than (double)LONG_MAX. So, for (double)LONG_MAX the cast used is (long)d 9223372036854775807 on ppc64 9223372036854775808 on x86_64 (gcc without optimization) 9223372036854775807 on x86_64 (gcc -O2) PHP expected value is 9223372036854775808 (Btw, I don't understand why PHP, build on x86_64, with -O2, gives the good result, some environment mystery) Obviously, we could have different result on different platform, compiler, architecture. I will be very interested by result on other platform (mac, windows), compiler (Visual C), architecture. If we switch to the unsigned cast: (long)(unsigned long)d; Any comments ? IIRC, on windows/visualC, no matter if it is x86 or x64, long is always 32bits, so it won't change the size of long. See http://en.wikipedia.org/wiki/LLP64#64-bit_data_models for a good description of this mess. AFAIK many packages that target both 32 and 64 bit environments MS and *nix, define explicitly adopt XXX_int32, XXX_uint32, XXX_int64, XXX_uint64, ... datatypes and use wrappers to map these onto the appropriate visualC / gcc types. As far as I can see, PHP doesn't and seems to use long and int almost interchangeably which causes problems as LP64/I32LP64 and LLP64/IL32P64 are very different. This is one reason for 64-bit support on Windows being problematic. It would be good for PHP to have a road map to removed data model-specific potholes, say by 5.6 or 5.7. //Terry
[PHP-DEV] Re: [PHP] Is header() malfunction due to PHP5.3.3 - 5.4.11 transition?
On Sat, Feb 9, 2013 at 3:59 PM, Tedd Sperling t...@sperling.com wrote: On Feb 9, 2013, at 2:00 PM, Jonathan Eagle jeo...@attglobal.net wrote: Jonathan: No offense to your routine, but you may want to review this: http://sperling.com/php/authorization/log-on.php If anyone finds an error, please post. After successfully logging in, the session id should be regenerated to prevent session fixation: http://php.net/manual/en/function.session-regenerate-id.php http://shiflett.org/articles/session-fixation Requests should be sent over https to prevent session hijacking (if you'd rather avoid paying for a cert for your site, you could just document this): http://stackoverflow.com/questions/22880/what-is-the-best-way-to-prevent-session-hijacking http://php.net/manual/en/function.session-set-cookie-params.php Even though this isn't a big deal for an example that only makes use of one password, and that password isn't likely one that you reuse anywhere else, for the sake of educating the masses, salting the password would be a nice addition: https://github.com/ircmaxell/password_compat https://gist.github.com/nikic/3707231 Adam -- Nephtali: A simple, flexible, fast, and security-focused PHP framework http://nephtaliproject.com
Re: [PHP-DEV] double val to long val conversion issue
Hi! these onto the appropriate visualC / gcc types. As far as I can see, PHP doesn't and seems to use long and int almost interchangeably which PHP indeed does not use fixed-size types in zvals, etc. but it definitely does not use long and int almost interchangeably. In almost any place where int is used instead of long or vice versa (unless it is a specific small value that is nowhere near limits of either int or long and used in very restricted context) - it is a bug and should be fixed. If you know of such places, please name them or even better, submit a bug report pointing them out. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] double val to long val conversion issue
Hi! About http://git.php.net/?p=php-src.git;a=commitdiff;h=79956330fe17cfd5f60de456497541b21a89bddf (For now, I have reverted this fix) Here some explanations. LONG_MAX is 9223372036854775807 (0x7fff) double representation of LONG_MAX is 9223372036854775808 I see what's going on here. We have precision loss due to the fact that the range of double (53 bits) is smaller than the range of long (63 bits) on 64-bit system. When it's converted back to long, I guess it has to be expanded back to 63 bits. 9223372036854775807 on ppc64 9223372036854775808 on x86_64 (gcc without optimization) 9223372036854775807 on x86_64 (gcc -O2) PHP expected value is 9223372036854775808 Not sure how value of long can be expected to be 9223372036854775808 - 9223372036854775808 is not representable in signed long. If you do (long)(unsigned long), you'd get -9223372036854775808. (Btw, I don't understand why PHP, build on x86_64, with -O2, gives the good result, some environment mystery) With -O2, gcc probably pre-calculates the result of the operation if you use simple test program. So, if I write: double b = LONG_MAX; printf(%ld, (long)b); Then without -O2, I'm getting: movsd -16(%rbp), %xmm0 cvttsd2siq %xmm0, %rsi But with -O2, it's just: movabsq $9223372036854775807, %rsi So the difference in results may stem from the fact that the calculations go in different way here. Obviously, we could have different result on different platform, compiler, architecture. I will be very interested by result on other platform (mac, windows), compiler (Visual C), architecture. If we switch to the unsigned cast: (long)(unsigned long)d; The result is always 9223372036854775808 (which is expected) Wait, long can not be 9223372036854775808, how the result of long conversion can be that? From my tests, this doesn't change anything on x86_64, and improves Well, for the value of (double)LONG_MAX the code actually changes substantially, and if I test this code: double b = LONG_MAX; printf(%ld %ld, (long)(unsigned long)b, (long)b); Then with -O2 I get different results: -9223372036854775808 9223372036854775807 But that may be an optimization artifact. With real PHP, the result of converting 9223372036854775807 to double and then back to int seems to always be -9223372036854775808 on Intel, with or without the patch. I don't have access to ppc64 machine so no idea what's going on there. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] double val to long val conversion issue
On 10/02/13 03:25, Stas Malyshev wrote: these onto the appropriate visualC / gcc types. As far as I can see, PHP doesn't and seems to use long and int almost interchangeably which PHP indeed does not use fixed-size types in zvals, etc. but it definitely does not use long and int almost interchangeably. In almost any place where int is used instead of long or vice versa (unless it is a specific small value that is nowhere near limits of either int or long and used in very restricted context) - it is a bug and should be fixed. If you know of such places, please name them or even better, submit a bug report pointing them out. Stan, you are right to correct me. Sorry. However, I still feel that the implicit assumption is that sizeof(long) == 2*sizeof(int) and this isn't the case with visualC, and PHP internal data structures compiled with visualC and gcc are significantly different; for example hash keys are 32 bits long on Windows and 64bits on *nix. Why aren't they 32bits, say, on both? (as there is no performance benefit is having 64bit hash keys when the maximum size of a hash table is an int).
Re: [PHP-DEV] double val to long val conversion issue
Hi! Stan, you are right to correct me. Sorry. However, I still feel that the implicit assumption is that sizeof(long) == 2*sizeof(int) and this I'm not sure where this assumption exists. Could you be more specific? PHP uses long for most integer values, and int for some internal things and sometimes those intersect, but usually there is either conversion or we can be pretty sure the value, while being nominally long, is in range of int (such as when it is an option with fixed set of values, etc.). However, there were certainly bugs in the past in this area, and may be still some, so eliminating them of course would be good. But right know I don't know of any code that makes this specific assumption. isn't the case with visualC, and PHP internal data structures compiled with visualC and gcc are significantly different; for example hash keys are 32 bits long on Windows and 64bits on *nix. Why aren't they 32bits, Yes, they are different, because long size is different, and PHP uses long (more specific, ulong) to store hash values. This is because numeric values are long, and it's easier to use the same type for both than bother with converting back and forth. As you noted, the difference for hashing is minimal since the value is anyway brought to hash size, and hashes of size more than 32-bit LONG_MAX aren't very practical. However, it matters in other parts of the code. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] double val to long val conversion issue
Le 10/02/2013 05:54, Stas Malyshev a écrit : Hi! About http://git.php.net/?p=php-src.git;a=commitdiff;h=79956330fe17cfd5f60de456497541b21a89bddf (For now, I have reverted this fix) Here some explanations. LONG_MAX is 9223372036854775807 (0x7fff) double representation of LONG_MAX is 9223372036854775808 I see what's going on here. We have precision loss due to the fact that the range of double (53 bits) is smaller than the range of long (63 bits) on 64-bit system. When it's converted back to long, I guess it has to be expanded back to 63 bits. 9223372036854775807 on ppc64 9223372036854775808 on x86_64 (gcc without optimization) 9223372036854775807 on x86_64 (gcc -O2) PHP expected value is 9223372036854775808 Not sure how value of long can be expected to be 9223372036854775808 - 9223372036854775808 is not representable in signed long. If you do (long)(unsigned long), you'd get -9223372036854775808. Yes; I mean -9223372036854775808 (0x8000) (sorry, I have use %lu format instead of %ld in my tests) (Btw, I don't understand why PHP, build on x86_64, with -O2, gives the good result, some environment mystery) With -O2, gcc probably pre-calculates the result of the operation if you use simple test program. So, if I write: double b = LONG_MAX; printf(%ld, (long)b); Then without -O2, I'm getting: movsd -16(%rbp), %xmm0 cvttsd2siq %xmm0, %rsi But with -O2, it's just: movabsq $9223372036854775807, %rsi So the difference in results may stem from the fact that the calculations go in different way here. Obviously, we could have different result on different platform, compiler, architecture. I will be very interested by result on other platform (mac, windows), compiler (Visual C), architecture. If we switch to the unsigned cast: (long)(unsigned long)d; The result is always 9223372036854775808 (which is expected) Wait, long can not be 9223372036854775808, how the result of long conversion can be that? Yes, -9223372036854775808 (0x8000) From my tests, this doesn't change anything on x86_64, and improves Well, for the value of (double)LONG_MAX the code actually changes substantially, and if I test this code: double b = LONG_MAX; printf(%ld %ld, (long)(unsigned long)b, (long)b); Then with -O2 I get different results: -9223372036854775808 9223372036854775807 But that may be an optimization artifact. Yes I also think. But is this couldn't occurs in real PHP, with another compiler or another gcc version ? With real PHP, the result of converting 9223372036854775807 to double and then back to int seems to always be -9223372036854775808 on Intel, with or without the patch. I don't have access to ppc64 machine so no idea what's going on there. That's exactly the problem. On Intel, we always get -9223372036854775808 (when 9223372036854775807 could be expected, with -O2, from you previous test) On ppc64, we always get 9223372036854775807. This is exactly what I'd like to fix. And, as you said, the patch doesn't change result on Intel. I could make this change conditionnal on PPC, but I think it will also protect us from any compiler optimization change. Remi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] double val to long val conversion issue
One more test (to get rid of compiler optimization)
int main (int argc, char *argv[]) {
double d;
if (argc1 sscanf(argv[1], %lg, d)) {
printf( double=%.20lg\n, d);
printf( signed=%lx\n, (long)d);
printf(unsigned=%lx\n, (unsigned long)d);
}
return 0;
}
On x86_64 (so, with or without -O2)
$ gcc -O2 -Wall math2.c -o math2 ./math2 9223372036854775807
double=9223372036854775808
signed=8000
unsigned=8000
On ppc64
$ gcc -O2 -Wall math2.c -o math2 ./math2 9223372036854775807
double=9223372036854775808
signed=0x7f
unsigned=8000
Remi.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
