
PHP 8 to Add a JIT - UkiahSmith
https://blog.krakjoe.ninja/2019/03/php-gr8.html
======
chrisseaton
This is the RFC with more technical details
[https://wiki.php.net/rfc/jit](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.

~~~
wvenable
> making a dynamic language perform well

Perhaps the advantage here is that PHP really all that dynamic. PHP is much
closer in design to taking Java and compiling it on every request than it is
like Python or Ruby.

~~~
skrebbel
Well, you can do

    
    
        $moo = "hello";
        $zork = "moo";
        echo $$zork; // hello
    

It doesn't get much more dynamic than that.

~~~
wvenable
It can. Python, for example, builds up classes at runtime. PHP builds up
classes at compile time. There are plenty of other examples. PHP is really
dynamic through eval() but that's more rare.

Although PHP does support the above syntax, it's actually pretty rare in
production code. PHP can be optimized like JavaScript is: perform direct
variable/member access but provide a slow path for these kinds of dynamic
lookups.

~~~
viraptor
You can't just wave away the impact of having eval though. Just the fact that
it exists means you need to keep around some supporting state like variable
names. You can't do full constant folding and eliminate all intermediate steps
for example if there a chance a runtime-created code will reach into your
frame and want them back.

~~~
wvenable
eval() is scoped to the current block. If you even just ignored JITing any
function with eval() in it then you'd still get quite far.

------
dexen
There 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._

~~~
yllus
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._

~~~
pushpop
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.

~~~
chiefalchemist
Perhaps not better, but there certainly have been worse.

As for the comments. Yes. But at least they're there, and quite often helpful.
Plenty of times I've read other docs where I wished they had commenting but
alas didn't.

~~~
ptx
The comments are only needed because the documentation is often wrong or
confused. And, of course, usually most of the comments are wrong too.

Other languages don't need comments because they at least aim to have
documentation that's correct.

~~~
chx
If you find the documentation wrong or confused please let us know.
[https://bugs.php.net/](https://bugs.php.net/) We do our best. I was granted
access some ten years ago and whenever I find a confusing page I fix it. I
know there has been terrible pieces before but for the last oh five or six
years I don't really find anything too bad. Please let us know what you found
wrong. Thanks!

~~~
ptx
I was mostly responding to the idea in an ancestor comment that PHP has
unusually good documentation (better than that of other languages), "best of
all" having comments.

I'm sure the PHP documentation is getting better all the time! Other languages
also have good documentation, though. And as pushpop said in an earlier
comment, the reason that the comments were useful historically is that the
documentation was not always correct or complete. (Perhaps in part because the
the language used to have a lot more unintended quirks?)

------
bitt
PHP 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.

~~~
bogdanu
And dont forget about preloading - an OPCache improvement, also available from
7.4.

------
maxxxxx
I am pretty impressed with the path PHP has been taking lately. They have
moved the language from being a mess into aggressively incorporating modern
features at a very rapid pace. Especially PHP7 is a really nice language.

~~~
justinator
I think the problem with PHP is that it's a mature language that is
aggressively incorporating modern features, yet _still is a mess_.

~~~
welly
What are the messy bits? I know they are there but how is it a mess in your
opinion?

There seems to be a lot of "PHP is a mess/garabage/whatever else" hyperbole in
this thread with no actual explanations why.

~~~
pathartl
I for one would rather see common utilities move into proper naming and static
classing with proper returns. For instance, strpos(string haystack, string
needle) will return the position of needle in haystack as an int if found. If
not, it returns false. To me, the proper thing in this scenario is to either
return an int (even -1 is fine for not found) or throw an exception.

There's inconsistencies in typing of what is returned. There's nothing wrong
with loose typing, especially in the place that PHP is used. It's just that
the PHP API regularly returns not what you'd expect.

Throw into the mix that the built in simple-functions are all over the place
([https://www.php.net/manual/en/ref.strings.php](https://www.php.net/manual/en/ref.strings.php)).
Seriously, there's str_replace, strpos, and parse_str. These could easily be
solved by doing something similar to C#'s naming by changing it to something
like String.Replace, String.IndexOf, String.Parse.

------
sickcodebruh
My feelings about PHP are stuck in what I remember from 2004. If I’m starting
a new backend web project in 2019, should I be considering PHP over Ruby,
Python, or TypeScript? Why or why not? I’m curious to hear from anyone who’s
used it professionally in the last couple years.

~~~
godot
For majority of backend web project, in 2019, there should be nearly no
technical advantage re: one language over another among all the popular ones.
(i.e. the ones you listed: PHP, Ruby, Python. I would argue to use pure nodejs
over Typescript though. Most people underestimate the dev flow speed it gives
you to not to have a compile/transpile step. Refresh and rerun is part of what
made PHP so popular years ago.)

In short, use whatever you're comfortable with. If you're super proficient
with PHP, keep using it. If Python is that language for you, use Python.

~~~
reallydude
> there should be nearly no technical advantage

In practice there is. Specifically in regard to parallelism and performance,
which is important for any non-trivial application.

You can spin up multiple Python processes or just re-implement in a different
language, some nuanced part of the stack that you've crafted to bottleneck(s),
or you can just choose not to use it from the start. It's not like you're
going to design around the deficiency at all levels.

You'll run into Ruby performance problems very early on without specific
knowledge, so people just stopped using it for anything load bearing. My bias
against Ruby is limited to PoC programs having memory problems and poor
performance compared to virtually identical implementations in other
languages, being a cultprit. YMMV.

Perl is hard for people to understand, since every feature of the language is
a landmine of obfuscation...php is getting there on it's own, to be fair.

The idea that there should be no technical advantage is ignorant. There are
choices that have been made and there's reasons for each. You don't run Python
on stream processing with Flink because it's not suited for parallelism.
Catching errors like a kafka broker disappearing, in PHP, is almost trivial
like in many languages, while Java requires a custom retry method that
requires intimate knowledge of how any connector works.

Knowing the languages, PHP has some very compelling strengths, as does Java
(performance and safety) and Python (generally consistency of implementation
and speed of development)...I still don't understand why I keep running into
rats' nests of javascript and other esoterics.

------
bratao
One very important motivation what I do not see clearly delineated in this
post is for Event-driven applications. Swoole[1] is an example of a PHP
framework which enable some very interesting uses such as Websocket services.

In those long lived processes, a JIT really shines!

[1] [https://www.swoole.co.uk/](https://www.swoole.co.uk/)

~~~
bogdanu
Do you happen to have any benchmarks with JIT and libries like swoole?

I thought the same some days ago, but in theory, the output from JIT lives
across requests so it shouldn't matter if its a long lived process or simply a
normal PHPfpm process.

Also, the usual bottleneck in PHP is I/O.

~~~
kyriakos
in long running processes like Swoole, there is no web server running in front
of PHP meaning PHP does some more heavy lifting which could benefit from JIT.

~~~
beberlei
That is not entirely correct. Swoole already takes away a lot of the CPU heavy
code, like HTTP protocol parsing by providing it in its C extension.

For one of my PHP extensions I benchmarked the C level implementation to be 5x
faster than Jitted PHP code:
[https://beberlei.de/2019/03/25/the_jit_in_relation_to_php_ex...](https://beberlei.de/2019/03/25/the_jit_in_relation_to_php_extensions.html)

So no, if your Swoole application does a lot of async I/O and its only in CPU
code to delegate between I/O, then it will not benefit from the JIT.

"Long-Running process" alone doesn't mean that its CPU bound.

------
tyingq
Article appears to be from the same person that maintains apcu, a very popular
user space kv memory cache for PHP.
[https://github.com/krakjoe/apcu](https://github.com/krakjoe/apcu)

~~~
inglor
Joe Watkins is a really nice person and contributed a lot to php including the
thread support (php-pthreads) the debugger (php-dbg) and other really
impressive stuff.

The nice story here is when he was in financial trouble (because of a bad
employer) the community stepped up and donated to him (
[https://www.gofundme.com/b9dfcg](https://www.gofundme.com/b9dfcg) ).

He has constantly been useful and a positive force of change and any language
ecosystem would be happy to have him.

------
antirez
I'm happy PHP is still there, because other much better languages missed a lot
of good things that PHP got right immediately (in the context of web
development):

1\. You may add complexity if you want but the _bare metal_ of web is that you
have some printf() like output construct plus a trivial <? ?> interpolation
thing. Then who wants more can add more, but this should be what you get
immediately for free, without template languages.

2\. Languages, even high level ones, should be reasonably fast.

3\. Setting up an environment should be trivial.

4\. By default things are created and die in the context of a page load. Then
if you want to optimize things, you may have _additional constructs_ to create
persistent connections, objects, whatever. But give me this huge garbage
collector that is a stateless execution, by default.

5\. A set of libraries already included so that for most things I don't have
to go and find some solution.

Many other competitors failed so big in that regards that I really wanted PHP
to get better as a language (like it is doing) so that it was not a so bad
experience like at the start, because I was pretty sure the others would
hardly fix the above points.

~~~
aasasd
Now, the actual tragedy of PHP isn't that coding in it feels soul-drainingly
tainted, but that it was always ‘good enough’ for armies of people. Because,
as a result, there wasn't any incentive to add features outside of the
paradigm of one-shot scripts.

E.g. there are at least three async frameworks, with barely any adoption―and
this new ‘Swole’ one is advertised like ReactPHP never existed, with its
promises and everything.

Meanwhile, somehow, the poster notion of PHP's versatility is that it's
purportedly just fine for desktop GUI programming, of all things―while being
single-threaded (its ‘pthreads’ aren't threads). The topic of UI freezes never
comes up in these pamphlets, for some reason.

------
joseph8th
PHP has made huge strides with 7.0+ but honestly a JIT was nowhere on my list
of feature requests. We use it at work (with CodeIgniter) and it gives the
company a big pool of reasonably qualified talent. For anything outside our
web apps, we switch to Python. I find it unlikely that new PHP shops are going
to use it to do all the CPU-bound things we aren't using it for now.

But who knows? I wouldn't have thought it would be as popular as it is now, if
you'd asked me 5 years ago.

------
kuroguro
Love what they've been doing on PHP lately :)

> However, this in fact opens the door on things such as machine learning, 3d
> rendering, 2d (gui) rendering, and data analysis, to name just a few.

Shouldn't we get decent threading built in before we consider most of those?
I've hit that wall many times when processing larger amounts of data w/ php
scripts. I know about the pthreads plugin but nothing beats a first class
citizen like goroutines for go or similar.

~~~
beberlei
Joe (the author of this post and pthreads extension) has been working on a new
threading extension in the last months that looks extremely promising and more
along the lines of goroutines than Java style threading:

\- [https://github.com/krakjoe/parallel](https://github.com/krakjoe/parallel)
\- [https://blog.krakjoe.ninja/2019/02/parallel-php-next-
chapter...](https://blog.krakjoe.ninja/2019/02/parallel-php-next-chapter.html)

~~~
EB66
Wow, that looks incredible. Thank you for linking it.

------
cutler
Apart from ubiquitous cheap hosting another big factor in PHP's early success
was the numerous magazines pumping out "Build X with PHP and MySQL" articles.
The shelves of newsagents were full of them in the early 2000s, some devoted
purely to PHP development. Dreamweaver also adopted PHP for its dynamic site
generator which made it accessible to front-end developers.

------
AstroJetson
Need some love here for AOLServer and TCL. Got "Philip & Alex's Guide to Web
Publishing" and within two weeks had a major Mutual Fund company up on the
web. The CICS interface was a little wonky, but it worked and worked well.

I do things now with Wordpress, since that grew and was maintained past AOL
server. I always look forward to improvements in PHP, the last few releases
have made huge strides in page load times

------
stesch
I care enough to click the link. But I don't care enough to know anything
about PHP 8. Why is the author insulting me with the intro?

~~~
halfnibble
I felt the intro was a little off too. I hadn't even heard of PHP 8 until
today.

------
nzd
So if JIT involves compiling into native machine code, can we expect that in
the future JIT capability would help PHP devs implement compiling whole PHP
project into native (like a single .exe binary for Windows)?

------
the_fonz
Doesn't this duplicate the effort of HHVM?

~~~
duskwuff
Nope! As of last year, HHVM no longer targets PHP [1]; instead, it targets a
Facebook-specific variant of PHP called "Hack". It will still run some PHP
code, but that's on its way out.

Even better/worse, PHP 7.2 with an opcode cache can actually outperform HHVM
on many practical benchmarks [2], and 7.3 is faster still.

[1]: [https://hhvm.com/blog/2018/09/12/end-of-php-support-
future-o...](https://hhvm.com/blog/2018/09/12/end-of-php-support-future-of-
hack.html)

[2]:
[http://web.archive.org/web/20180305000053/https://kinsta.com...](http://web.archive.org/web/20180305000053/https://kinsta.com/blog/php-7-hhvm-
benchmarks/)

------
dboreham
For a second I read that as "PDP 8..."

------
gambit186
The article says that this will help PHP in areas outside of the web. But what
others areas actually _want_ PHP? Even in its niche, the web, it has fallen
out of grace for new projects.

~~~
kibibu
Don't believe it. Maybe in SV it's out of grace, but it gets plenty of use.

------
doener
I already submitted that:
[https://news.ycombinator.com/item?id=19531611](https://news.ycombinator.com/item?id=19531611)

