On Thu, Oct 23, 2014 at 5:50 PM, Andrea Faulds <a...@ajf.me> wrote: > Hi! > > > On 23 Oct 2014, at 13:47, Dmitry Stogov <dmi...@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’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/ > > > > >
