Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89487
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <565AF32E.60606@lsces.co.uk>
References: <009301d128fa$bb2675d0$31736170$@lool.fr>
	<CAFMT4Np9Bwt5PqJ4SDufDLs7QWB3+2WZEjHqo43Jem-r_UrtwQ@mail.gmail.com>
	<565AF32E.60606@lsces.co.uk>
Date: Mon, 30 Nov 2015 16:31:33 +0700
Message-ID: <CAEZPtU5gNyRjniiUeFwG-2LpE5vxXofy815A0JjZdDW0zXRzrA@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Proof of Concept : 3.5x and more Performance Boost for
 php7 using 4 cores
From: pierre.php@gmail.com (Pierre Joye)

On Sun, Nov 29, 2015 at 7:44 PM, Lester Caine <lester@lsces.co.uk> wrote:
> On 29/11/15 04:44, Levi Morrison wrote:
>>> A multicore php8 or php9?  Wouldn't be cool????
>> Honestly, PHP is a poor language for parallel computing. This is
>> because PHP is a web-focused language. The the most common setup ends
>> up with a blocking request on a network call. What we really need is
>> an improved asynchronous model so that we can wait on those network
>> requests more efficiently.
>
> I'd second that. Since all of MY data is stored in a database, requests
> to that use other cores on the processor or even other processors, and
> so to be able to carry on building other areas of material while waiting
> for one or more database or other services to return will be a lot more
> productive than trying to do the thread that is waiting for a result
> faster? In addition, having several users each getting a single core to
> handle their request seems a lot more practical than one request hogging
> all of the resources?
>
> There are applications that are suitable for high power parallel
> processing, and these are ones where reusing GPU resources which are
> inherently parallel data aware is much more practical freeing the MPU
> resources to handle threads that are less reliant on parallel data.
>
> Adding extensions such as the Lapack which can be expanded to take
> advantage of the available hardware to parallel process the data set is
> a lot more practical than trying to make an inherently serial process
> 'parallel'?.

I fully agree here.

Also PHP exists to serve request as fast as possible. Any tasks being
so expensive that parallelism is required is the best candidate to be
delegated outside the request handling, preferably on another box.

Also an extension fits the main usage for such features, in CLI.

-- 
Pierre

@pierrejoye | http://www.libgd.org