Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99398
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5313411f-40b4-58c6-83a8-7e813526f2a7@tekwire.net>
References: <5313411f-40b4-58c6-83a8-7e813526f2a7@tekwire.net>
Date: Tue, 6 Jun 2017 14:43:13 +0200
Message-ID: <CAF+90c9j4c+L8irb+tN+Qcx7SxA-d1EMBrXuZGw3FXi2SZr-Jw@mail.gmail.com>
To: =?UTF-8?Q?Fran=C3=A7ois_Laupretre?= <francois@tekwire.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="94eb2c05ae588352ec055149f606"
Subject: Re: [PHP-DEV] Proposing inclusion of PCS in the 7.2 core distribution
From: nikita.ppv@gmail.com (Nikita Popov)

--94eb2c05ae588352ec055149f606
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 5, 2017 at 7:46 PM, Fran=C3=A7ois Laupretre <francois@tekwire.n=
et>
wrote:

> Hi,
>
> PCS provides a fast and easy mechanism to mix C and PHP code in PHP
> extensions (more about PCS at http://pcs.tekwire.net). Thanks to the PHP
> 7 performance improvement and the inclusion of opcache in the core, a lot
> of existing non-performance-critical extension code may now be converted =
to
> PHP without significant performance loss (this must be measured case by
> case, of course, but tests show that opcode-cached PHP code is often fast=
er
> than C).
>
> Another motivation is the lack of extension maintainers. It may be comple=
x
> to convert a C extension to PHP but, once it's done, maintenance becomes
> much easier.
>
> As one of PCS goals is to allow converting parts of existing core
> extensions to PHP, it seems natural to initiate the movement by an
> inclusion of PCS in the core distribution. Then, I and others will start
> proposing conversions of existing code. IMO, the PDO generic layer is a
> perfect candidate, but there are many others.
>
> Converting existing C code to PHP is not the only usage. With PCS, adding
> an OO layer to a function-only extension becomes an easy task. Sara
> recently told about a curl OOP layer (https://gist.github.com/sgole
> mon/e95bfc34d34c4f63fa953ee9294ae02c). Using PCS, adding such PHP code on
> top of the curl extension would take less than one hour.
>
> I hadn't proposed this so far because the 'cache_key' operation currently
> proposed for 7.2 is a pre-requisite, as PCS exposes the PHP code it manag=
es
> via a stream wrapper.
>
> So, please give me your thoughts. Suggestions of potential candidates to
> be rewritten from C to PHP are welcome too.
>

Hi,

First of all: I think the ability to implement parts of PHP extensions in
PHP is extremely important and will be a game changer in our ability to
maintain and improve our standard library.

There are essentially only two good reasons for implementing functionality
in C: One is performance, the other is FFI. Unfortunately, the requirement
to use C for everything inside an extension means that we write a large
amounts of C code that does not fall into either of those categories. The
resulting code is hard to maintain, often subtly buggy and usually not
consistent with ordinary userland PHP code. Typical issues we see all the
time are bad or completely absent serialization support, lack of circular
garbage collection, crashes when the object is improperly initialized and
bugs appearing when internal classes are extended.

On top of that, implementing certain functionality in C actually makes the
resulting code slower than equivalent PHP code. While our virtual machine
is highly optimized, our internal APIs are often not, or not typically used
in their most efficient form. One case where internal code loses are
invocations of userland callbacks. Another is access to properties.

The current situation also has a large and somewhat hidden impact on our
API design. Due to the large maintenance burden that implementing "proper"
APIs imposes on us, we tend to go with the simplest possible API. Usually
this means that we end up directly exposing C binding APIs, even if they
are a very bad fit for PHP. As already noted in this thread, the current
curl API is such an example. (I know that some people will argue that its
better to expose simple procedural APIs rather than fancy object oriented
APIs -- however, that's a choice that should be made based on technical
arguments, not due to technical limitations.)

Some people have mentioned that this is better solved by shipping the PHP
code separately using composer. While this may be viable for 3rd party
extensions (and may be preferable if they have large fractions of PHP
code), this option does not exist for our standard library. We can hardly
tell people that they should go install a composer package in order to make
use of some APIs in our standard library.

Anyway, to get back to the topic of PCS. First, I would recommend to target
PHP 7.3 for this change. Feature freeze for 7.2 is in a bit over a month
and I think we'll want to make some non-trivial changes to how this works
if we integrate it in PHP. If added to PHP, I think this should be
integrated into the core, rather than being an extension.

Here are some random thoughts:

1. As far as I understand, PCS relies on autoloading. There are two issues
here: First, autoloading does not register symbols prior to autoloading.
This means that functions like get_defined_classes() will not behave as
expected. Second, autoloading does not support functions. I think both of
these problems can be solved with some up-front symbol analysis. Lazily
compiling internal functions should not run into any of the problems we
have with userland function autoloading.

2. It has already been mentioned in the thread, but what seems to lack
right now is a good way of integrating PHP and C portions. As far as I
understand, PCS allows you to write an entire class in PHP, but it does not
allow you to offload parts of the functionality to C without exposing
additional public APIs. I think there are two things we can do here:

a) Provide a mechanism that makes certain functions only available inside
extension PHP code. This would allow exposing some private PHP functions
which are only used in the internal implementation of the extension.

b) Allow binding some methods specified in PHP to an internal
implementation. The way this works in HHVM is that the PHP file contains
just a signature, with an attribute that signifies that an internal
implementation will be bound to that function:

class Bar {
    <<__Native>>
    function foo($args);
}

This would be useful for other reasons as well. In particular, this could
become a replacement for the existing arginfo-based signature
specification, which is somewhat limited and causes discrepancies with
userland classes. For example, arginfo does not support default values.

Regards,
Nikita

--94eb2c05ae588352ec055149f606--