How does HHVM improve PHP performance?

Added in January 2014: The current promotion momentum of HHVM in the factory is very good. It is recommended that everyone try it in 2014, especially now that the compatibility test has reached 98.58%, and the modification cost has been further reduced.

Background

HHVM is a high-performance PHP virtual machine developed by Facebook. It is claimed to be 9 times faster than the official one. I was very curious, so I took the time to briefly learn about it and compiled this article. I hope it can answer two questions:

• Is HHVM reliable? Can it be used in products?
• Why is it so much faster than official PHP? How is it optimized?

What would you do?

Before discussing the implementation principles of HHVM, let’s put ourselves in your shoes: Suppose you have a website written in PHP that encounters performance problems. After analysis, you find that a large part of the resources are consumed in PHP. How would you optimize PHP performance?

For example, there are several ways:

• Option 1, migrate to a language with better performance, such as Java, C++, Go.
• Option 2, separate the functions through RPC and implement them in other languages, allowing PHP to do fewer things. For example, Twitter puts a lot of business logic into Scala, and the front-end Rails is only responsible for presentation.
• Option 3, write PHP extension and switch to C/C++ at the performance bottleneck.
• Option 4, optimize PHP performance.

Option 1 is almost unfeasible. Ten years ago, Joel warned with the example of Netscape that you will give up years of experience accumulation, especially for products with complex business logic like Facebook. There are too many PHP codes. According to the It is said to have 20 million lines (quoted from [PHP on the Metal with HHVM]). The cost of modification is probably greater than writing a virtual machine, and for a team of thousands of people, learning from scratch is unacceptable.

Option 2 is the safest solution and can be migrated gradually. In fact, Facebook is also working hard in this regard and has also developed RPC solutions such as Thrift. Another language mainly used within Facebook is C++. From the early days You can see this in the Thrift code, because the implementations in other languages ​​are very crude and cannot be used in a production environment.

Currently in Facebook, it is said that PHP:C++ has increased from 9:1 to 7:3. Coupled with the presence of Andrei Alexandrescu, C++ is becoming more and more popular in Facebook, but this can only solve part of the problem. After all, the cost of C++ development Much higher than PHP, it is not suitable for use in places that are frequently modified, and too many RPC calls will seriously affect performance.

Option 3 looks good, but is difficult to implement in practice. Generally speaking, the performance bottleneck is not very significant, and is mostly the result of continuous accumulation. In addition, the cost of PHP extension development is high. This solution is generally only used in public applications. And it is based on a basic library that has not changed much, so this solution cannot solve many problems.

It can be seen that the first three solutions cannot solve the problem well, so Facebook actually has no choice but to consider the optimization of PHP itself.

Faster PHP

Since we want to optimize PHP, how to optimize it? In my opinion, there are several methods:

• Option 1, optimization at the PHP language level.
• Option 2, optimize the official implementation of PHP (that is, Zend).
• Option 3, compile PHP into bytecode (bytecode) in other languages, and run it with the help of virtual machines (such as JVM) in other languages.
• Option 4, convert PHP to C/C++, and then compile it into local code.
• Option 5, develop a faster PHP virtual machine.

PHP language-level optimization is the simplest and feasible. Of course Facebook has thought of it, and has also developed performance analysis tools like XHProf, which is very helpful in locating performance bottlenecks.

However, XHProf still failed to solve Facebook's problem well, so we continue to look at it. Next is option 2. Simply put, the execution process of Zend can be divided into two parts: compiling PHP into opcode and executing opcode, so optimizing Zend It can be considered from these two aspects.

Optimizing opcode is a common practice, which can avoid repeated parsing of PHP, and can also do some static compilation optimization, such as Zend Optimizer Plus. However, due to the dynamic nature of the PHP language, this optimization method is limited and optimistic. It is estimated that it can only improve performance by 20%. Another consideration is to optimize the opcode architecture itself, such as a register-based approach, but this approach requires too much work to modify, and the performance improvement will not be particularly obvious (maybe 30%?), so the input-output ratio is not high.

Another method is to optimize the execution of opcode. First, let’s briefly mention how Zend executes it. After Zend’s interpreter (also called interpreter) reads the opcode, it will call different functions according to different opcodes (actually some are switches, but for I have simplified the description for convenience), and then perform various language-related operations in this function (if you are interested, you can read the book "In-depth Understanding of the PHP Core"), so there are no complex encapsulation and indirect calls in Zend, as an explanation It's already done very well for the device.

