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.
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’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.
--
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?).
I might experiment with it tonight, or sometime later this week.
Thanks.
--
Andrea Faulds
http://ajf.me/