rfc:jit

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Last revision Both sides next revision
rfc:jit [2019/02/13 09:07]
dmitry
rfc:jit [2019/04/12 07:15]
laruence
Line 1: Line 1:
 ====== PHP RFC: JIT ====== ====== PHP RFC: JIT ======
-  * Version: ​0.9+  * Version: ​1.0
   * Date: 2019-01-28   * Date: 2019-01-28
   * Author: Dmitry Stogov <​dmitry@php.net>,​ Zeev Suraski <​zeev@php.net>​   * Author: Dmitry Stogov <​dmitry@php.net>,​ Zeev Suraski <​zeev@php.net>​
-  * Status: ​Under Discussion+  * Status: ​Accepted (to be merged into PHP-8 only)
   * First Published at: https://​wiki.php.net/​rfc/​jit   * First Published at: https://​wiki.php.net/​rfc/​jit
  
 ===== Introduction ===== ===== Introduction =====
-It's no secret that the performance jump of PHP 7 was originally initiated by attempts to implement JIT for PHP. We started these efforts at Zend (mostly by Dmitry) back in 2011 and since that time tried 3 different implementations. ​ We never moved forward to propose to release any of them, for three main reasons: ​ They resulted in no substantial performance gains for typical Web apps;  They were complex to develop and maintain; ​ We still had additional directions we could explore to improve performance without having to use JIT.+It's no secret that the performance jump of PHP 7 was originally initiated by attempts to implement JIT for PHP. We started these efforts at Zend (mostly by Dmitry ​and Xinchen) back in 2011 and since that time tried 3 different implementations. ​ We never moved forward to propose to release any of them, for three main reasons: ​ They resulted in no substantial performance gains for typical Web apps;  They were complex to develop and maintain; ​ We still had additional directions we could explore to improve performance without having to use JIT.
  
 ===== The Case for JIT Today ==== ===== The Case for JIT Today ====
Line 27: Line 27:
 When enabled, native code of PHP files is stored in an additional region of the OPcache shared memory and op_array->​opcodes[].handler(s) keep pointers to the entry points of JIT-ed code. This approach doesn'​t require engine modification at all. When enabled, native code of PHP files is stored in an additional region of the OPcache shared memory and op_array->​opcodes[].handler(s) keep pointers to the entry points of JIT-ed code. This approach doesn'​t require engine modification at all.
  
-We use DynAsm (developed for LuaJIT project) for generation of native code. It's a very lightweight and advanced tool, but does assume good, and very low-level development knowledge of target assembler languages. ​ In the past we tried LLVM, but its code generation speed was almost 100 times slower, making it prohibitively expensive to use. Currently we support ​only x86 and x86_64 on POSIX platforms. Windows support should be relatively straightforward,​ but was (and still is) a low priority for us. DynAsm also supports ARM. ARM64, MIPS, MIPS64 and PPC, so in theory we should be able to support all of the platforms that are popular for PHP deployments (given enough efforts).+We use DynAsm (developed for LuaJIT project) for generation of native code. It's a very lightweight and advanced tool, but does assume good, and very low-level development knowledge of target assembler languages. ​ In the past we tried LLVM, but its code generation speed was almost 100 times slower, making it prohibitively expensive to use. Currently we support x86 and x86_64 ​CPUs on POSIX platforms and Windows. DynAsm also supports ARM. ARM64, MIPS, MIPS64 and PPC, so in theory we should be able to support all of the platforms that are popular for PHP deployments (given enough efforts).
  
 PHP JIT doesn'​t introduce any additional IR (Intermediate Representation) form. It generates native code directly from PHP byte-code and information collected by SSA static analyses framework (a part of opcache optimizer). Code is usually generated separately for each PHP byte-code instruction. Only few combinations are considered together (e.g. compare + conditional jump). PHP JIT doesn'​t introduce any additional IR (Intermediate Representation) form. It generates native code directly from PHP byte-code and information collected by SSA static analyses framework (a part of opcache optimizer). Code is usually generated separately for each PHP byte-code instruction. Only few combinations are considered together (e.g. compare + conditional jump).
Line 402: Line 402:
  
 ===== State and compatibility ===== ===== State and compatibility =====
