Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:78270
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.214.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <68229C26-4EEC-49DC-BA05-D5AC9728D1E8@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>
Date: Thu, 23 Oct 2014 16:47:48 +0400
Message-ID: <CA+9eiLvh9RFVmYD1_y0AU0NVkkxYTfjv_C6H4tN8RH-w7X7M1g@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11352f46c58bce050616785c
Subject: Re: [PHP-DEV] [RFC] Big Integer Support
From: dmitry@zend.com (Dmitry Stogov)

--001a11352f46c58bce050616785c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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).

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 free=
.

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...

Thanks. Dmitry.

On Thu, Oct 23, 2014 at 2:32 PM, Andrea Faulds <ajf@ajf.me> wrote:

>
> > On 22 Oct 2014, at 21:12, Andrea Faulds <ajf@ajf.me> wrote:
> >
> > I ran the script several times, then took the results and put them into
> Excel to produce the above table with its averages.
> >
> > So common scripts are either unaffected, or will run ever-so-slightly
> faster.
>
> Just to be clear, though, that didn=E2=80=99t tell the whole story. With =
that
> number of iterations, there=E2=80=99s no speed difference that isn=E2=80=
=99t within the
> margin of error. However, up the iterations by 100x and the bigint branch
> is consistently very slightly slower. Remove the body of the loop so it=
=E2=80=99s
> just `for ($i =3D 0; $i < 100000000; $i++) {}` and the bigint branch is
> consistently very slightly faster. No idea why either of these is the cas=
e.
>
> So, apparently, the bigint branch both makes things slower and makes them
> faster! But it=E2=80=99s not a big enough difference for me to be worried=
 about it.
> The differences that do exist might disappear if the fast_* functions can
> have their inline asm rewritten and be uncommented. Currently, master has
> custom asm for these, while the bigint branch has to use the probably
> slower C implementations because I don=E2=80=99t understand x86 or x64 as=
m and am
> unable to rewrite it.
>
> --
> Andrea Faulds
> http://ajf.me/
>
>
>
>
>

--001a11352f46c58bce050616785c--