Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99632
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain outlook.de designates 40.92.64.49 as permitted sender)
To: Nikita Popov <nikita.ppv@gmail.com>, =?iso-8859-1?Q?Fran=E7ois_Laupretre?=
	<francois@tekwire.net>
CC: PHP internals <internals@lists.php.net>
Thread-Topic: [PHP-DEV] Proposing inclusion of PCS in the 7.2 core
 distribution
Thread-Index: AQHS3iPDpaJzbtenaECswmptkGUOWaIXyKSAgBt547A=
Date: Sat, 24 Jun 2017 21:28:37 +0000
Message-ID: <HE1PR02MB10520207DC7E11AF91686EDFBAD90@HE1PR02MB1052.eurprd02.prod.outlook.com>
References: <5313411f-40b4-58c6-83a8-7e813526f2a7@tekwire.net>
 <CAF+90c9j4c+L8irb+tN+Qcx7SxA-d1EMBrXuZGw3FXi2SZr-Jw@mail.gmail.com>
In-Reply-To: <CAF+90c9j4c+L8irb+tN+Qcx7SxA-d1EMBrXuZGw3FXi2SZr-Jw@mail.gmail.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [ccDRwQkGugynQ5CeDFbltDdqvy37M+EbmGYbeFbREFkfucmvN7Mhq/fUK8KMTEC2]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1;HE1EUR01HT112;7:1xzg6ytF35Z+ELf9hG03rYOhEXCe5vck5HDoOi3MUln2Rgbmrr+/4QpUfnY5Yzobvm8l6VmwHphj80B47c/UeUEerN4RWgOjJhM88HYbapEuw8qFnqI2RpitbJkPJRXgdLhKVuJJtc85XDvQRJ4I8r0ixKGDtOnWxqdHC5o/qfeyyl5EFri+EjhC+WWmufDgfbw8cGhxv2IR2KCkoM42CkTL0wc5Qv+rwcU6HdVAe22LSaegIA2MiFOYz7bWqk6OWphXYKZbJ4zd019f1HoQJZejSbPnqkBW/x9+BD1eU45M7sehDqyBRTsBddwMNe4O2sKZelCQAjfAKNkNCIikSp8YuylAOpWC0ygYDAuJUyhJyiXuge+w2hShFB7zcTfGQ+2IPo7bp3lFMWrVVcbv6/KbTyaHWzRFCQySgKD9YX+TUjExsFQCgi43ZyVXLljPEw/mfd19dfAVux8VTdjGXIdQQe0rJyQkEmGJuvlQrDY+dqaaBvYeZ4VwdHmQS3kpzYd2/sUbpxKUQwOL/I2Yz50psESPWhRUk0L5jgmfxiKptj/gXO/kttAmPrHnxD9CtcTe+cJDqnKrXJiFO6OQG6NCjeHSUfMpte//UjTwwIOyranFz1zTko+Cc8Uc8qWYBGKTBvvonD26TsZQVp0P4LCS247v5HYy0C4QkBPOH99/C+yJYWV9tygbwLOrYpDH+EY44YjAie8Nq1wGU8loSHWvDxK3oBQWQYjSsxUm0R7068I8JD1G5vNdX9kyxvD/J9jzFJHtOm+ay+Ea2cvKaQ==
x-incomingheadercount: 46
x-eopattributedmessage: 0
x-forefront-antispam-report: EFV:NLI;SFV:NSPM;SFS:(7070007)(98901004);DIR:OUT;SFP:1901;SCL:1;SRVR:HE1EUR01HT112;H:HE1PR02MB1052.eurprd02.prod.outlook.com;FPR:;SPF:None;LANG:en;
x-ms-office365-filtering-correlation-id: dcc54639-56ae-4c7b-c130-08d4bb47f9fb
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(300000503095)(300135400095)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322274)(1603101448)(1601125374)(1701031045)(300000504095)(300135200095)(300000505095)(300135600095)(300000506067)(300135500095);SRVR:HE1EUR01HT112;
x-ms-traffictypediagnostic: HE1EUR01HT112:
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031);SRVR:HE1EUR01HT112;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:HE1EUR01HT112;
x-forefront-prvs: 03484C0ABF
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2017 21:28:37.6555
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1EUR01HT112
Subject: RE: [PHP-DEV] Proposing inclusion of PCS in the 7.2 core distribution
From: weltling@outlook.de (Anatol Belski)

Hi,

