Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82732
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAPwsocGWQzzmv_QXZj5786_i72rkFH3_ZJiXddSHhHYKnYnTbA@mail.gmail.com>
References: <6FD9B9A4-E831-4D4F-AD66-BD04D8C37991@ajf.me>
	<CAPwsocEiBZ4T+cBE_-FOfURxDwGK10ORZwjMSYbtDG9WgxVT_w@mail.gmail.com>
	<7472A723-0408-4928-B06D-F0A1CE62EC73@ajf.me>
	<CAPwsocGWQzzmv_QXZj5786_i72rkFH3_ZJiXddSHhHYKnYnTbA@mail.gmail.com>
Date: Sun, 15 Feb 2015 18:51:21 +0100
Message-ID: <CAEZPtU7Ujy8CsD_ramoxb=9FTPuTSKtoMcWdb3mgdjvCZN6aDw@mail.gmail.com>
To: Leigh <leight@gmail.com>
Cc: Andrea Faulds <ajf@ajf.me>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] Big Integer Support
From: pierre.php@gmail.com (Pierre Joye)

On Sun, Feb 15, 2015 at 6:42 PM, Leigh <leight@gmail.com> wrote:
> On 15 February 2015 at 13:51, Andrea Faulds <ajf@ajf.me> wrote:
>>> Extensions "that deal with numbers" are all going to need updating. So
>>> probably every extension?
>>
>> Anything accepting a zval rather than a long through zpp, but the change=
s are quite small in most cases. It=E2=80=99s a much smaller change than, s=
ay, what phpng did.
>
> The real-world performance gains of ng are significant. Everything is
> a trade-off. Having to change exts because the guys behind ng have
> made (potentially) "80% of all websites" faster is acceptable - in my
> opinion.

Let be serious here, the zpp changes be for 7 (pls stop calling that
ng, it is 7 now :) or for this RFC is irrelevant. An ext wants to
support bigint? fine. It can't? Then it will fail or cast with warning
or notice.

>>> You talk about eventually deprecating ext/gmp and moving it to PECL.
>>> Definitely not acceptable.
>>
>> I *talk* about it. I=E2=80=99m not saying we=E2=80=99ll do it. It=E2=80=
=99s a future possibility: since it would be made largely redundant by larg=
e integer support in core, we might eventually get rid of it.
>>
>> I said =E2=80=9Cmight=E2=80=9D because it=E2=80=99s not part of the prop=
osal, it is merely a thought.
>
> The GMP ext offers a lot more than arbitrary precision arithmetic.
> There's a slew of functions there that go hand in hand with big ints
> and their applications. gmp_inverse, gmp_powm and gmp_rootrem to name
> a few. There are applications, both proprietary and open that depend
> on these. I'd personally be willing to help bring more functionality
> to ext/gmp rather than lose all of these important functions to PECL.

Fully agree, gmp allows more. And it should not be removed. While
"native" bigint support is really handy and I can see many benefits.
Using GMP for other features remain important.

>>> Sorry, the fixed size integer data type is far too baked-in and
>>> useful.
>>
>> I could understand your perspective if PHP had modular arithmetic like C=
 and such, but it doesn=E2=80=99t. So I don=E2=80=99t understand why it is =
=E2=80=9Cfar too useful=E2=80=9D - what usefulness is being lost by extendi=
ng its range?
>
> Among other thing the behaviour of overflow and shift operations are
> well documented and understood quirks of fixed size integer types.

Does that mean it should not be improved? Aka more obvious and less quirky?


>>> I don't see any gain from this patch except hidden performance
>>> penalties, breaks, and extra work for everyone in maintaining it and
>>> other extensions. I'd rather big int usage was kept verbose and
>>> conscious.
>>
>> I see a clear gain: we clean up almost every integer overflow edge case,=
 integer overflow handling is more intuitive, we support large integers saf=
ely on 32-bit, and we don=E2=80=99t require you to use a weird extension th=
at may crash the PHP interpreter and DoS your web host in order to do large=
 number arithmetic.
>
> A weird extension? The base library of which you are using to back
> your big int implementation.

I agree here too. gmp is just fine. I see this RFC as a different
thing. Having bigint support in the engine makes sense regardless of
gmp. Other languages have it and are very happy with that. It is
simply way easier and cleaner to use than relying on an ext (while
Nikita's patch for operators overloading for exts makes things
better).

Cheers,
--=20
Pierre

@pierrejoye | http://www.libgd.org