All free PHP compilers that are presented here can rebuild PHP scripts into machine code that can run on a computer without downloading a special PHP interpreter, or compile them into a bytecode command line interface (NET or Mono framework or Java bytecode is required for installation (where a Java Virtual Machine is required for installation)).
Such compilers can be useful for a variety of purposes: they can speed up the execution of your script because they are no longer interpreted at runtime; or thanks to them, you can distribute your applications without revealing the source code (which other commercial scripts require). I suppose they are also suitable for the case where someone wants to write web-dependent PHP programs and distribute them with the functionality of running on the desktop (as opposed to regular web applications that run on a server), this is all possible because that PHP is an easy-to-learn programming language and basically contains many built-in functions with Internet access. (In this case, you will either have to distribute applications with a built-in web server or use a compiler that compiles the server into your application.)
By the way, if you want to use obfuscation in your code, then know that this is also possible when using PHP accelerator. Such accelerators also imply an increase in the speed of execution of your script.
Useful information for those who do not yet know that the official version of the PHP translator can be downloaded from the PHP website: Hypertext Processor.
Free PHP compilers for composing native code, .NET or Java bytecode scripts.
Bambalam (new)
This program produces standalone Windows EXE applications for your PHP source code. It's not really a native code compiler since it just encodes source code and embeds a PHP interpreter, but it's certainly a good fit for people looking for native and byte-code compilers. By the time the entire program was written, its execution environment was the built-in version of PHP 4.4.4 (the program had not been updated since 2006). The source code for Bambalam is publicly available.
Phalanger (for .NET)
Phalanger compiles your PHP code into CLI bytecode (.exe or .dll). This program can be run through .NET 4.0 or Mono frameworks. Your PHP code can use any .NET objects and additional standard PHP extension libraries. The resulting NET assembly can be either signed or hidden. The program also produces templates that allow you to create PHP applications using Visual Studio. The program is released under the Apache license.
HipHop for PHP (for native code)
HipHop translates your PHP code into C++ code, which is later compiled using the GNU C++ compiler into executable binary code. The compiler supports all the features of PHP 5.3 (except of course for things like eval()). It works and compiles code for 64-bit Linux and FreeBSD. Since the program is distributed in source code form, you will have to compile manually (yourself). It is released under the PHP License.
Roadsend PHP (for native code).
The Roadsend PHP compiler produces native binaries (executables) for Windows and Linux. Your scripts are not limited to console programs (command lines): they can be built using embedded web servers, allowing them to run in the same way they run on a website, albeit on your own user system. The compiler is released under the GNU GPL license and runs under the GNU LGPL. Unfortunately, the program has stopped its active development.
Project Zero (for Java)
(Note: This software appears to be defunct. The site has been inaccessible for about half a year now.) Project Zero includes a compiler and CLR that can compile your PHP code into Java bytecode and run it. Note that Project Zero is more than just a PHP compiler/runtime; it provides a rich framework that allows you to enhance web applications using PHP or Groovy (another scripting language). This compiler is available for Windows, Mac OS X and Linux. In order to work with this compiler, you will need to download the Java Development Kit.
Which of the proposed compilers do you prefer? Or do you have another favorite translator? Leave your remarks and comments below, we will be happy to read them and reel them in.
Tags: PHP compilers, script translation
There are two types of programming languages: interpreted and compiled. What language is PHP? In order to answer this question, we need to understand the terminology.
A program that translates code written in one programming language into another is called a translator. A compiler is also a translator. It translates code written in a high-level language into machine code. The compilation process creates a binary executable file that can be run without a compiler.
An interpreter is a completely different category. The interpreter does not translate the code, but executes it. The interpreter analyzes the program code and executes each line of it. Every time you execute such code, you must use an interpreter.
In terms of performance, interpreters are significantly inferior to compilers, since binary code executes much faster. But interpreters allow you to fully control the program during its execution.
As for PHP, it is neither a compiler nor an interpreter. PHP is a cross between a compiler and an interpreter. Let's try to understand this and look at how PHP processes code.
Let's look at the picture:
We see that PHP is composed of two almost independent blocks - a translator and an interpreter. Why did you need to do this? Of course, for reasons of speed.
The PHP input is a script. It translates it (translates it), checking the syntax, into a special bytecode (internal representation). PHP then executes the bytecode (not the program code itself), but it does not create an executable file.
Bytecode is much more compact than ordinary program code, so it is easier (and faster) to interpret (execute). Judge for yourself: parsing is carried out only once at the translation stage, and a “semi-finished product” is executed - bytecode, which is much more convenient for these purposes. Therefore, PHP is more of an interpreter than a compiler. This “double work” was necessary for the following purposes.
Consider the loop:
For (i=0;i<10; i++) { Operator_1; Operator_2; Operator_3; ............ Operator_99; Operator_100; }
This cycle will “spin” 10 times. For each of these ten passes, the interpreter must 100 lines of code. And it needs to analyze and execute 10*100 = 1000 lines of code! If you convert the entire loop into bytecode once, then it will have to analyze 10 times less! This means that scripts will run 10 times faster!
It turns out that PHP is.
The main phase of PHP's work is the interpretation of the internal representation of the program and its execution. It is this phase that takes the most time in serious scenarios. However, the slowdown is not that significant.
It is worth remembering that PHP version 3 was a “pure” interpreter, and with PHP 4 scripts began to run much faster, since PHP version 4 (and PHP5) is an interpretive translator.
The Perl language, which is almost always called a compiler, works in exactly the same way - it translates program text into an internal representation, and then uses the resulting code during execution. So, we can say that PHP version 4 is a compiler in exactly the same way that Perl is.
So, we are forced to conclude that PHP is an interpreter with a built-in translation block that optimizes the flow of interpretation.
Using an interpreter (and therefore PHP) has its undeniable advantages:
- There is no need to worry about freeing the allocated memory, there is no need to close files when you are finished working with them - the interpreter will do all the routine work, since the program is executed under its watchful control;
- There is no need to think about variable types, and there is no need to declare a variable before its first use;
- Debugging programs and detecting errors is greatly simplified - the interpreter has complete control over this process;
- In the context of web applications, the interpreter also has a very important advantage - there is no danger of the server “freezing” if the program does not work correctly.
There are other advantages too. In general, using an interpreter can give scripts the power that Web users expect from them.
The performance penalty of PHP is noticeable in the case of large and complex loops, when processing a large number of lines, etc. However, note that this is the only drawback of PHP, which will appear less and less as more powerful processors are released, so that eventually , disappear altogether.
|
<<< Назад
(What's new in PHP5?) |
Content |
Forward >>>
(Transition to PHP 5.3) |
| If you have any other questions or something is not clear - welcome to our | |
|
|
PHP is an interpreted programming language; with each request, the source code is analyzed and “executed”. This approach, of course, is very convenient at the project development stage, but it introduces an extra step into the process of executing production code. Thus, interpretation, which at first glance is PHP's strong point, costs extra CPU time and resources.
Below we will talk about compilers that allow you to compile PHP code into C++, and it into executable code. Thus, PHP applications are executed directly by the processor, bypassing the interpreter.
Let's check if everything is so good in practice.
How the interpreter works
Interpretation of PHP code takes place in two stages:
- Code parsing and generation of opcodes (Zend opcodes) - instructions understandable to the interpreter.
- Execution of opcodes.
While the first phase lends itself well to optimization (using an opcode cache), the second is quite closed - the interpreter is always an intermediary between the set of instructions and the processor executing them. Without an interpreter, the processor cannot understand what to do with opcodes.
To get rid of the interpreter link, compilers were invented, the most popular and recent of which is HipHop from Facebook. Let's feel it closer.
HipHop PHP
HipHop is written by Facebook developers and is an application that:- optimizes PHP code
- converts to C++
- generates from your application a multi-threaded web server that executes it
- compiles into executable code using g++
Thus, the input is PHP code, the output is a server, part of which is the written functionality.
Let's check how HipHop can handle compiling an application written using a framework, such as Wordpress.
Compiling Wordpress
After installing HipHop, in the src/hphp/ folder we will get the hphp file, which is the compiler. Before compilation starts, set the environment variables:
Cd .. # go to the folder with hiphop export HPHP_HOME=`pwd` export HPHP_LIB=`pwd`/bin export CMAKE_PREFIX_PATH=`/bin/pwd`/../
and go ahead!
Download Wordpress and unzip the archive:
Wget http://wordpress.org/latest.tar.gz tar zxvf latest.tar.gz
Copy wp-config-sample.php to wp-config.php and specify the settings for connecting to the database (in the host settings we specify 127.0.0.1, not localhost).
For successful compilation you need to patch Wordpress a little:
- Open wp-includes/js/tinymce/plugins/spellchecker/classes/SpellChecker.php and replace: function &loopback(/* args.. */) ( return func_get_args(); ) with function &loopback(/* args.. */ ) ( $ret = func_get_args(); return $ret; )
- In wp-includes/query.php, instead of if (!isset($q["suppress_filters"])) $q["suppress_filters"] = false; insert $q["suppress_filters"] = true;
Wordpress is ready.
Hiphop needs to specify the list of files that we will compile - we will get it and save it in files.list:
Find. -name "*.php" > files.list
Everything is ready for compilation, let's proceed:
$HPHP_HOME/src/hphp/hphp --input-list=files.list -k 1 --log=3 --force=1 --cluster-count=50
After completing the command, in the temporary folder (at the beginning of compilation, hphp will show its path, something like “/tmp/hphp_ptRgV1”) we will receive a compiled web server. Let's launch it (if something is hanging on port 80, for example apache or nginx, you must first stop it to free the port):
Sudo /tmp/hphp_6s0pzd/program -m server -v "Server.SourceRoot=`pwd`" -v "Server.DefaultDocument=index.php" -c $HPHP_HOME/bin/mime.hdf
Voila! By going to http://localost we will see a working Wordpress blog.
Performance
Let's see if there will be a performance increase compared to the uncompiled version of WordPress running on apache2. Below are graphs of the dependence of page generation speed on the number of parallel users.
As you can see, the results were shocking: the compiled blog runs on average 6 times faster! The average number of requests processed per second in the uncompiled version is 9, and in the compiled version it is 50! I don’t know about you, but these results amazed me; I didn’t expect such a strong performance increase.
Summarize
After such stunning results, only one thing can be said - the guys from Facebook did a great job. The compiler really makes a rocket out of an application, and although the application needs to be prepared before compiling, the result is worth it.
To the point:
If you liked the post, click on Google +1 - it will give me more motivation to write and it will just be a pleasure.
Alexey Romanenko: My name is Alexey Romanenko, I work at RBC. The topic of this report is somewhat controversial. It would seem, why compile PHP scripts when everything seems to work like that?
Probably the main question is: “Why?” In general, the purpose of this presentation is to try to understand whether such a compilation is needed, if so, why, in what form and to whom.
What is a PHP compiler?
First, a short overview of what a PHP compiler is. I'll tell you how it works, what it is and how you can speed it up.
The first functional module is the so-called SAPI (Server API), which provides an interface for accessing PHP from various clients (Apache, some kind of CGI server (Common Gateway Interface) and others). There is also SAPI embedded, which allows you to embed PHP into any application.
The second main part is PHP Core, which processes requests, implements all work with the network, file system and parsing the scripts themselves.
The third global part is the Zend Engine, which compiles our scripts into some bytecode, executes it on its virtual machine and handles memory management (implements comprehensive allocators).
One of the most important and largest parts is the Extentions module, which implements 99% of what we use in PHP. These are either “wrappers” for some libraries, or functionality, or classes, built-in libraries, etc. We can also write our own extensions.
How is the script itself executed?
First. Lexical analysis occurs - the file is downloaded, parsed, all the characters from the set of this file are translated into a certain set of tokens, which we then work with.
The parsing phase parses these tokens. Based on this analysis, a certain grammatical structure is compiled, on the basis of which the bytecode will then be generated.
At the end, Zend Engine executes it. The result is returned to the client.
We are talking about high loads. If you repeat this scheme of actions every time, everything will work very slowly. When our interpreter receives several hundred or thousand requests at the same time, the speed is simply nonexistent.
But there are solutions. They have been known for a long time.
How to achieve acceleration?
The simplest, cheapest and well-tested solution is bytecode caching. Instead of going through the parsing phase, we simply cache our bytecode. There are special extensions for this - they are well known to everyone who has worked with PHP - these are APC, eAccelerator, Xcache and so on. Zend Engine simply executes the bytecode.
The second option is code profiling, identifying bottlenecks. We can rewrite something as PHP extensions (this will be an extension in C/C++), compile it and use it as modules.
The third option is more global - forget about PHP and rewrite everything. In general, this option has a right to life, but only in the case when there is not enough PHP code. In large, large projects (or that have existed for quite a long time), a lot of it usually accumulates, and it will take a long time to rewrite everything. Business requirements will not allow you to do this. In general, writing something in PHP, for example, for a front-end server, does not take too long, because it is a simple language. It allows you to quickly do things that take longer to do in low-level languages.
There is an alternative option, which has recently become widespread, and that is to compile PHP somewhere, into something faster.
Let's compile something?
By the word “compilation” I will mean the translation of PHP script code into something else, into some other code.
In this case it can be of two types.
Native code is a kind of binary file that can be executed on a physical machine.
Non-native code. You can compile some bytecode that can be executed on another virtual machine, for example, on the JVM.
How can you compile native code from PHP?
Roadsend compiler. Its sequel is Raven. There is also PHC (this is a PHP Open Source compiler). Recently, HipHop (Facebook) has also appeared.
I'll give a short overview of what can be done for non-native code. As far as I know, there are 3 working options. This is bytecode generation for Java and bytecode generation for .Net: Quercus, Project Zero, Phalanger. I will not consider compilation into non-native code, because we do not use it. Let's return to compilation into native code.
In my opinion, the oldest compiler is Roadsend. It began to be developed quite a long time ago, in 2002. It was originally a commercial application. It was closed, only in 2007 it was released into Open Source. There is a very complex compilation scheme: a certain Bigloo compiler is used for the Scheme language, after which native code is generated. This compiler does not use the Zend Engine.
We can either generate a separate executable binary or generate a module for Apache. It is also possible to generate a binary that will work as a web server. But it doesn't work. I don't know why, but it doesn't work for me at all.
As far as I know, work on Roadsend is not currently underway. It evolved into the Raven project, which was completely rewritten in C++. As a compiler, it uses LLVM to generate code.
At the moment everything looks very promising.
But it is still under construction. Even in the documentation there are hints that we will not generate binaries. Wait.
Things would be sad if we didn't have PHC. This is an OpenSource compiler. It has been developed since 2005. One of its disadvantages: it uses built-in SAPI. We are not abandoning the Java machine, the Zend Engine. Essentially, it translates PHP code into PHP extension module code. After that, it compiles, but the execution process, again, involves the Zend Engine.
Example of using PHC
Very similar to how we work, for example, with conventional compilers, gcc. The first one shows that there is one binary, we can also simply generate the C code. Since the same gcc is used inside after generating this code, we can use those flags that are intended for optimization and other things.
We were talking about an application that runs on the command line.
To launch a web application you need to perform several steps, it is quite complex. First you need to generate an extension, then compile the code, and then somehow (either dynamically or statically) connect it.
Key benefits of PHC
Essentially, we use the same PHP, we are fully compatible. All other extensions are supported. We use everything that we have compiled. Pretty good documentation.
By the way, one of the additional bonuses of PHC is that you can generate the XML work of our script based on how XML is constructed, sometimes this can be useful.
Minuses
In my opinion, this is an inferior binary, because it still has a dependency on Zend Engine. There is also some complexity in terms of connecting web projects.
The main thing
This report probably would not have happened if HipHop, a solution from Facebook, had not appeared. Its creators also accumulated a large amount of PHP code and thought for a long time what to do with it.
As I understand it, after the options to rewrite everything were rejected, it was decided to write some kind of translator (in this case into C++ code). The project is relatively young; it was officially released only in February of this year. PHP code is translated into C++ code and then generated using standard tools on your operating system. However, for now only the Linux operating system is supported.
Just yesterday I asked a Facebook representative about this decision. He said that currently 100% of PHP code is compiled through HipHop. The code does not work in its pure form through the PHP interpreter. Again, the creators announced a significant reduction in processor load.
Basic functionality of HipHop
It directly generates the binary itself, which can be executed on the command line. There is such an option for launching it as a streaming web server. There is also a separate built-in debugger. It can debug scripts both locally and remotely (it will work as a server).
The assembly process is quite non-trivial. There is a description, but it is not collected everywhere. At the moment, as I said, everything is assembled for Linux, plus initially everything was “tailored” for 64 bits. Although 32 bits are now experimentally supported. But I managed to assemble it and patch it a little - in general, it did all this, because it is not assembled by default.
In addition, they have their own versions of libcore and, in my opinion, there are a couple of libraries that also need to be patched. In general, the assembly process is not that simple.
At the output after assembly, we receive a certain hphp file, which is a translator of our PHP code into C++. If we look at the flags, there are quite a lot of them. I have highlighted here a few basic ones that you may need.
We can use a file in HDF format as a configuration file (config), specifying various directives. We can set the error level and other things there (HDF is everything that is available in a structured form). We can also take the config itself from the database or use it directly on the command line.
We set the logging level during compilation: show all errors or also display warnings, additional information, or generally keep a full log of everything that happens.
A very useful directive is input_list=FILE, which allows us to specify a list of scripts that we want to compile. It is also worth mentioning a directive such as lazy-bind. We can specify all project files - those that will be compiled.
Example of running PHP script compilation
The third level of logging has been installed, there is quite general information on time, you can see how long it took. In fact, the script is quite simple. This is the usual “Hello, World”, I just took a screenshot.
The heaviest file is our “program” binary, its size is 28 MB. Essentially, our "Hello, World" weighs 28 MB. I wanted to note that in addition to the standard line “Echo “Hello, World!”, this binary includes a lot more. This is a full-fledged web server, a full-fledged server for administration.
What are we doing?
We have “Hello…” in C++, which performs a function consisting of one line “echo “Hello, World”. In addition, a lot of third-party stuff is loaded. As we can see, this is a full-fledged file in C++.
This is the resulting program. It already contains quite a few different keys for different configurations, but I will only mention a few of them.
This is --mode, this is the launch mode of our program. We can run it either directly (from the command line) or in web server or full-fledged daemon mode. There are a couple more options, but they are unimportant.
config is used in the same format. I did not give directives because there are a lot of them. HipHop comes with documentation. It is not on the wiki site, but documentation is provided with the distribution, where everything is clearly described. I didn’t even expect that the description would be so detailed. This allows you to configure the solution quite flexibly.
To run in server mode, we can specify the port. For administration, a separate port is used, where you can send some requests that allow you to manage the server. If we have a debugging server running, then we indicate the host and port where we will “bind” for debugging.
Launch example
For example, we specified port 9999 for broadcasting. By performing simple http requests, we can receive either statistics, or somehow manage the server, or obtain some additional information. In general, it is very convenient.
Option to get status information
It is possible to receive the server status set in various built-in formats (xml, json, html). Essentially, information is provided about the server master process itself and the handlers - threads that process requests.
Additional Statistics
In fact, a lot of statistics are provided. Because HipHop works natively with memcache and SQL in the form of MySQL, it provides detailed information on all operations that are performed with it.
Complete memory statistics
There is a very useful feature here - Application Stats. Using the additional functions of HipHop itself in PHP, we can write statistics in our scripts, which we then receive through regular access to http.
Debugging
As I already said, it is possible to use the built-in "debug" to debug scripts. This is very convenient because the hphpi interpreter works similarly to what we have compiled. There is a difference in the “behavior” of scripts when they are executed in standard PHP and when using some compiled data. To debug what is compiled, Facebook wrote a separate interpreter.
In the first case, we run the code with the “-f” switch and see how the file behaves; all output goes to stdout. Or we can run it in debug mode and get into the interactive debugger. It is very similar to standard GDB: you can also set breakpoints, run, enter variable values, track, and more.
One of the additional features
We have a program that turned out after compilation. It can be used as an RPC server. We run requests over http, and by calling the params function, we can pass a parameter as either a json array or a separate parameter. We will have json returned, which returns the results of these functions. This is very convenient - the necessary functionality is already built in from the very beginning.
Cons of HipHop
At the moment, HipHop does not support language constructs and functions such as eval(), create_function() and preg_replace() with /e, although these are all analogous to eval(). However, in the latest releases, in my opinion, you can still enable eval() via config. But it is not recommended to do this. In general, using eval() is bad.
The main advantages of HipHop
Of course, the main advantage is support from Facebook. It works and is being developed quite actively. A community of developers is emerging around this project. A completely new PHP implementation has been written.
As I already said, the advantage is that native code is generated. A performance increase is claimed by reducing processor load costs (tests confirm this).
It is quite flexible in configuration. I was pleasantly surprised that there are quite a few options for customization. I think this is due to the fact that the project actually works. Everything that is used is incremented.
As I already mentioned, HipHop provides quite a lot of additional features. These include use as an RPC server, administration, various statistics and much more. By the way, there is also an API for working with other languages.
Quite good documentation has been written for this solution. Another advantage: this is a solution that is actually ready for use in production (example: Facebook).
Minuses
The main disadvantage is that at the moment a rather limited number of modules are supported. For example, when working with a database, we can only use functions for working with MySQL. There is no PostgreSQL support here.
There is also such a thing as the complexity of assembly, which I already mentioned. There are problems with building on 32-bit systems. But I think this will be fixed soon. For now, only compilation from PHP 5.2 is used. Version 5.3 is not supported yet, but will be supported as promised.
What should you not expect from the compilation in general and from HipHop in particular?
Compiling will in no way speed up your slow SQL queries in the database. If the bottleneck is the database, then compile it or don’t compile it, it won’t do any good.
Compilation does not speed up static loading, only dynamic loading. It makes debugging much more difficult. Many people are probably used to the fact that everything is quite easy to debug in PHP. This will no longer happen during compilation. Although, as I noted, Facebook has made this process as easy as possible, without it it would be even more difficult to compile every time.
Don't expect this to be some kind of “silver bullet” that will solve all your problems. In fact, compilation solves a fairly narrow range of problems. If they are, then this may help.
What problems does compilation solve?
It reduces the load on the CPU, since when actively working with PHP and a large number of requests, the load on it increases quite significantly. Of course, I would like to conduct some tests.
Testing
The first test (the simplest) is a rather expensive operation that takes quite a long time to complete. In the tests, I tried to abstract myself and not make requests using some external resource.
The load falls entirely on the processor. The test showed that HipHop "won" against everyone: it works almost one and a half times faster than the standard PHP compiler. PHC passed this test very slowly.
For the second performance test, I used the official PHP script, which can be downloaded from SVN. It performs a number of functions that perform sorting, assignment, summing - quite expensive operations from a mathematical point of view.
HipHop was ahead again. Moreover, with standard PHP the time difference is approximately 3 times. PHC performed better here, but was about half as bad as HipHop.
PHP is mainly used for threads that handle http requests - this is worth keeping in mind.
Several standard configurations (Apache with PHP, Nginx with fpm-php and plug-in APC for code caching). As a fifth option - HipHop.
To be honest, I conducted the tests not on the server, but on a laptop. The numbers, of course, may not fully correspond to reality, but in this case the results are normal. It is worth noting that as the load increases, the number of requests and the total number of requests simultaneously increases. Next is RPS. We tested a standard page that includes 10 simple inclusions. Essentially, this is testing PHP as an interpreter.
Question from the audience: What are the numbers in the cell - seconds?
Alexey Romanenko: This is fps.
Here we can conclude that as the number of simultaneous requests increases, HipHop behaves very well.
It can be seen that using APC is standard practice. It shows that it adds, for example, as Apache a performance boost of about 2 times. This also happens with Nginx. But the fact that Nginx is slow does not mean that this package is worse. Just a specific test. If we really test here, then Apache will “die” on slow requests.
We probably want to understand whether we need this or not.
When should you think about compilation?
Most likely, this is needed when we see that our bottleneck is the CPU. If we're CPU-bound using PHP as the standard interpreter, it's probably worth considering that maybe part of the project can be compiled.
For some cases when your application needs autonomy to run, this method is unlikely to be suitable.
Reducing the number of servers. When there are a lot of servers, then by reducing the productivity by 2 times, roughly speaking, we also reduce the number by half. When it’s one server, it makes no sense, but when there are 100-200 of them, then it probably makes sense.
The main reason why Facebook began to use HipHop is the presence of large amounts of PHP code that there is no way to rewrite (or there is no one, or it is simply expensive). Increasing productivity by 2 times is already good.
Probably everything. Waiting for questions.
Questions and answers
Question from the audience: Hello. Please tell me if you have any other examples of successful implementations of Hiphop, besides Facebook. Would you like to transfer the RBC website, for example, to HipHop? Alexey Romanenko: I'll start with the second one. The RBC website is difficult to translate. Regarding successful implementation. I compiled PHP Unit myself, it compiled successfully. Also, as far as I know, the PHP Bunty board compiles successfully. A number of organizations, in fact, already use compilation. Further tests will show how justified it will be to use this project. Question from the audience: Can you give an example of an organization that uses it? Alexey Romanenko: Honestly, I won’t tell you now, but this is the West. As far as I know, no one uses it here. Question from the audience: What is the difference at runtime other than lack of support for some of the features you mentioned. How dangerous is it to translate a “live” project? Alexey Romanenko: The difference is that any compiled program can crash. Perhaps some problems will appear that have not yet been identified. In fact, there are a number of differences in the "behavior" of PHP itself. I did not include them because more detailed information can be found in the documentation. The Facebook team has written its own interpreter, which is essentially 99.9% equivalent to the one that will work in compiled form. It is better to test your code not with a standard PHP interpreter, but, as I said, with hphpi for PHP.