> -----Original Message-----
> From: Nikita Popov [mailto:nikita.ppv@gmail.com]
> Sent: Tuesday, June 6, 2017 2:43 PM
> To: Fran=E7ois Laupretre <francois@tekwire.net>
> Cc: PHP internals <internals@lists.php.net>
> Subject: Re: [PHP-DEV] Proposing inclusion of PCS in the 7.2 core distrib=
ution
>=20
> On Mon, Jun 5, 2017 at 7:46 PM, Fran=E7ois Laupretre <francois@tekwire.ne=
t>
> wrote:
>=20
> > 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 faster than C).
> >
> > Another motivation is the lack of extension maintainers. It may be
> > complex 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 manages via a stream wrapper.
> >
> > So, please give me your thoughts. Suggestions of potential candidates
> > to be rewritten from C to PHP are welcome too.
> >
>=20
> Hi,
>=20
> 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.
>=20
> There are essentially only two good reasons for implementing functionalit=
y in C:
> One is performance, the other is FFI. Unfortunately, the requirement to u=
se 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 co=
de 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.
>=20
> On top of that, implementing certain functionality in C actually makes th=
e
> 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 o=
f
> userland callbacks. Another is access to properties.
>=20
> 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 si=
mple
> procedural APIs rather than fancy object oriented APIs -- however, that's=
 a
> choice that should be made based on technical arguments, not due to techn=
ical
> limitations.)
>=20
> 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 extensi=
ons
> (and may be preferable if they have large fractions of PHP code), this op=
tion
> does not exist for our standard library. We can hardly tell people that t=
hey
> should go install a composer package in order to make use of some APIs in=
 our
> standard library.
>=20
> Anyway, to get back to the topic of PCS. First, I would recommend to targ=
et 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 integ=
rate it
> in PHP. If added to PHP, I think this should be integrated into the core,=
 rather
> than being an extension.
>=20
> Here are some random thoughts:
>=20
> 1. As far as I understand, PCS relies on autoloading. There are two issue=
s
> 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 compili=
ng
> internal functions should not run into any of the problems we have with u=
serland
> function autoloading.
>=20
> 2. It has already been mentioned in the thread, but what seems to lack ri=
ght 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:
>=20
> 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.
>=20
> b) Allow binding some methods specified in PHP to an internal implementat=
ion.
> 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:
>=20
> class Bar {
>     <<__Native>>
>     function foo($args);
> }
>=20
> 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 exam=
ple,
> arginfo does not support default values.
>=20
The mechanism like HHVM has is what were surely useful. Where I see a conce=
rn regarding PHP is, that with the original proposal a PHP interpreter is n=
eeded for the partials processing. To the compilation time for the core, it=
 is not expected to be available. In further, for example if the binary jus=
t compiled would be used, it has an issue potential with FDO/PGO. Reason - =
required preparation tasks would produce training data not necessarily desi=
red. Perhaps that is solvable by extending the build time - an independent =
minimal binary could be produced just for the goal. That, however, might no=
t suffice depending on complexity, fe like it were about a PECL ext dependi=
ng on classes of another one and trying to use type hints, classes from dep=
endent, etc. Perhaps this needs more evaluation for non core exts. It's som=
ehow a chinken/egg issue.

IMO, in any case the pieces, that can be handed out into a PHP code, would =
be a huge win. That would add to complexity reduction of the actual C parts=
 an make the actual dev faster and more qualitative. There are always cases=
, where moving the implementation partially to C is a win in speed or funct=
ionality, or where is moving C implementation into userland doesn't make th=
ings worse but simplifies a lot. Currently it's almost only one way - only =
moving parts to C is a win in most case. Flexibility is a huge win in havin=
g both, too.=20

I'd also see the topic as coupled tightly with the previous discussions abo=
ut Opcache core integration. Looking at what Python does, a possibility to =
redistribute the opcode cached bins might make sense. Of course, there are =
differences in how it works, where we could introduce some naming/configura=
tion conventions to pursue the goal. That might involve also a change to pa=
ckage.xml specs for PECL exts. In general, I'd put the Opcache integration =
in the foreground, as that is the long standing topic that would also make =
evermore sense when the JIT branch in integrated. A PECL ext can have sourc=
es only, but given it's compiled for and on a specific platform - having ri=
ght the opcode bins is more optimal. Maybe having both ways of either pure =
PHP or opcode bins were useful, too. In any case, Opcache integration with =
the core could be a game changer in many topics, as for me. Another related=
 topic might be the integration of libffi, also looking at the good example=
s from Python.

Thanks

Anatol