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. 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
