Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78277
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.218.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <EBBCF759-F622-4903-9821-DE3C63CD142A@ajf.me>
References: <8C47FA53-0964-49C0-963C-332A936348A5@ajf.me>
	<CA+9eiLuOcd-u_kzu+MZM71Ns_-9vsSbifFF5x9Q1b4k0NV12Wg@mail.gmail.com>
	<F41D165E-A2FB-4423-BF8F-6F6B5F4E201E@ajf.me>
	<68229C26-4EEC-49DC-BA05-D5AC9728D1E8@ajf.me>
	<CA+9eiLvh9RFVmYD1_y0AU0NVkkxYTfjv_C6H4tN8RH-w7X7M1g@mail.gmail.com>
	<EBBCF759-F622-4903-9821-DE3C63CD142A@ajf.me>
Date: Thu, 23 Oct 2014 19:22:18 +0400
Message-ID: <CA+9eiLv6MQjvqe2XXQjpUF1PjaNgPMYOoUmVDR3qZLkcjTd+SA@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113ce1f852b464050618a12e
Subject: Re: [PHP-DEV] [RFC] Big Integer Support
From: dmitry@zend.com (Dmitry Stogov)

--001a113ce1f852b464050618a12e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 23, 2014 at 5:50 PM, Andrea Faulds <ajf@ajf.me> wrote:

> Hi!
>
> > On 23 Oct 2014, at 13:47, Dmitry Stogov <dmitry@zend.com> wrote:
> >
> > Hi Andrea,
> >
> > The synthetic benchmarks are not always reflect the impact on real-life
> performance.
> >
> > Unfortunately, I wasn't able to run any big real-life apps with your
> bigint branch, because it misses support for commonly used extensions
> (ext/session, ext/json, ext/pdo).
>
> Yes, that=E2=80=99s unfortunate. ext/json is first on my list to update o=
nce I=E2=80=99m
> done with ext/standard, I particularly want large integers in JSON to
> decode to bigints (though allow disabling this if you desire). I really
> should=E2=80=99ve finished porting ext/standard months ago, I=E2=80=99ve =
been dragging my
> heels on that one.
>
> > I ran bench.php and it's a bit slower with bigint.
> >
> > master 1.210 sec
> > bigint   1.330 sec
> >
> > I also measured the number of executed instructions using valgrind
> --tool=3Dcallgrind (less is better)
> >
> > master  1,118M
> > bigint    1,435M
> >
> > May be part of this difference is caused by missing latest master
> improvements, but anyway, introducing new core type, can't be done for fr=
ee.
>
> I=E2=80=99m not really sure about whether a new core type can=E2=80=99t b=
e free. For
> switch statements, if they=E2=80=99re compiled to a jump table, they shou=
ldn=E2=80=99t be
> any slower when a new case is added. But I=E2=80=99m not certain on that,=
 I don=E2=80=99t
> spend much time reading generated asm.
>
> Does bench.php do any float operations? I=E2=80=99m not sure from reading=
 the
> source, but I think it might end up having ints overflow and become float=
s
> in master or bigints in my branch. If that=E2=80=99s the case, it would o=
bviously
> be slower as bigints trade performance for accuracy. This particular issu=
e
> can=E2=80=99t really be helped. Although these apps, if they want floats,=
 can just
> ask for them explicitly by marking their numbers with a dot.
>

bench.php does some math on long and floats, but I don't think overflow is
involved.


>
> Another source of slowdown is, as previously mentioned, the asm functions
> not being updated and hence me having to disable them. Particularly for
> things like multiplication, addition and so on, the C code we have is far
> less efficient. I believe the asm code simply checks for an overflow flag
> after the operation, which should be very fast.


yes, this may be a reason.


> On the other hand, the C code converts the ints to doubles, does a double
> operation, sees if the result of that is greater than PHP_INT_MAX convert=
ed
> to a double, and *then* does the operation if it won=E2=80=99t overflow. =
This means
> that, until the asm code is updated, all integer operations may be
> significantly slower, which is unfortunate. However, I think that if the
> asm were to be updated, the slowdown for integer ops would completely, or
> at least mostly, disappear.
>
> > I also was able to run qdig, and it showed about 2% slowdown.
> >
> > [master] $ sapi/cgi/php-cgi -T 1000 /var/www/html/bench/qdig/index.php =
>
> /dev/null
> > Elapsed time: 3.327445 sec
> >
> > [bigint] $ sapi/cgi/php-cgi -T 1000 /var/www/html/bench/qdig/index.php =
>
> /dev/null
> > Elapsed time: 3.382823 sec
> >
> > It would be great to measure the difference on wordpress, drupal, ZF=E2=
=80=A6
>
> The reasons for the dig slowdown are likely the same.
>

2% is not a big difference (it may be even a measurement mistake), but more
tests should be done.


>
> --
>
> I=E2=80=99ve so far been scared to touch the asm=E2=80=A6 but actually, I=
 don=E2=80=99t think it
> could be *that* hard. It=E2=80=99s not doing something especially complex=
. The
> bigint API looks fairly stable now and I=E2=80=99m unlikely to change it =
much
> further, so there=E2=80=99s little worry about having to change the asm a=
 second
> time. The main problem with asm, I suppose, is testing it. I do have a
> 32-bit Ubuntu VM set up, but I=E2=80=99d also need to set up Windows VMs,=
 and
> possibly others (don=E2=80=99t we have PowerPC in the source just now?).
>

change asm for 32-bit Linux and add TODO marks for others. I don't test PHP
on PPC as well.

Thanks. Dmitry.


>
> I might experiment with it tonight, or sometime later this week.
>
> Thanks.
>
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>

--001a113ce1f852b464050618a12e--