Hey Dmitry, > On 23 Oct 2014, at 16:22, Dmitry Stogov <dmi...@zend.com> wrote: > >> 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.
After procrastinating about this for a long time, I finally went and updated the overflow checks today and ran bench.php. I still haven’t touched the inline asm, I’ve just removed it, since clang and GCC (only in GCC 5.0, sadly) have checked arithmetic intrinsics. If someone wants to, they can rewrite the inline asm for compilers that have no overflow-checking intrinsics, but this is good enough for now, at least for the purposes of performance checking on my machine. I’m using clang, by the way. If you want to replicate these results, you’ll probably also need it, since GCC 5.0 isn’t out yet, unfortunately. I compiled the bigint-libtommath branch (theoretically this was just a branch, but actually all the new changes have gone there, I’ll merge it into the bigint branch once LibTomMath port is done), and the current master branch. For bigint-libtommath, I used ./configure --enable-debug --enable-phpdbg —-disable-all —-enable-bigint-gmp Because of the —-enable-bigint-gmp flag, it’s using the GMP backend, not the LibTomMath one. I’m doing this since there’s still one or two small things I haven’t finished implementing for LibTomMath, e.g. the binary bitwise ops have the wrong behaviour just now. For master, I used ./configure --enable-debug --enable-phpdbg —-disable-all Then, I ran bench.php four times, and each time I ran it first on ./php-bigint-gmp, then on ./php-bigint-master. On each run, the bigint branch turned out faster, as well as overall: bigint master 6.593 6.659 6.424 6.661 6.414 6.588 6.381 6.673 AVERAGE 6.453 6.64525 DIFFERENCE -0.19225 0.19225 RATIO 0.971069561 1.0297923446 So master is 2.9% slower! Full output here: https://gist.github.com/TazeTSchnitzel/759c1513b442571f5e26 I can’t actually explain why bigints would be faster. It might just be because I got rid of fast_increment_function in favour of just checking of op1 == ZEND_LONG_MAX in zend_vm_execute.h, ditto for fast_decrement_function. Maybe using overflow intrinsics is faster than inline asm. Maybe it’s something completely different. I honestly don’t know. The result surprised me as I expect bigints would be slower, so I redid it. Again, bigints came out on top: bigint master 6.55 6.779 6.353 6.738 6.326 6.674 6.144 6.177 AVERAGE 6.34325 6.592 DIFFERENCE -0.24875 0.24875 RATIO 0.9622648665 1.0392149135 This time master was around 3.9% slower. Full log here: https://gist.github.com/TazeTSchnitzel/59c190b86c9dd5b20570 If we combine the two runs: bigint master 6.593 6.659 6.424 6.661 6.414 6.588 6.381 6.673 6.55 6.779 6.353 6.738 6.326 6.674 6.144 6.177 AVERAGE 6.398125 6.618625 DIFFERENCE -0.2205 0.2205 RATIO 0.9666849232 1.0344632216 master’s 3.4% slower. Just to check I named the files correctly: oa-res-26-240:php-src ajf$ ./php-master -r 'var_dump(PHP_INT_MAX * 2);' float(1.844674407371E+19) oa-res-26-240:php-src ajf$ ./php-bigint-gmp -r 'var_dump(PHP_INT_MAX * 2);' int(18446744073709551614) Yes, it’s definitely the bigint branch. So, at least by these preliminary results, the bigint branch would appear to be faster than master. This is merely bench.php, but it’s still a good sign. :) Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
