This is the RFC with more technical details https://wiki.php.net/rfc/jit . I believe their plan is to emit low-level code directly via DynAsm, without their own intermediate representation. This kind of approach has been tried again and again and again and every project doing this either not got the results they wanted and given up or has had to go back and add a proper intermediate representation. Examples include R…
PHP 8 to Add a JIT
61–70 of 190 posts
Re: PHP 8 to Add a JIT
#62This is the RFC with more technical details https://wiki.php.net/rfc/jit . I believe their plan is to emit low-level code directly via DynAsm, without their own intermediate representation. This kind of approach has been tried again and again and again and every project doing this either not got the results they wanted and given up or has had to go back and add a proper intermediate representation. Examples include R…
> use DynAsm (developed for LuaJIT project) for generation of native code
But at the very least, this exercise will ensure that DynAsm will be actively used by a few people. So even if this PHP JIT effort fails, the underlying JIT technology will be more widely understood and hopefully better documented for other projects.
Re: PHP 8 to Add a JIT
#63Earlier quoted context omitted.
I agree with just about all of your post except using Rails as an example of something that burnt out quickly. It was the most popular web framework around for the best part of a decade and is still being chosen for new projects.
Rails was popular among those that never saw such approaches before, like on AOLServer and Zope. I just kept using Java, .NET and C++, while enjoying their performance, IDE tooling, and whatever ideas they could bring into their web stacks. Nowadays most cool companies that were pushing Ruby, are on JVM languages.
Re: PHP 8 to Add a JIT
#64Earlier quoted context omitted.
I think PHP had a couple of obvious advantages - it almost had a "first mover" advantage in that it happened to be installed alongside CGI-BIN on shared webhosts way back in the way - plus Drupal and WordPress being PHP projects. But to me, one of the most significant advantages PHP has is that its documentation is terrific . PHP.net is simple, clear about parameters and return values (as clear as PHP lets it be anyw…
"it almost had a "first mover" advantage in that it happened to be installed alongside CGI-BIN on shared webhosts way back in the way" That's a good observation. Because the mod_php and mod_perl Apache modules were much faster and lighter weight than CGI-BIN, and pre-installed on shared hosting, both PHP and Perl dominated the early web days.
Re: PHP 8 to Add a JIT
#65Re: PHP 8 to Add a JIT
#66Earlier quoted context omitted.
I think PHP had a couple of obvious advantages - it almost had a "first mover" advantage in that it happened to be installed alongside CGI-BIN on shared webhosts way back in the way - plus Drupal and WordPress being PHP projects. But to me, one of the most significant advantages PHP has is that its documentation is terrific . PHP.net is simple, clear about parameters and return values (as clear as PHP lets it be anyw…
Things may have changed since v7 but historically I’ve not found PHPs documentation any better than any other language. In fact I remember a few occasions where I’ve ended up going by the advice of the comments rather than the documentation itself because the documentation was either out dated or just plain wrong.
Re: PHP 8 to Add a JIT
#67There is something to be said about PHP's staying power. The early versions of the language weren't considered "right". Except maybe they were right for the problem at hand. The way I see it was PHP captured the vector of change , and left ample room for future developments. Both internal changes (hello, bytecode; hello, JIT), language level features (hi there, namespaces), and runtime level features (oh hai, countle…
PHP also didn't make the mistake Perl did. A shame because Perl tried very hard to make the right thing easy with security.
Re: PHP 8 to Add a JIT
#68Re: PHP 8 to Add a JIT
#69Earlier quoted context omitted.
That looks it merely needs some reflection support (variable name lookup).
Isn't reflection slow as hell? If not please correct me.
echo $FOO[$BAR];
echo $$BAZ;
>>>
push FOO.ptr
push BAR.ptr
call hash_get
push ax
call print
push local_table // static per compiled scope
push BAZ.ptr
call hash_get
push [ax+24] // entry->value
call print
You'd probably want to add error handling (to both cases) and accessing a global variable that didn't exist when the code was compiled will likely be slow, but if becomes a preformance bottleneck you can always rewrite it to something easier to compile.Re: PHP 8 to Add a JIT
#70PHP is doing great! I like the direction it is going in. PHP 7.4 also introduced nice features to improve static typing. The FFI is pretty cool too. You also get free performance improvements while remaining mostly backward compatible. It is trying very hard to stay relevant and I believe it is succeeding.