Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67407
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.220.43 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <CAF+90c_qj9_GcqhYSBRnbYLBJ-31iBSUTdnVn8owWJxpzqRedQ@mail.gmail.com>
References: <CAF+90c_PPTajBqs636f373DKF=hotrK1ObTojddxx=bxC3g16w@mail.gmail.com>
	<518FD653.6070705@daylessday.org>
	<CAF+90c_qj9_GcqhYSBRnbYLBJ-31iBSUTdnVn8owWJxpzqRedQ@mail.gmail.com>
Date: Sun, 12 May 2013 12:57:07 -0700
Message-ID: <CAESVnVov7hyt=AW+XwB2z6Jf3870bJO5DcnFTb7o66FN3Ds1TA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Antony Dovgal <tony@daylessday.org>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec52162f316b07a04dc8ace20
Subject: Re: [PHP-DEV] [RFC] Internal operator overloading and GMP improvements
From: pollita@php.net (Sara Golemon)

--bcaec52162f316b07a04dc8ace20
Content-Type: text/plain; charset=ISO-8859-1

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
>

--bcaec52162f316b07a04dc8ace20--