Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89467
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.215.10 cause and error)
Message-ID: <1448637633.24066.18.camel@kuechenschabe>
To: Pascal KISSIAN <php-mailing-list@lool.fr>
Cc: internals@lists.php.net
Date: Fri, 27 Nov 2015 16:20:33 +0100
In-Reply-To: <00b501d1291f$c66ca930$5345fb90$@lool.fr>
References: <009301d128fa$bb2675d0$31736170$@lool.fr>
	 <1448631693.24066.10.camel@kuechenschabe>
	 <00b501d1291f$c66ca930$5345fb90$@lool.fr>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Proof of Concept : 3.5x and more Performance Boost
 for php7 using 4 cores
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Fri, 2015-11-27 at 15:27 +0100, Pascal KISSIAN wrote:
> Hi Johannes,
> thanks for the answer,
> 
> -----Message d'origine-----
> De : Johannes Schlüter [mailto:johannes@schlueters.de] 
> Envoyé : vendredi 27 novembre 2015 14:42
> À : Pascal KISSIAN
> Cc : internals@lists.php.net
> Objet : Re: [PHP-DEV] Proof of Concept : 3.5x and more Performance Boost for php7 using 4 cores
> 
> >Your test runs a single PHP process. Mind that in a typical deployment on a server you have quite a few parallel PHP processes already competing for time on the CPU (when not >waiting for IO) a benchmark should reflect that.
> 	You can see  at http://poc.yakpro.com/?php7_performance_boost_parallel_computing ,
> 	in the " Faq: Is it usefull on a heavy traffic web site? " section, a graph that answers partially your question.

It's no real answer, though. And I still have doubts.

> >For in_array I'm assuming that often either one or no match exist, thus in average the old algorithm has to process half the elements in average. With that form of parallelization it >will process C/(N -1) + C/2N elements where C is the count of elements and N the number of cores, so in total need more CPU. (might be wrong)
> 	In the new algorithm, each core processes C/2N elements in parallel, and when one core has found a result, the process is stopped for the other cores...
> 	so the average cpu need is C/2N  * N  so exactly the same C/2.

Thanks.

> >So please run tests with a "typical" application (like wordpress or
> >such) in a more typical environment.
> 	Do you know a real application that is executing only array_sum() or in_array() functions?
> 	If the time of those functions represent only 0.5% of global run time, we will just speed-up those 0.5%....
> 
> 	I have not rewritten all php in parallel...
> 	I just did a "Proof of Concept", to be sure that it is possible to run some php functions in parallel, and this in less time.
> 
> 	And I hope that many people will be interested to start thinking parallel in php, as the next speed improvements in hardware will be the multiplication of cores in a cpu.

Well how many parts can one parallelize for real life applications? Also
how many typical calls will hit this optimization (the in_array one for
instance is only used for "larger" arrays)

Mind: The parallel code is harder to debug and as the implementation has
different paths depending on the input data and system configuration
which makes it harder to find issues. So the maintenance cost is quite
high and real life gain therefore has to be relevant.

johannes