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
>
