Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89485
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.204 cause and error)
To: internals@lists.php.net
References: <009301d128fa$bb2675d0$31736170$@lool.fr>
 <CAFMT4Np9Bwt5PqJ4SDufDLs7QWB3+2WZEjHqo43Jem-r_UrtwQ@mail.gmail.com>
Message-ID: <565AF32E.60606@lsces.co.uk>
Date: Sun, 29 Nov 2015 12:44:30 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <CAFMT4Np9Bwt5PqJ4SDufDLs7QWB3+2WZEjHqo43Jem-r_UrtwQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Proof of Concept : 3.5x and more Performance Boost for
 php7 using 4 cores
From: lester@lsces.co.uk (Lester Caine)

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'?.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk