PHP 8 to Add a JIT
blog.krakjoe.ninja
PHP 8 to Add a JIT
1–10 of 190 posts
Re: PHP 8 to Add a JIT
#2There 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, countless built in classes and functions).
Moreover, unlike many framework that shone brightly and burned out quickly (Rails?), PHP captured the essence of the environment: HTTP is stateless, and URLs aren't uniformly routable from either end, and well-formed HTML/XML/JSON is just a subset of tag soup.
Worse is better.
Re: PHP 8 to Add a JIT
#3There 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
#4There 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…
> URLs aren't uniformly routable from either end
What do you mean?
Re: PHP 8 to Add a JIT
#5This 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 Rust adding MIR before emitting LLVM, Rubinius trying to emit LLVM directly from Ruby and not getting good results so giving up, JRuby adding an IR before emitting Java byte code, Dropbox's Pyston implementation of Python that emitted LLVM directly where they gave up entirely, etc, etc, etc.
Low level backends are not going to do the kind of key optimisations such as scalar replacement of aggregates that are table stakes for making a dynamic language perform well - they just don't have the high-level semantic model of the language needed to do it.
Maybe they've got some new ideas, or maybe simplicity is a key constraint for them, but I predict from experience that they will need an intermediate representation to get the results that they want.
Re: PHP 8 to Add a JIT
#6There 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…
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.
Re: PHP 8 to Add a JIT
#7There 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.
make the right thing easy with security.
All other things being equal, security is usability[1] anti-pattern. You don't get to make clever hacks (in the original sense) on a secure system.
Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. - Doug Gwyn
--
[1] at the very least for a power user or a developer
Re: PHP 8 to Add a JIT
#8There 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…
> URLs aren't uniformly routable from either end What do you mean?
Having a single, uniform router (function/class/whatever) is only valid for trivial software. Any non-trivial system is better off with multiple independent URL routers with different semantics.
Re: PHP 8 to Add a JIT
#9There 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…
I think PHP endures because it does one thing and does it exceptionally well. There is no other tool that makes the creation of simple dynamic server side web sites as easy and accessible. Simple FTP/SCP deployment to the server is such a killer feature.
It is also one of the few choices available on cheap shared hosting sites.
Re: PHP 8 to Add a JIT
#10There 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…
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 anyways) and best of all has a terrific comments / examples section for each function.
Better documented is better.