If you want to improve the execution performance of Zend, you need to understand the underlying execution of the program. For example, function calls actually have overhead, so they can be optimized through Inline threading. Its principle is like the inline keyword in C language That way, but it expands related functions at runtime and then executes them in sequence (just an analogy, the actual implementation is different), and it also avoids the waste caused by CPU pipeline prediction failure.

In addition, you can also use assembly like JavaScriptCore and LuaJIT to implement the interpreter. For specific details, it is recommended to read Mike’s explanation

But these two methods are too expensive to modify, and are even more difficult than rewriting one, especially to ensure backward compatibility, as you will know when I mention the characteristics of PHP later.

Developing a high-performance virtual machine is not a simple matter. It took more than 10 years for the JVM to reach its current performance. So can these high-performance virtual machines be directly used to optimize the performance of PHP? This is the idea of ​​​​Option 3.

In fact, this solution has been tried by people for a long time, such as Quercus and IBM's P8. Quercus has hardly been used by anyone, and P8 is also dead. Facebook has also investigated this method, and there have even been unreliable rumors, but in fact Facebook gave up in 2011.

Because option 3 looks good, but the actual effect is not ideal. According to many experts (such as Mike), VM is always optimized for a certain language, and other languages ​​will encounter many bottlenecks when implementing it, such as dynamic Method calling has been introduced in Dart's documentation, and it is said that the performance of Quercus is not much different from Zend+APC ([from The HipHop Compiler for PHP]), so it doesn't make much sense.

However, OpenJDK has also been working hard in recent years. The recent Grall project looks pretty good, and there are also languages ​​​​that have achieved significant results on it, but I haven’t had time to study Grall yet, so I can’t judge here.

The next step is option 4, which is exactly what HPHPc (the predecessor of HHVM) does. The principle is to convert the PHP code into C++ and then compile it into a local file. It can be considered an AOT (ahead of time) method. About it For technical details of code conversion, please refer to the paper The HipHop Compiler for PHP. The following is a screenshot from the paper, which can be used to get an overview:

The biggest advantage of this approach is that it is simple to implement (compared to a VM), and it can do a lot of compilation optimization (because it is offline, it is okay if it is slower), for example, the above example will - 1优化掉了，但它很难支持 PHP 中的很多动态的方法，如 eval()、create_function(), because this requires another The cost of embedding an interpreter is not small, so HPHPc simply does not support these syntaxes.

In addition to HPHPc, there are two similar projects, one is Roadsend and the other is phc. phc’s approach is to convert PHP into C and then compile it. The following is an example of converting file_get_contents($f) into C code:

<div class="blockcode"> <div id="code_LjU"><ol> <li>static php_fcall_info fgc_info;</li> <li>php_fcall_info_init ("file_get_contents", &fgc_info);</li> <li>php_hash_find (LOCAL_ST, "f", 5863275, &fgc_info.params);</li> <li>php_call_function (&fgc_info) ;</li> </ol></div> <em onclick="copycode($('code_LjU'));">Copy code</em> </div>

Speaking of phc, the author once cried on the blog, saying that he went to Facebook to demonstrate phc two years ago and communicated with the engineers there. As a result, it became popular as soon as it was released, but he has been busy for 4 years but is unknown. Now The future is bleak. . .

Roadsend is no longer maintained. For dynamic languages ​​like PHP, this approach has many limitations. Since it cannot be included dynamically, Facebook compiled all the files together. The file deployment when going online actually reached 1G. It's becoming increasingly unacceptable.

There is also a project called PHP QB. I didn’t look at it due to time constraints. I think it might be something similar.

So there is only one way left, which is to write a faster PHP virtual machine and take this dark road to the end. Maybe you are like me. When you first heard that Facebook was going to build a virtual machine, you thought it was too outrageous, but If you analyze it carefully, you will find that this is actually the only way.

Faster virtual machines

Why is HHVM faster? The key technology of JIT has been mentioned in various news reports, but in fact it is far from that simple. JIT is not a magic wand that can improve performance with just a wave of it, and the operation of JIT itself is also time-consuming. , for simple programs, it may be slower than the interpreter. The most extreme example is that the interpreter of LuaJIT 2 is slightly faster than the JIT of V8, so there is no absolute thing. It is more about the handling of details. The development history of HHVM It is a history of continuous optimization. You can see from the picture below how it surpasses HPHPc little by little:

