Am 03.05.2017 um 05:37 schrieb Sara Golemon:
On Tue, May 2, 2017 at 10:19 PM, li...@rhsoft.net <li...@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)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
