[PHP-DEV] Optional pre-compiler for PHP8?
Hello all: While reading the [RFC] Union Types v2 thread and comments from Dmitry[1], and especially Benjamin[2] who suggested "building a static analysis tool which could prove that certain type checks would never fail, and prime OpCache" it occurred to me that a PHP pre-compiler could potentially be used to resolve numerous issues the community has been debating. But first, let me define what I envision for a pre-compiler: - A command-line tool that could take a PHP file and/or application and generate pre-compiled files with an extension of .phpc or similar. - This of these .phpc files being implemented similar to .phar` files, but actually compiled to a OpCache binary form. - Pre-compiled files would be deployed alongside .php files, or optionally(?) standalone without PHP files. - Libraries and (WordPress) plugins could deliver pre-compiled files too, alongside their .php source files - Command line switches could allow for: - Compiling with or without (selected) deprecations - Selected constants defined on the command line - Packaging code on a one-to-one per PHP file, as one file per namespace, one file per app, etc. - The pre-compilation process would be able to: - Type-check everything that has type-hints - Do type checking that is too expensive to do at runtime - Pre-compiling: - Could help eliminate the complexity of auto-loading and opening many files, at least for pre-compiled code. - Would be an option for type checking and improved performance, but not be required. If the PHP community were to embrace the idea of an optional pre-compiler then we could see the following benefits: 1. Full type checking capability without any concerns for runtime performance issues related to type checking. 2. Ability to significant improve performance over time, possibly even more than a JIT model. 3. Potential to support optimized real types — as in Hack — where code needs to be highly performant 4. Ability to deprecate features for pre-compiled code while still supporting them when not precompiled. While benefits #1 to #3 are highly valuable, consider benefit #4. If we had such a pre-compiler than the concern for BC for pre-compiled code could become moot as the deprecations would not affect any existing code that is not pre-compiled. This could potentially give us the best of both worlds? Further, those most interested in deprecations and moving to enterprisey language features certainly use a CI/CD build process so it should be not problem at all for them to incorporate a pre-compile step. Lastly, having such an optional process — with its primary promoted benefit being performance — could be a great incentive for those running less strict and backwards-compatible PHP code to refactor their source code to gain greater performance. This contrasts with deprecating features and breaking BC just "because it is a better way to program." Give them a carrot rather than use a stick. So for those who know PHP's internal core code: Is there any reason this is not technically viable? And for everyone: What do you think of this as a potential future for PHP? -Mike [1] https://news-web.php.net/php.internals/107699 [2] https://news-web.php.net/php.internals/107702
Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288
On 2019-10-26 08:20, Jan Ehrhardt wrote: > Fill in a smtp-server of your choice (like smtp.gmail.com) and run it. > It is non optimized for speed, so it might take 2 minutes before the > results show. @Helmut and @Nikita: could you test this and share your > results here? I ran it on the command line and this was the result: $ php secure_stream_test.php 64.233.167.108:587 connected 220 smtp.gmail.com ESMTP e12sm6843183wrs.49 - gsmtp Send EHLO smtp.gmail.com 250-smtp.gmail.com at your service, [MYIPHERE] 250-SIZE 35882577 250-8BITMIME 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-CHUNKING 250 SMTPUTF8 Send STARTTLS 220 2.0.0 Ready to start TLS Turn on encryption for login phase: stream_socket_enable_crypto 64.233.167.108:587: stream_socket_enable_crypto returned true Send EHLO smtp.gmail.com 250-smtp.gmail.com at your service, [MYIPHERE] 250-SIZE 35882577 250-8BITMIME 250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-CHUNKING 250 SMTPUTF8 QUIT & close Cheers, K. C. -- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944 /* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */ signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] configure bug with static openssl 1.1.1? - bugid 77288
"Helmut K. C. Tessarek" in php.internals (Tue, 22 Oct 2019 22:33:39 -0400): >After a few more hours of trial and error I managed to get it working. > >However, the `-lpthread` in OPENSSL_LIBS is ignored. I checked the config.log, > but it wasn't added to the linker command. But adding it to LIBS solved the >issue. > >This is the command that finally worked: > >./configure [snip] --with-openssl=/usr/local/ssl-1.1.1 [snip] >CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib LIBS="-lpthread" >OPENSSL_LIBS="-L/usr/local/ssl-1.1.1/lib -l:libssl.a -l:libcrypto.a -ldl >-lpthread" OPENSSL_CFLAGS="-I/usr/local/ssl-1.1.1/include" > >I will also update the bug, so that people have this info on file as a >reference. In my implementation I ran into a serious problem. PHPMailer stopped sending mails to a remote smtp server over port 587. After really a lot of debugging I found out that stream_socket_enable_crypto failed: Warning: stream_socket_enable_crypto(): SSL operation failed with code 1 OpenSSL Error messages: error:1416F086:SSL routines: tls_process_server_certificate:certificate verify failed I wrote an example program to illustrate this: https://gist.github.com/Jan-E/7f0055624b82c39dee6ae5b712f2c97a Fill in a smtp-server of your choice (like smtp.gmail.com) and run it. It is non optimized for speed, so it might take 2 minutes before the results show. @Helmut and @Nikita: could you test this and share your results here? I had to revert back to PHP versions, compiled with the system OpenSSL libs. -- Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Union Types v2
> > As they are runtime checks, would an ini setting where they can be > completely disabled be feasible? So during development and in production > when the performance decrease doesn't matter, I can have the full runtime > type checking. But when absolutely needed, the checking can be disabled. Note that I would personally never disable these checks in production, as they may prevent potential bugs down the road, that would not have necessarily been caught in dev. I would rather expect PHP to bring down the cost of these checks in production to a negligible level, as mentioned in my previous message (static analysis and JIT). — Benjamin On Fri, 25 Oct 2019 at 10:09, Peter Bowyer wrote: > On Thu, 24 Oct 2019 at 13:47, Rowan Tommins > wrote: > > > I think this performance impact is a real concern; PHP is the only > language > > I know of which implements type checks entirely at run-time in production > > code, and we should ask ourselves if that's definitely the right > approach. > > > > As they are runtime checks, would an ini setting where they can be > completely disabled be feasible? So during development and in production > when the performance decrease doesn't matter, I can have the full runtime > type checking. But when absolutely needed, the checking can be disabled. > > Peter >
Re: [PHP-DEV] Re: [RFC] Union Types v2
>
> I think this performance impact is a real concern; PHP is the only language
> I know of which implements type checks entirely at run-time in production
> code, and we should ask ourselves if that's definitely the right approach.
Would it be possible, at least in principle, to build a static analysis
> tool which could prove that certain type checks would never fail, and prime
> OpCache with code that leaves them out? As I understand it, this is how
> Dart works: the compiler only emits run-time checks for assertions it can't
> prove true by static analysis.
I was wondering the same thing, especially in the light of preloading,
where a lot of class/function definitions are known on startup.
For example, doing:
function x(): int {}
function y(int $foo) {}
y(x());
Should definitely not redundantly check the type of the y() parameter, if
possible.
Also, in the case of JIT, shouldn't type hints actually *improve*
performance?
— Benjamin
On Thu, 24 Oct 2019 at 14:47, Rowan Tommins wrote:
> Hi Dmitry,
>
> On Wed, 23 Oct 2019 at 16:43, Dmitry Stogov wrote:
>
> > Actually, I think PHP already took wrong direction implementing "typed
> > references" and "type variance".
> > Introducing more "typing", we suggest using it, but this "typing" comes
> > with a huge cost of run-time checks.
> > From 10% (scalar type hint of argument) to 3 times (typed reference
> > assignment) performance degradation.
> > Anyone may rerun my benchmarks
> > https://gist.github.com/dstogov/fb32023e8dd55e58312ae0e5029556a9
> >
>
>
> I think this performance impact is a real concern; PHP is the only language
> I know of which implements type checks entirely at run-time in production
> code, and we should ask ourselves if that's definitely the right approach.
>
> Would it be possible, at least in principle, to build a static analysis
> tool which could prove that certain type checks would never fail, and prime
> OpCache with code that leaves them out? As I understand it, this is how
> Dart works: the compiler only emits run-time checks for assertions it can't
> prove true by static analysis.
>
> The simpler idea I had in this area was caching what type checks a value
> had passed, either on each zval or perhaps just at the class level, so that
> checking the same type again would be much faster, even if it was a complex
> union with multiple interfaces.
>
> Regards,
> --
> Rowan Tommins
> [IMSoP]
>
