Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78272
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ajf.me designates 198.187.29.244 as permitted sender)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
In-Reply-To: <CA+9eiLvh9RFVmYD1_y0AU0NVkkxYTfjv_C6H4tN8RH-w7X7M1g@mail.gmail.com>
Date: Thu, 23 Oct 2014 14:50:03 +0100
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <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>
To: Dmitry Stogov <dmitry@zend.com>
Subject: Re: [PHP-DEV] [RFC] Big Integer Support
From: ajf@ajf.me (Andrea Faulds)

Hi!

> On 23 Oct 2014, at 13:47, Dmitry Stogov <dmitry@zend.com> wrote:
>=20
> Hi Andrea,
>=20
> The synthetic benchmarks are not always reflect the impact on =
real-life performance.
>=20
> 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 =
once 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.
>=20
> master 1.210 sec
> bigint   1.330 sec
>=20
> I also measured the number of executed instructions using valgrind =
--tool=3Dcallgrind (less is better)
>=20
> master  1,118M
> bigint    1,435M
>=20
> May be part of this difference is caused by missing latest master =
improvements, but anyway, introducing new core type, can't be done for =
free.

I=E2=80=99m not really sure about whether a new core type can=E2=80=99t =
be free. For switch statements, if they=E2=80=99re compiled to a jump =
table, they shouldn=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 floats in master or bigints in my branch. If that=E2=80=99s the =
case, it would obviously be slower as bigints trade performance for =
accuracy. This particular issue 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.

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. 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 =
converted 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.
>=20
> [master] $ sapi/cgi/php-cgi -T 1000 /var/www/html/bench/qdig/index.php =
> /dev/null
> Elapsed time: 3.327445 sec
>=20
> [bigint] $ sapi/cgi/php-cgi -T 1000 /var/www/html/bench/qdig/index.php =
> /dev/null
> Elapsed time: 3.382823 sec
>=20
> 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.

--

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?).

I might experiment with it tonight, or sometime later this week.

Thanks.

--
Andrea Faulds
http://ajf.me/