-Currently we support ​only x86 and x86_64 ​non-ZTS builds ​on POSIX platforms (tested on Linux). +Currently we support x86 and x86_64 on POSIX platforms (tested on Linux with GCC and LVVM) and Windows (both non-ZTS and ZTS builds)We support ​"​Hybrid"​ and "​Call" ​VM with and without GCC explicit global ​register variables ​extension
-We support only "​Hybrid VM" that requires C compiler ​with GCC extensions (labels as values ​and explicit global register variables). Unfortunately,​ LLVM doesn'​t support the second feature ​and MSVC - both+There are no any restrictions ​on C compiler and OS any more.
- +
-ZTS support is not a big problem, but it should be implemented after ZTS improvement described at [[https://​wiki.php.net/​zts-improvement|https://​wiki.php.net/​zts-improvement]] +
- +
-LLVM and MSVC are not supported yet. Without JIT, bench.php is about 2 times faster on PHP built with GCC, then with LLVM or MSVC. LLVM and MSVC reqiure ​support ​for "​Call ​VM" ​(it's implemented,​ but wasn't tested for a while) ​and additional code for opcode handlers argument passing and FP/IP register reloading (to emulate ​register variables ​and reuse existing code-generator). Windows support might also require adoption to different calling convention+
- +
-Alternative way to support all platforms and C compilers is generating low-level VM (using the same JIT framework). This VM won't depend ​on C compiler ​extensions, ​and going to be comptible with JIT out of the boxAs a side effect, interpretation should also became faster. This approach is used in JVM template VM, low level WebKit interpreter,​ V8 ignition interpreter,​ LuaJIT interpreter. Low-level VM may be implemented in PHP-8, in addition to existing interpreter written in C. +
- +
-===== Open Issues ===== +
-Make sure there are no open issues when the vote starts!+
  
 ===== Future Scope ===== ===== Future Scope =====
Line 420: Line 411:
 Support for JIT is more a strategic PHP question. JIT definitely requires a lot of work, but it may be actively developed only as a part of PHP, with common effort. Support for JIT is more a strategic PHP question. JIT definitely requires a lot of work, but it may be actively developed only as a part of PHP, with common effort.
  
-This project requires a 2/3+1 majority.+This project requires a 2/3+1 majority. Voting opened 2019-03-21 and closes 2019-03-28
  
 <doodle title="​Include JIT into PHP 8?" auth="​user"​ voteType="​single"​ closed="​true">​ <doodle title="​Include JIT into PHP 8?" auth="​user"​ voteType="​single"​ closed="​true">​
Line 428: Line 419:
  
 As PHP 7.4 is already branched and its engine is not expected to be significantly changed (consequently requiring corresponding changes to the JIT implementation),​ we can also consider including JIT in PHP-7.4 as an experimental feature (disabled by default), to provide early access and receive more feedback. This also requires a 2/3+1 majority. As PHP 7.4 is already branched and its engine is not expected to be significantly changed (consequently requiring corresponding changes to the JIT implementation),​ we can also consider including JIT in PHP-7.4 as an experimental feature (disabled by default), to provide early access and receive more feedback. This also requires a 2/3+1 majority.
 +
 +In case JIT is not included in PHP-7.4 and PHP-8 introduces language compatibility breaks (it already does), existing applications couldn'​t be tested with JIT without porting to PHP-8.
  
 <doodle title="​Include JIT into PHP 7.4 (experimental)?"​ auth="​user"​ voteType="​single"​ closed="​true">​ <doodle title="​Include JIT into PHP 7.4 (experimental)?"​ auth="​user"​ voteType="​single"​ closed="​true">​
Line 440: Line 433:
  
 ===== Implementation ===== ===== Implementation =====
-After the project is implemented,​ this section should contain  +Merged ​into PHP master by [[https://​github.com/​php/​php-src/​commit/​9a06876072b9ccb023d4a14426ccb587f10882f3|9a06876072b9ccb023d4a14426ccb587f10882f3]] ​commit
-  - the version(s) it was merged ​into +
-  ​a link to the git commit(s) +
-  - a link to the PHP manual entry for the feature +
-  - a link to the language specification section (if any)+
  
 ===== References ===== ===== References =====
   - [[https://​luajit.org/​dynasm.html|DynAsm page]]   - [[https://​luajit.org/​dynasm.html|DynAsm page]]
 +  - [[https://​github.com/​LuaJIT/​LuaJIT/​tree/​master/​dynasm|DynASM Source codes]]
   - [[https://​corsix.github.io/​dynasm-doc/​|The Unofficial DynASM Documentation]]   - [[https://​corsix.github.io/​dynasm-doc/​|The Unofficial DynASM Documentation]]
- 
-===== Rejected Features ===== 
-Keep this updated with features that were discussed on the mail lists. 
- 
rfc/jit.txt · Last modified: 2019/04/12 07:38 by laruence