Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102415
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 104.47.32.95 cause and error)
To: internals <internals@lists.php.net>
Thread-Topic: PHP 2^3
Thread-Index: AdQMftVok3xkcPLJQYKDOhPigMbX0g==
Date: Mon, 25 Jun 2018 12:30:28 +0000
Message-ID:
 <DM5PR0201MB354280334D34629059189156AC4A0@DM5PR0201MB3542.namprd02.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: zend.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_DM5PR0201MB354280334D34629059189156AC4A0DM5PR0201MB3542_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a33c82dd-da4e-4e3c-2302-08d5da976f79
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2018 12:30:28.7019
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 32210298-c08b-4829-8097-6b12c025a892
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR0201MB3462
Subject: PHP 2^3
From: zeev@zend.com (Zeev Suraski)

--_000_DM5PR0201MB354280334D34629059189156AC4A0DM5PR0201MB3542_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

As I mentioned a few days ago I intended to send it slightly later - but as=
 Nikita brought up the topic of PHP 8, this is probably as good a time as a=
ny to start the discussion.

Please note:  The goal of this email isn't to discuss in detail each and ev=
ery topic that's mentioned, but rather to establish whether we want to move=
 to focus on PHP 8 as we go beyond PHP 7.3, based on some of the research p=
rojects and PoCs we've been working on.

There are several areas that I think we should invest in in the next major =
version:

1. JIT.  As most of you probably know, we've invested heavily in re-doing J=
IT on top of the PHP 7 infrastructure.  There are good news and bad news.  =
The good news is that - like the JIT POC we did back in 2014 - the results =
for CPU intensive workloads are remarkable.  The bad news is that it doesn'=
t significantly move the needle for typical Web workloads.
That said, unlike 2014 - where we had another avenue to go after, this time=
 we believe that JIT doesn't improve the performance of typical Web workloa=
ds simply because the bottleneck there is no longer PHP code execution.
However, I still think we should still include JIT in the next major versio=
n of PHP for at least 2 reasons:
  - It will open the door for new types of workloads for PHP (non Web)
  - It may open the door for new built-in functionality being written in PH=
P - for more secure code (e.g. a PHP unserialize() implementation, instead =
of one in C)
In addition, it's always possible that we're missing something in our bench=
marks and that there are real world Web workloads that would actually benef=
it from the speedup.
One thing worth noting is that in all likelihood, we'd want to make OPcache=
 (or at least large parts of it) a part of the core engine (and no longer a=
 separate extension) as a part of the JIT effort.
- (bonus) Combined with other things we're experimenting with, the compound=
 effect may still result in better performance for Web apps.
To get a feel for the performance gains we're talking about here, I recorde=
d a benchmark comparing PHP 7.0 and the JIT PoC, available here:
https://www.youtube.com/watch?v=3DdWH65pmnsr

2. Better support long-running, async-based, microservices-focused executio=
n model.  It's probably no secret that one of the key reasons Node is gaini=
ng popularity is because it can handle a huge number of concurrent connecti=
ons issuing relatively lightweight requests very efficiently - which is a g=
ood match for modern microservices based architectures.  There are already =
several projects available for PHP that aim to provide similar functionalit=
y - most notably ReactPHP and more recently Swoole.
The main thing that is missing is that most of PHP's IO doesn't support asy=
nc execution.  What I think we should do is add as much support for async I=
O as possible across the various extensions and streams - so that using som=
ething like Swoole would become practical for more use cases.  More specifi=
cally - the goal would be to provide extension authors with mechanisms that=
 they can use to make their extensions/functions optionally asynchronous, w=
ithout having to tackle the job entirely on their own.  While we've done so=
me research into this area, it requires a lot more research - but I'm cauti=
ously optimistic that it can be done.  We would potentially want to use lib=
uv for this task, and potentially rewrite or otherwise refactor parts of th=
e PHP streams system.

3. Foreign Function Interface support.  Essentially, make it very easy to c=
onnect PHP to native code libraries written in C or C++ without having to w=
rite an extension.  Now, I realize this may not sound like much more than a=
n extension - however, I think that if we look at the potential impact and =
not just the complexity of implementation - this is actually quite strategi=
c.  This can open the door for PHP to be used a lot more often in conjuncti=
on with 'bleeding edge' technologies, such as AI and Machine Learning, and =
not just ones existing today - but kind of 'future proof' it for whatever t=
echnologies emerge down the road.  Dmitry brought that up on the mailing li=
st already, and he's made quite a bit of progress there.  He actually spent=
 the last couple of weeks writing TensorFlow bindings for PHP, and wrote wh=
at's probably the first Neural Network in PHP - recognizing handwritten dig=
its with 98% precision (https://github.com/dstogov/php-tensorflow/blob/mast=
er/test_nmist_01.php).  I think that especially combined with JIT - this ca=
n make PHP a real powerhouse for executing CPU intensive apps, while not co=
mpromising on developer productivity.  By the way, to make it go truly fast=
 (especially in conjunction with JIT), we'll likely want this to actually b=
e merged into the core engine as well, and not as a separate extension.

4. Preloading support.  We've discussed this at a high level numerous times=
, but if we end up introducing JIT into PHP 8 as I hope we will, preloading=
 support can very nicely complement it.  It will effectively enable the dev=
elopment of PHP-based "extensions" - instead of just C based (or FFI based)=
 ones.  With JIT, the penalty for writing logic in PHP would go down dramat=
ically - and it would obviously offer benefits as far as both simplicity an=
d security are concerned.  In addition - preloading can actually speed thin=
gs up very substantially for Web based apps, as it may allow us to resolve =
certain dependencies at compile time (mainly inheritance) in compile-time i=
nstead of runtime.

Now, two things I should mention that this list is/isn't:


  *   It's incomplete - i.e., the fact a certain feature isn't on it does n=
ot preclude its inclusion in PHP 8
  *   It's not set in stone - we'll of course have to have RFCs for each of=
 these ideas, and we may also very well fail to implement some of them to s=
atisfactory levels

What this list is - a collection of directions around which we've performed=
 varying amounts of research (some of them quite a lot, like JIT), that I t=
hink is strong grounds for us to start discussing a PHP 8 timeline, and mak=
ing PHP 7.3 the last feature release in the PHP 7.x family.  If we had to c=
ome up with an educated guess as to when PHP 8 could be ready to be release=
d based on the abovementioned featureset, we're probably talking about 2-2.=
5yrs away (i.e. mid/late 2020).  We can also consider having a very slim PH=
P 7.4 release sometime in 2019 that wouldn't add any functionality, but tha=
t would give us an opportunity to deprecate anything that we missed in 7.3 =
that truly requires deprecation - while still allowing folks to prepare for=
 8.0 ahead of time.

My aim with this email is to both gauge the sentiment of shifting focus tow=
ards PHP 8 after the 7.3 release, as well as directional feedback regarding=
 the various bulletpoints.  If there's positive feedback, I think the next =
step may be to draft a 'PHP 8 as the next feature release of PHP' RFC, with=
 perhaps provisions for a deprecation-only 7.4, and then continue with each=
 of the above proposals (as well as any others) separately.  We can also tr=
y to include a timeline in it, but I think it has to have provisions to be =
delayed (to a certain limit) in case things take longer to research/develop=
/stabilize.

Thoughts?

Zeev



--_000_DM5PR0201MB354280334D34629059189156AC4A0DM5PR0201MB3542_--