It is worth mentioning that the new virtual machine ART in Android 4.4 uses the AOT solution (remember? The HPHPc mentioned earlier is this), and the result is twice as fast as the previous Dalvik that used JIT, so JIT is not necessarily faster than AOT.

Therefore, this project is very risky. Without a strong heart and perseverance, it is very likely to be abandoned halfway. Google once wanted to use JIT to improve the performance of Python, but it ultimately failed. For Google, the use of Python is actually There are no performance issues (well, Google used to write crawl in Python [see In The Plex], but that was all in 1996).

Compared to Google, Facebook obviously has greater motivation and determination. PHP is Facebook’s most important language. Let’s take a look at which experts Facebook has invested in this project (not complete):

• Andrei Alexandrescu, author of "Modern C++ Design" and "C++ Coding Standards", the undisputed master in the field of C++
• Keith Adams, who was responsible for the core architecture of VMware. Back then, VMware sent him alone to carry out technical cooperation with Intel, which proves how much he knows about the VMM field
• Drew Paroski, who participated in the development of .NET virtual machine at Microsoft and improved the JIT
• Jason Evans, developed jemalloc, which reduced Firefox’s memory consumption by half
• Sara Golemon, author of "Extending and Embedding PHP", PHP kernel expert, I think all PHP masters have read this book, maybe you don't know that she is actually a woman

Although there are no top experts in the field of virtual machines like Lars Bak and Mike Pall, if these experts can work together and write a virtual machine, it will not be a big problem. So what challenges will they face? Next we discuss them one by one.

What are the specifications?

The first problem you have to face when writing your own PHP virtual machine is that PHP has no language specification, and the syntax between many versions is incompatible (even small version numbers, such as 5.2.1 and 5.2.3). What is the PHP language specification? What about the definition? Let’s take a look at a statement from IEEE:

The PHP group claim that they have the ?nal say in the speci?cation of (the language) PHP. This groups speci?cation is an implementation, and there is no prose speci?cation or agreed validation suite.

So the only way is to honestly look at the implementation of Zend. Fortunately, it has been painfully done once in HPHPc, so HHVM can directly use it, so this problem is not too big.

Language or extension?

Implementing the PHP language is not just as simple as implementing a virtual machine. The PHP language itself also includes various extensions. These extensions are integrated with the language. Zend works tirelessly to implement various functions that you may use. If you analyze the PHP code, you will find that its C code has 800+ thousand lines after excluding the blank line comments. And guess how many Zend engine parts there are? There are just under 100,000 rows.

This is not a bad thing for developers, but it is very tragic for engine implementers. We can compare it with Java. To write a Java virtual machine, you only need to implement bytecode interpretation and some basic JNI calls. Most of Java's built-in libraries are implemented in Java, so if performance optimization is not considered, it is much more difficult to implement a PHP virtual machine than a JVM in terms of workload. For example, someone used 8,000 lines of TypeScript to implement a JVM. Doppio.

For this problem, HHVM’s solution is very simple, that is, only implement what is used in Facebook, and you can also use what has been written before in HPHPc, so the problem is not big.

Implement Interpreter

The next step is the implementation of Interpreter. After parsing PHP, a Bytecode designed by HHVM will be generated, which is stored in ~/.hhvm.hhbc(SQLite file) for reuse. When executing Bytecode, it is similar to Zend, and also puts different bytecodes into Implemented in different functions (this method has a special name in the virtual machine: Subroutine threading)

The main body of Interpreter is implemented in bytecode.cpp. For methods such as VMExecutionContext::iopAdd, the final execution will be differentiated according to different types. For example, the add operation is implemented in tv-arith.cpp. Here is a short excerpt of it

<code class="c++"><div class="blockcode"> <div id="code_oM7"><ol> <li>if (c2.m_type == KindOfInt64) return o(c1.m_data.num, c2.m_data.num);</li> <li>if (c2.m_type == KindOfDouble) return o(c1.m_data.num, c2.m_data.dbl);</li> </ol></div> <em onclick="copycode($('code_oM7'));">复制代码</em> </div>

正是因为有了 Interpreter，HHVM 在对于 PHP 语法的支持上比 HPHPc 有明显改进，理论上做到完全兼容官方 PHP，但仅这么做在性能并不会比 Zend 好多少，由于无法确定变量类型，所以需要加上类似上面的条件判断语句，但这样的代码不利于现代 CPU 的执行优化，另一个问题是数据都是 boxed 的，每次读取都需要通过类似 m_data.num 和 m_data.dbl

