Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Address feature request #38917 for native SPKAC (HTML5 keygen element) support: ext/openssl/openssl.c ext/openssl/php_openssl.h ext/openssl/tests/openssl_spki_
hi, On Sun, May 12, 2013 at 12:18 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I'd to disagree. Besides the lack of testing (openssl is stable, or do we begin to say feature a is not and feature b is beta but everything else is stable?), the nightmare about what is available in which version is really not what we should do. Where's the nightmare? Each function is tagged with available version. Waiting for several years for a new function is not a good idea. php-next will be in a year, openssl can be released in pecl as well. There are many requests supporting this idea, incl. from 5.5 users, incl. 5.3. Can be released and actually released are two very different things. If we have somebody who commits to actually releasing it, with time table, etc. that would be different story. Not really, features freeze means features free, not less not much. We can't keep adding things endlessly and expect a release in a foreseeable period. Even then, with your model it means we'd be re-releasing every extension as PECL... Those with interest to have them in PECL. It works very well for some extensions already. And it is not my model :) Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] Internal operator overloading and GMP improvements
Hi internals! https://wiki.php.net/rfc/operator_overloading_gmp This RFC proposes to add operator overloading for INTERNAL classes. Furthermore it exemplarily implements the new API for GMP. Thanks, Nikita
Re: [PHP-DEV] [RFC] Internal operator overloading and GMP improvements
On 2013-05-12 19:25, Nikita Popov wrote: Hi internals! https://wiki.php.net/rfc/operator_overloading_gmp This RFC proposes to add operator overloading for INTERNAL classes. Furthermore it exemplarily implements the new API for GMP. IMO the proposal B is quite reasonable change, but the proposal A (i.e. the operator overloading part) is definitely an overkill. A simple benchmark should demonstrate that using GMP for basic arithmetic would kill performance in quite a brutal way. -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Internal operator overloading and GMP improvements
On Sun, May 12, 2013 at 7:50 PM, Antony Dovgal t...@daylessday.org wrote: On 2013-05-12 19:25, Nikita Popov wrote: Hi internals! https://wiki.php.net/rfc/operator_overloading_gmp This RFC proposes to add operator overloading for INTERNAL classes. Furthermore it exemplarily implements the new API for GMP. IMO the proposal B is quite reasonable change, but the proposal A (i.e. the operator overloading part) is definitely an overkill. A simple benchmark should demonstrate that using GMP for basic arithmetic would kill performance in quite a brutal way. Right, the difficulty here is to use it for large numbers only. It reduces the impact for standard ranges but do not totally suppress it. Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Internal operator overloading and GMP improvements
On Sun, May 12, 2013 at 7:50 PM, Antony Dovgal t...@daylessday.org wrote: On 2013-05-12 19:25, Nikita Popov wrote: Hi internals! https://wiki.php.net/rfc/**operator_overloading_gmphttps://wiki.php.net/rfc/operator_overloading_gmp This RFC proposes to add operator overloading for INTERNAL classes. Furthermore it exemplarily implements the new API for GMP. IMO the proposal B is quite reasonable change, but the proposal A (i.e. the operator overloading part) is definitely an overkill. A simple benchmark should demonstrate that using GMP for basic arithmetic would kill performance in quite a brutal way. I think this is a misunderstanding. I do not suggest to use GMP for all arithmetic and also do not suggest to auto-promote to GMP for large numbers. The operator overloading only comes into play if one of the operands is already a GMP instance. Regarding performance: The addition of the operator overloading does have a measurable impact on performance. The switch of GMP from resources to objects also does not show any clear change either way. What does become faster is if a gmp function gets a non-gmp argument and needs to cast it to GMP (this is faster because now only the mpz_t instance is created and not a full resource). Obviously when the overloaded operators are used rather than the functions it's faster too. Nikita
Re: [PHP-DEV] [RFC] Internal operator overloading and GMP improvements
On Sun, May 12, 2013 at 9:02 PM, Nikita Popov nikita@gmail.com wrote: I think this is a misunderstanding. I do not suggest to use GMP for all arithmetic and also do not suggest to auto-promote to GMP for large numbers. The operator overloading only comes into play if one of the operands is already a GMP instance. Regarding performance: The addition of the operator overloading does have a measurable impact on performance. Ooops, that was a typo. I wanted to say does NOT have a measurable impact on performance. The switch of GMP from resources to objects also does not show any clear change either way. What does become faster is if a gmp function gets a non-gmp argument and needs to cast it to GMP (this is faster because now only the mpz_t instance is created and not a full resource). Obviously when the overloaded operators are used rather than the functions it's faster too. I tweaked the implementation a bit and now it seems to be faster in any case. I added some numbers in https://wiki.php.net/rfc/operator_overloading_gmp#performance Nikita
Re: [PHP-DEV] [RFC] Internal operator overloading and GMP improvements
Are we ignoring the ZEND_IS_SMALLER issue?
if ($gmp 123) { ... }
There's no ZEND_IS_GREATER opcode, so it gets quietly turned into:
if (123 $gmp) { ... }
Which will be confusing.
I dealt with this in operator by having the user apply a patch before
building:
https://github.com/php/pecl-php-operator/blob/master/compare-greater-5.1.2.diff
If we're going to bake this into ZE, then we should just add
ZEND_IS_GREATER(_OR_EQUAL) opcode.
-Sara
On Sun, May 12, 2013 at 12:02 PM, Nikita Popov nikita@gmail.com wrote:
On Sun, May 12, 2013 at 7:50 PM, Antony Dovgal t...@daylessday.org
wrote:
On 2013-05-12 19:25, Nikita Popov wrote:
Hi internals!
https://wiki.php.net/rfc/**operator_overloading_gmp
https://wiki.php.net/rfc/operator_overloading_gmp
This RFC proposes to add operator overloading for INTERNAL classes.
Furthermore it exemplarily implements the new API for GMP.
IMO the proposal B is quite reasonable change, but the proposal A (i.e.
the operator overloading part) is definitely an overkill.
A simple benchmark should demonstrate that using GMP for basic arithmetic
would kill performance in quite a brutal way.
I think this is a misunderstanding. I do not suggest to use GMP for all
arithmetic and also do not suggest to auto-promote to GMP for large
numbers.
The operator overloading only comes into play if one of the operands is
already a GMP instance.
Regarding performance: The addition of the operator overloading does have a
measurable impact on performance. The switch of GMP from resources to
objects also does not show any clear change either way. What does become
faster is if a gmp function gets a non-gmp argument and needs to cast it to
GMP (this is faster because now only the mpz_t instance is created and not
a full resource). Obviously when the overloaded operators are used rather
than the functions it's faster too.
Nikita
Re: [PHP-DEV] [RFC] Internal operator overloading and GMP improvements
On Sun, May 12, 2013 at 9:57 PM, Sara Golemon poll...@php.net wrote:
Are we ignoring the ZEND_IS_SMALLER issue?
Not ignoring it :) It's mentioned in one sentence: The operators , =, [...]
are indirectly supported by the following compiler transformations: [...]
if ($gmp 123) { ... }
There's no ZEND_IS_GREATER opcode, so it gets quietly turned into:
if (123 $gmp) { ... }
Which will be confusing.
Why would this be confusing? I'd agree if this happened in userland (people
could wonder why the operators are swapped), but internally we are already
dealing with this anyway. E.g. when you implement compare_objects you have
to be aware of this (to understand stuff like the return 1 trick).
I dealt with this in operator by having the user apply a patch before
building:
https://github.com/php/pecl-php-operator/blob/master/compare-greater-5.1.2.diff
If we're going to bake this into ZE, then we should just add
ZEND_IS_GREATER(_OR_EQUAL) opcode.
Not sure this is really necessary, but I have no problem with doing that
either.
Nikita
Re: [PHP-DEV] [RFC] Internal operator overloading and GMP improvements
Hi! Why would this be confusing? I'd agree if this happened in userland (people could wonder why the operators are swapped), but internally we are already dealing with this anyway. E.g. when you implement compare_objects you have to be aware of this (to understand stuff like the return 1 trick). Your code suggests (even though RFC never says it) that the left operand defines the comparison. However, for the switched operations, the right operand would then define the comparison. It is pretty confusing, IMO. -- 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] [RFC] Internal operator overloading and GMP improvements
Why would this be confusing? I'd agree if this happened in userland (people could wonder why the operators are swapped), but internally we are already dealing with this anyway. E.g. when you implement compare_objects you have to be aware of this (to understand stuff like the return 1 trick). Your code suggests (even though RFC never says it) that the left operand defines the comparison. However, for the switched operations, the right operand would then define the comparison. It is pretty confusing, IMO. This. I see in zend_object_do_operation that op1 (LHS) has priority, but if it's not an object, then op2(RHS) gets the chance to handle it. So it works fine in the simple case of (Object and Non-Object), but if you have two different Objects, both implementing operator overloading in potentially different ways then the precedence order matters more. By having a separate opcode for GREATER, the user can explicitly state who they want to get precedence. I realize I'm potentially trying to solve a problem which doesn't exist, but separating out smaller/greater is a fairly trivial change, so I'd rather we did it now and avoid potential fail. -Sara
Re: [PHP-DEV] Re: [PHP-CVS] com php-src: Address feature request #38917 for native SPKAC (HTML5 keygen element) support: ext/openssl/openssl.c ext/openssl/php_openssl.h ext/openssl/tests/openssl_spki_
Hi! Not really, features freeze means features free, not less not much. We can't keep adding things endlessly and expect a release in a foreseeable period. You seem not have misunderstood me, I was talking about 5.5.1, i.e. post 5.5.0 release. Those with interest to have them in PECL. It works very well for some extensions already. And it is not my model :) Having some extensions in PECL doesn't help getting somebody to maintain this specific one in PECL. If that is happening - tell me who's doing it, then my position would be different. -- 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] [RFC] Internal operator overloading and GMP improvements
Hi Nikita, The patch looks quite good. However, it must slow down each comparison operator (even if it compares two integers). I would suggest overloading of CMP operator instead of separate , =, ==, !=, , =. Also it may make sense to think about overloading of unary operators to provide a solid decision. In case you think about user-level operator overloading in the future (that may make sense :) it would be better to design them all together. Thanks. Dmitry. On Sun, May 12, 2013 at 7:25 PM, Nikita Popov nikita@gmail.com wrote: Hi internals! https://wiki.php.net/rfc/operator_overloading_gmp This RFC proposes to add operator overloading for INTERNAL classes. Furthermore it exemplarily implements the new API for GMP. Thanks, Nikita
