Re: [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.ppv@gmail.com> wrote: > On Sun, May 12, 2013 at 7:50 PM, Antony Dovgal <tony@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 >