Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81717
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 192.64.116.208 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
In-Reply-To: <CAPwsocFQgZy9WDGjG6PQ+mUvwYkzS69n0s-Uw5yCYveGK1OYZQ@mail.gmail.com>
Date: Tue, 3 Feb 2015 14:49:27 +0000
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <3B265E0A-7479-456A-B134-5CA607C68EFF@ajf.me>
References: <CAPwsocEjjJPkUvihYdj8tNRrf3XQ9WJzT=1Er6gjLs2MMgHwsw@mail.gmail.com> <1D8DC03D-0E2C-494C-9ED2-244334F57D8A@ajf.me> <CAPwsocHACBzYg8L5O3s2r=BGDrhe4VaLNTFmCX=rz_4_rpRFZw@mail.gmail.com> <6E8210CD-4BA3-4694-8482-4803F562D77C@ajf.me> <CAPwsocFgHY3B-0dt6QWSmLJOgEvcBwtE1rSHXWrRh44jAv_u0w@mail.gmail.com> <1BEEF374-D8BC-4FE2-8CE0-5EBB1AC4CF04@ajf.me> <CAPwsocFQgZy9WDGjG6PQ+mUvwYkzS69n0s-Uw5yCYveGK1OYZQ@mail.gmail.com>
To: Leigh <leight@gmail.com>
Subject: Re: [PHP-DEV] Zero-fill right shift.
From: ajf@ajf.me (Andrea Faulds)

Hi,

> On 3 Feb 2015, at 14:43, Leigh <leight@gmail.com> wrote:
>=20
> On 3 February 2015 at 14:36, Andrea Faulds <ajf@ajf.me> wrote:
>> I don=E2=80=99t know where you got that idea. The binary ops are =
consistent - they aren=E2=80=99t constrained by register size like in =
previous PHP versions, but they=E2=80=99re still completely consistent.
>>=20
>=20
> php -r 'var_dump(1 << 65);'
> int(2)
>=20
> Rotate left gets broken.

It=E2=80=99s not =E2=80=9Cbroken=E2=80=9D, the behaviour is just =
different to account for it now being an arbitrary-precision type. If =
you want to =E2=80=9Crotate left=E2=80=9D, bitmasking does exist.

>=20
>> It=E2=80=99s slower, yes, but that hardly matters. If people care so =
much about performance, why use PHP?
>>=20
>=20
> If people didn't care about performance, we wouldn't have phpng, or
> any of the other work people have done to make the engine faster.
>=20
> Sometimes you have to make the most of what you have available.

OK, performance is not unimportant. But in most cases, =
arbitrary-precision integers are not going to be a bottleneck for your =
web app.

Also, the bigint changes only affect you if you=E2=80=99re dealing with =
large integers anyway. If you want to preserve the horrid float =
promotion behaviour, you can do so explicitly. But I think in most =
cases, it=E2=80=99s better to trade off performance for lack of data =
loss.

--
Andrea Faulds
http://ajf.me/