On Tue, May 26, 2015 at 6:24 PM, Rasmus Lerdorf <ras...@lerdorf.com> wrote:
> On 05/26/2015 07:33 AM, Dmitry Stogov wrote: > > Commit: 7dac4d449f72d7eb029aa1a8ee87aaf38e17e1c5 > > Author: Dmitry Stogov <dmi...@zend.com> Tue, 26 May 2015 > 17:33:25 +0300 > > Parents: ca31711625095c2d6e308d7f0fc9d371ad0934d4 > > Branches: master > > > > Link: > http://git.php.net/?p=php-src.git;a=commitdiff;h=7dac4d449f72d7eb029aa1a8ee87aaf38e17e1c5 > > > > Log: > > Add targets to simplify building PHP with FDO (Feedback Directed > Optimisation) > > PHP should be built with the folowing steps: > > > > make clean > > make -j4 prof-gen > > ; now php should be trained with some scripts > > ; for example `sapi/cgi/php -T 1000 /var/www/http/wordpress/index.php > > /dev/null` > > make prof-clean > > make -j4 prof-use > > > > The "properly" trained build may give up to 10% real performance boost! > > "Improprly" trained PHP might be even slower. > > Whoa, really 10%? I know there is AutoFDO coming in gcc 5.1 and I didn't > think this was really practical until then. Perhaps it is. I wonder if > this will spur php-wordpress, php-drupal and php-mediawiki tuned builds? > I hope, we will be able to identify the main sources of speed difference and provide a source level solution that won't require FDO. I'm going to work on this with a team of experts from Intel, but we don't have any receipt yet. In case anyone find something useful please share with me. At this point we know that FDO built inlines most memcpy() and memset() calls. Training scripts may speed-up some apps and slow-down others, but it looks like most real-life apps benefits from the the same things, while synthetic benchmarks from something opposite. So improving real-life apps we slow-down bench.php and back :) Thanks. Dmitry. > > -Rasmus > >
