On Thu, Oct 23, 2014 at 5:50 PM, Andrea Faulds <[email protected]> wrote:
> Hi!
>
> > On 23 Oct 2014, at 13:47, Dmitry Stogov <[email protected]> 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’s unfortunate. ext/json is first on my list to update once I’m
> 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’ve finished porting ext/standard months ago, I’ve 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=callgrind (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’m not really sure about whether a new core type can’t be free. For
> switch statements, if they’re compiled to a jump table, they shouldn’t be
> any slower when a new case is added. But I’m not certain on that, I don’t
> spend much time reading generated asm.
>
> Does bench.php do any float operations? I’m 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’s the case, it would obviously
> be slower as bigints trade performance for accuracy. This particular issue
> can’t 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 converted
> to a double, and *then* does the operation if it won’t 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…
>
> 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’ve so far been scared to touch the asm… but actually, I don’t think it
> could be *that* hard. It’s not doing something especially complex.. The
> bigint API looks fairly stable now and I’m unlikely to change it much
> further, so there’s 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’d also need to set up Windows VMs, and
> possibly others (don’t 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/
>
>
>
>
>