Ahead of Time Compiler/AOT for PHP8?

[appifys]

Description

Hi,

Is it possible to compile the PHP8 bytecode directly to native machine code (just like what JIT does right now) or at least cache the JIT'd code into a file, and distribute that file only without source/bytecode for PHP8?

I am a senior engineer at a tech company, and I know for a fact many other companies are holding off on PHP as it doesn't offer Ahead of Time Compilation for performance and security reasons - and many have decided to use Rust over it.

We are open to paying for this feature to be implemented, if that's what it takes?

Thank you

[iluuu1994]

Hi @appifys!

I think what you're suggesting could make sense (it's also something that gets discussed frequently internally) but unfortunately it's impossible to tell how much of a difference it would actually make.

and many have decided to use Rust over it.

I think it's important to note that even in the best case scenario with all the optimization and compilation, PHP will likely always be factors slower than C/C++/Rust. It not only comes down to the type of execution (interpretation of source code, interpretation of opcodes, JIT, machine code, etc) but also how the language is designed and what optimizations are possible.

PHP is very dynamic, that's one of its strengths in terms of usability but also one of its weaknesses when it comes to performance. The fact that you can defined classes/functions in if statements or include different version of them from different files makes it impossible to make any kind of assumptions about their types or behavior. So if our primary goal was to optimize performance we might also have to tweak the languages behavior to better fit this goal.

Also note that there are some good ways to improve PHPs performance.

• There's approaches like Roadrunner, php-pm and the likes which keep workers running to avoid the cost of bootstraping for each request. The JIT also has better chances of making a difference in long-standing processes.
• Requires more work, but you can use things like varnish to cache things that don't change between requests

[appifys]

Hi @iluuu1994 Thanks so much for the reply!

Performance isn't why companies like us use PHP. We love the flexibility it provides. But the reasons why a lot of corporate tech companies are choosing Rust over PHP is the same reasons why there's a huge community demanding the .NET Core/Framework offer a true AOT compiler for decades.

They want an AOT solution because of two main reasons:

1. Overhead reduction
   When there's no JIT, no interpreter, just native, or at least semi-native code execution results in much less overhead, and therefore lower memory and CPU footprint in general.
2. Source Code Security:
   When we ship products, we want to be able to ship a compiled binary to offer a good level of source code protection (while retaining baseline performance)

E.g. we don't want our clients to just easily copy and paste our code, otherwise they won't stay our clients for long.

We want to make it as difficult as possible for them to copy our code (i.e. if it is compiled to somewhat-native machine code) while retaining performance. We are aware of PHP obfuscators, but those sacrifice performance, and sometimes even functionality.

We are willing to pay to get this work done. I don't imagine it's too difficult - just caching the JIT'd code to a file, and stripping the bytecode?

Thank you for reading

[iluuu1994]

why there's a huge community demanding the .NET Core/Framework offer a true AOT compiler for decades

To be fair, I think C# / .NET Core has a lot of things going for it. The language is great, the community is big, it's now cross platform, the tooling is great and yes, it's fast.

We are willing to pay to get this work done. I don't imagine it's too difficult - just caching the JIT'd code to a file, and stripping the bytecode?

In general, nothing is easy in a programming language with as many entangled features as PHP 😜 It's also not completely clear what the goal is, a single binary that can be executed as a standalone application, a file that PHP can run, does it need to support all of PHP or a subset, what about extensions, or including other PHP files, etc. As for how difficult / time consuming it would be, the only person to probably tell at this point is Dmitry. @dstogov Can you tell in what way this would be realistic at all?

[rquadling]

There was Zend Guard for a while. The idea here was that the opcodes generated by the compilation phase would be distributable, but even that (with some effort) was reversible. I don't know if this project (and others) are still in play.

Edit: Well https://www.zend.com/products/zend-guard is still in play but seems not updated for PHP 7+.

[dstogov]

Hi,

AOT won't make any performance improvement. The current benchmarks of Tracing vs Function JIT prove this on both small tests and huge apps. (HotSpot JVM proves the same).
The current implementation of function JIT may be transformed into AOT JIT. It's also possible to implement AOT through translation to C with the following compilation by C compiler.
I think, PoC prototype might be implemented in ~3 months, the product quality would take 1-2 years of a small team.
Personally, I'm not interested in AOT and prefer extending tracing and region-based JIT.

[appifys]

Thank you for the reply.

We did not say performance would be better - we meant overhead would be smaller. E.g. smaller memory footprint, lighter on CPU. Zend OP code is trivial to decode and recover source code, but the natively compiled OP codes would not be, and thus provides source code security.

@iluuu1994 I agree, C# has a lot of great things going for it, but the final missing piece is a true AOT compiler, which is why there's a community that's been asking MS for this for over a decade now.

@dstogov I am wondering, there was a project, https://github.com/vjardin/bcgen, that outputted the OP codes to a file which can be executed without the original source code. From looking at their code, it seemed they just hooked into the Zend Accelerator, and made it output the bytecode to a file. Could we possibly do the same for the JIT'd native code?

Thanks

[dstogov]

I didn't see bcgen before. It's not a big problem to serialize Zend bytecode, with native JIT-ed code this is much more difficult. The code must be position independent (PIC), it must be somehow linked with PHP. Also the AOT compiled binary is going to be restricted by single PHP version and set of extensions.

[cmb69]

Given the amount of work to implement and maintain that, and the doubtful benefits, I think this needs to go through the RFC process.

[iluuu1994]

Given this is unlikely to happen I'm closing this issue.