Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:98952 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 6480 invoked from network); 3 May 2017 03:54:41 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 May 2017 03:54:41 -0000 Authentication-Results: pb1.pair.com smtp.mail=lists@rhsoft.net; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=lists@rhsoft.net; sender-id=pass Received-SPF: pass (pb1.pair.com: domain rhsoft.net designates 91.118.73.15 as permitted sender) X-PHP-List-Original-Sender: lists@rhsoft.net X-Host-Fingerprint: 91.118.73.15 mail.thelounge.net Received: from [91.118.73.15] ([91.118.73.15:64265] helo=mail.thelounge.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id FE/0E-02776-97459095 for ; Tue, 02 May 2017 23:54:34 -0400 Received: from srv-rhsoft.rhsoft.net (Authenticated sender: h.reindl@thelounge.net) by mail.thelounge.net (THELOUNGE MTA) with ESMTPSA id 3wHkn15fxyzXKg for ; Wed, 3 May 2017 05:54:29 +0200 (CEST) To: Mailing-List php References: <79ca3537-b439-583a-6162-05da302711f2@rhsoft.net> <403881ad-ec0c-395f-279e-6b345ee7cb39@rhsoft.net> Message-ID: <84d53625-de7f-e2cb-e2c7-c3e83ede6219@rhsoft.net> Date: Wed, 3 May 2017 05:54:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-CH Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] the experimental jit-branch is impressive From: lists@rhsoft.net ("lists@rhsoft.net") Am 03.05.2017 um 05:37 schrieb Sara Golemon: > On Tue, May 2, 2017 at 10:19 PM, lists@rhsoft.net wrote: >> 100% internal codebase without 3rd party libraries developed over the last >> 15 years and in the meantime 100% strict-types/typehints/return-types only >> missing some commented nullable/void return types because i need to wait >> with 7.1.x for another busy guy with some of his instances :-) >> > Would you mind running some numbers against "commodity > apps/frameworks" (e.g. Wordpress, ZendFramework, Laravel, etc...) I > expect that will be far more telling (in a potentially positive way). > For example, HHVM performs best on "highly optimized code", which is > why it tends to look a bit tepid against PHP 7 when run on "normal" sorry, all my setups have a lot of stuff in the config to kill stuff like wordpress/joomla/typo3 so nobody comes to the idea installing after that badly mainatined stuff on my machines (for our own CMS there is a deplyoment system maintaining 100, 200 or 1000 instances with s single shell command) > codebases (particularly WP, which is in many ways not JIT friendly). > I realize the proof of concept jit branch is probably missing quite a > bit of optimizations compared to where it will land, so it may not > make then same kind of difference, but hey... curiosity killed the > cat. WP is not friendly to anything :-) on the other hand i guess that more the code itself is bloatet the impact of performance improvements is bigger compared to my code where httpd and connection handling takes as long as the application while 20% of my runtime costs are database connections and queries which don't get faster in any case >> the profiling system is our internal demo-system with every depolyable >> module installed, runs the auto-testsuite inclduing refelection fuzzy-calls >> > Sounds very comprehensive and I'm glad you're using such a heavy > benchmarking suite. :D well, it was more about "how do i feed https://software.intel.com/en-us/blogs/2015/10/09/pgo-let-it-go-php with as much as possible runtime informations" and later "how do i get that beast deployable again after rewrite the whole codebase to native PHP7 with minimized fallout on type-errors" >> so 5% is not that bad >> > Apologies if I gave the impression that I felt it was "bad". My > expressed disappointment was only relative to the headline "ZOMGWTFBBQ > 100% GAIN" headline (which I think most of us regarded as probably > wrong in some way due to the early-days nature of the jit branch). :) yeah, i thought i start a party after the first result which maxed out at 4200/seconds after a few thousand requests on my workstation looking in the direction of the 12-core Xeon "and what will you do with that" :-) what will be interesting with the JIT is how it benefits from newer CPU architectures, currently we optimize for sandybdrige, with next summer the cluster nodes will be replaced and the VMware EVC mode raised to skylake leading to maintain a different PHP PGP-build with -mtune=native looking at "Use AVX instructions (if enabled and available)" https://github.com/zendtech/php-src/commit/d9474c784041745a455dd5be06b52c0029e40697 there will be some space of improvement on both sides, the PHP binary itself as well as what code the JIT can prodcue at the end (skylake Xeon will intoduce AVX512 as example)