if (c2.m_type == KindOfInt64) return o(c1.m_data.num, c2.m_data.num);

if (c2.m_type == KindOfDouble) return o(c1.m_data.num, c2.m_data.dbl);

Copy code

Exactly Because of Interpreter, HHVM has significantly improved its support for PHP syntax compared to HPHPc. In theory, it is fully compatible with official PHP. However, the performance of this alone will not be much better than Zend. Since the variable type cannot be determined, it is necessary to Adding conditional statements similar to the above, but such code is not conducive to the execution optimization of modern CPUs. Another problem is that the data is boxed, and each read needs to go through something like m_data.num and m_data.dbl method to obtain indirectly.
For problems like this, we have to rely on JIT to optimize.
Implement JIT and optimization
First of all, it is worth mentioning that PHP’s JIT has not been tried before:

Someone experimented with LLVM in 2008, and the result was 21 times slower than the original. . .

In 2010, IBM Japan Research Institute developed P9 based on their JVM virtual machine code. Its performance is 2.5 to 9.5 times that of official PHP. You can read their paper Evaluation of a just-in-time compiler retrofitted for PHP. <div class="blockcode">In 2011, Andrei Homescu developed it based on RPython and wrote a paper HappyJIT: a tracing JIT compiler for PHP, but the test results were mixed and not ideal. <div id="code_JSG"> <ol> <li>So what exactly is JIT? How to implement a JIT? </li> <li> </li> <li>In dynamic languages, there is basically an eval method, which can be passed a string for execution. JIT does a similar thing, except that it needs to splice not strings, but machine codes on different platforms, and then to execute, but how to implement it in C? You can refer to this introductory example written by Eli. Here is a piece of code from the article: </li> <li> </li> <li> <li> </ol> </div> <em onclick="copycode($('code_JSG'));">unsigned char code[] = {</em> 0x48, 0x89, 0xf8, // mov %rdi, %rax</div> 0x48, 0x83, 0xc0, 0x04, // add $4, %rax🎜 0xc3 // ret🎜} ;🎜memcpy(m, code, sizeof(code));🎜🎜🎜Copy code🎜🎜

However, it is easy to make mistakes when writing machine code by hand, so the best is to have an auxiliary library, such as Mozilla's Nanojit and LuaJIT's DynASM, but HHVM does not use these, but implements one that only supports x64 (in addition Still trying to use VIXL to generate ARM 64-bit) and make the code executable through mprotect.

But why is JIT code faster? You can think about it. In fact, the code written in C++ is eventually compiled into machine code. If the same code is just manually converted into machine code, what is the difference between it and what is generated by GCC? Although we mentioned some optimization techniques based on CPU implementation principles earlier, the more important optimization in JIT is to generate specific instructions based on types, thereby greatly reducing the number of instructions and conditional judgments. The following picture from TraceMonkey shows this A very intuitive comparison was made. We will see specific examples in HHVM later:

HHVM is first executed through the interpeter, then when will it use JIT? There are 2 common JIT trigger conditions:

• trace: Record the number of loop executions. If it exceeds a certain number, JIT this code
• method: Record the number of function executions. If it exceeds a certain number, JIT the entire function or even inline it directly

As to which of the two methods is better, there is a post on Lambada that has attracted discussions from various experts, especially Mike Pall (LuaJIT author), Andreas Gal (Mozilla VP) and Brendan Eich (Mozilla CTO). I have a lot of my own opinions, and I recommend everyone to watch them, so I won’t show off here.

The difference between them is not only the compilation scope, but also many details, such as the handling of local variables, which will not be discussed here

But HHVM did not use these two methods. Instead, it created its own method called tracelet, which is divided according to type. See the picture below

You can see that it divides a function into 3 parts. The upper 2 parts are used to handle two different situations where $k<code>$k 为整数或字符串两种不同情况的，下面的部分是返回值，所以看起来它主要是根据类型的变化情况来划分 JIT 区域的，具体是如何分析和拆解 Tracelet 的细节可以查看 Translator.cpp 中的 Translator::analyze is an integer or a string. The lower part is the return value, so it seems that it is mainly The JIT area is divided according to the changes in types. For details on how to analyze and dismantle Tracelet, you can view the Translator::analyze

method in Translator.cpp. I haven't had time to look at it yet, so I won't discuss it here.

Of course, various attempts and optimizations are needed to achieve high-performance JIT. For example, initially the newly added tracelet of HHVM will be placed in the front, that is, the positions of A and C in the above picture will be swapped. Later, I tried to put it in the back. As a result, the performance was improved by 14%, because the test found that it is easier to hit the response type in advance

The execution process of JIT is to first convert HHBC to SSA (hhbc-translator.cpp), then optimize SSA (such as Copy propagation), and regenerate it into local machine code. For example, under X64, it is implemented by translator-x64.cpp of.

Let’s use a simple example to see what the machine code finally generated by HHVM is like, such as the following PHP function: <div class="blockcode"> <div id="code_B9S"><ol> <li> <?php <li>function a($b){</li> <li> echo $b + 2;</li> <li>}</li> </ol></div> <em onclick="copycode($('code_B9S'));">复制代码</em> </div> <p></p> <div id="code_B9S"><code class="nasm language-nasm" data-lang="nasm"><?php <div class="blockcode">function a($b){<div id="code_ZLy"> echo $b + 2;<ol>} <li> <li><em onclick="copycode($('code_B9S'));">Copy the code<li> <li> <li> </li> <li>This is what it looks like after compilation:</li> <li> </li> <li> <li> <li> <li> <li>mov rcx,0x7200000</li> <li>mov rdi,rbp</li> <li>mov rsi,rbx</li> <li>mov rdx,0x20</li> <li>call 0x2651dfb <:transl::tracecallback long void><li>cmp BYTE PTR [rbp-0x8],0xa</li> <li>jne 0xae00306</li> <li>; The previous step is to check whether the parameters are valid</li> <li> <li>mov rcx,QWORD PTR [rbp-0x10]; Here %rcx is assigned a value of 1 </li> <li>mov edi,0x2 ; Assign %edi (that is, the lower 32 bits of %rdi) to 2 </li> <li>add rdi,rcx ; Add %rcx </li> <li>call 0x2131f1b <:print_int> ; Call the print_int function , at this time the value of the first parameter %rdi is already 3<li> <li>; We will not discuss it later</li></:print_int> </li></:transl::tracecallback> </li></em></li> </ol>mov BYTE PTR [rbp+0x28],0x8</div>lea rbx,[rbp+0x20]<em onclick="copycode($('code_ZLy'));">test BYTE PTR [r12], 0xffnjne 0xae0032A</em>Push QWORD PTR [RBP+0x8]

mov RBP, QWORD PTR [RBP+0x0] 🎜mov RDI, RBP🎜mov RSI, RBX🎜mov RDX, QWORD PTR [RSP] 🎜 0x236b70e &E lt; hphp: :JIT::traceRet(HPHP::ActRec*, HPHP::TypedValue*, void*)>🎜ret 🎜🎜🎜Copy code🎜🎜

And the implementation of HPHP::print_int function is like this:

<div class="blockcode"><div id="code_K6f"><ol> <code class="c++ language-c++" data-lang="c++"><div class="blockcode"> <div id="code_K6f"><ol> <li>void print_int(int64_t i) {</li> <li> char buf[256];</li> <li> snprintf(buf, 256, "%" PRId64, i);</li> <li> echo(buf);</li> <li> TRACE(1, "t-x64 output(int): %" PRId64 "n", i);</li> <li>}</li> </ol></div> <em onclick="copycode($('code_K6f'));">复制代码</em> </div>

可以看到 HHVM 编译出来的代码直接使用了 int64_tvoid print_int(int64_t i) {

char buf[256 ];

snprintf(buf, 256, "%" PRId64, i);

echo(buf);<div class="blockcode"> <div id="code_K70"><ol><li>-v Eval.JitWarmupRequests=0</li></ol></div> <em onclick="copycode($('code_K70'));">复制代码</em> </div> TRACE(1, "t-x64 output(int): %" PRId64 "n", i);

}

Copy code

You can see that the code compiled by HHVM directly uses int64_t

, avoiding the interpreter It solves the problem of parameter judgment and indirect data acquisition, which significantly improves the performance. In the end, it even achieves little difference from the code compiled by C. <div class="blockcode"> <div id="code_biL"><ol> <li> <?hh <li>class Point2 {</li> <li> public float $x, $y;</li> <li> function __construct(float $x, float $y) {</li> <li> $this->x = $x;</li> <li> $this->y = $y;</li> <li> }</li> <li>}</li> <li>//来自：https://raw.github.com/strangeloop/StrangeLoop2013/master/slides/sessions/Adams-TakingPHPSeriously.pdf</li> </ol></div> <em onclick="copycode($('code_biL'));">复制代码</em> </div>

注意到 float

Note: In server mode, HHVM will trigger JIT only if there are more than 12 requests. When starting HHVM, you can add the following parameters to make it use JIT on the first request:

<div class="blockcode"><div id="code_K70"> <ol>-v Eval.JitWarmupRequests=0</ol> <h2> <em onclick="copycode($('code_K70'));">Copy code</em> </h2> <p> </p>So when testing performance, you need to pay attention. Running it once or twice and comparing it will not see the effect. <p> </p>Type derivation is very troublesome, so we should force programmers to write it clearly<p> </p>The key to JIT is to guess the type, so if the type of a certain variable changes over time, it will be difficult to optimize. So HHVM engineers began to consider playing tricks on PHP syntax, adding type support, and launched a new language - Hack (Tucao) This name is really not good for SEO), it looks like this: <ul> <code class="php language-php" data-lang="php"><div class="blockcode"><div id="code_biL"> <ol> <li> <?hh </li>class Point2 {</li> <li> public float $ x, $y;</li> function __construct(float $x, float $y) {<li> $this->x = $x;</li> $this->y = $y; }<p>}</p>//From: https ://raw.github.com/strangeloop/StrangeLoop2013/master/slides/sessions/Adams-TakingPHPSeriously.pdf</ol> <p><em onclick="copycode($('code_biL'));">Copy code em></em></p> <h2> </h2>Did you notice the <code>float<ul> keyword? Having static types allows HHVM to better optimize performance, but it also means that it is incompatible with PHP syntax and can only use HHVM. <li> </li>In fact, I personally think that the biggest advantage of doing this is to make the code easier to understand and reduce unintentional mistakes, just like the optional types in Dart. This is also the original intention. It also facilitates IDE identification. It is said that Facebook is still developing a Web-based IDE can collaboratively edit code, so you can look forward to it. <li> </li>Can you use HHVM? <li> </li>In general, compared to the previous HPHPc, I think HHVM is worth a try. It is a real virtual machine and can better support various PHP syntax, so the cost of modification will not be higher, and because it can Seamlessly switch to the official PHP version, so you can start FPM at the same time to be on call at any time. HHVM also has a FastCGI interface for easy calling. As long as emergency preparations are made, the risk is controllable and it is very promising in the long run. <li> </li>I’m not sure how much the performance can be improved. I need to use my own business code for real testing, so that we can truly know how much benefit HHVM can bring, especially how much overall performance improvement is. Only by getting this data can we make decisions. . <li> </li>Finally, let’s sort out the problems you may encounter. Those who plan to use it can refer to: <li> </li> <li>Extension problem: If a PHP extension is used, it must be rewritten. However, the HHVM extension is much simpler to write than Zend. You can see the examples on the wiki for specific details. </li> <li>Stability issues of HHVM Server: This multi-threaded architecture may cause memory leaks after running for a period of time, or a poorly written PHP may directly cause the entire process to hang up, so you need to pay attention to testing and disaster recovery measures in this area . </li> <li>Difficulty in problem repair: HHVM will be more difficult to repair than Zend when problems occur, especially JIT code. We can only hope that it will be more stable. </li> <li> </li>P.S. In fact, I only know basic virtual machine knowledge and have never written a few lines of PHP code. Many things were temporarily searched for information when writing this article. Due to the limited time and limited level, there will inevitably be inaccuracies. Welcome everyone to comment and give advice:)</ul>

Quote

Andrei Alexandrescu on AMA

Keith Adams’ clues on HN

How Three Guys Rebuilt the Foundation of Facebook🎜 🎜PHP on the Metal with HHVM🎜 🎜Making HPHPi Faster🎜 🎜HHVM Optimization Tips🎜 🎜The HipHop Virtual Machine (hhvm) PHP Execution at the Speed ​​of JIT🎜 🎜Julien Verlaguet, Facebook: Analyzing PHP statically🎜 🎜Speeding up PHP-based development with HHVM🎜 🎜Adding an opcode to HHBC🎜 🎜🎜🎜🎜 🎜 🎜 🎜 🎜🎜 🎜🎜