PHP 8 to Add a JIT • Hacker News Board

Re: PHP 8 to Add a JIT

#31

Post by glennpratt » Sun, Mar 31, 2019, 4:57 PM UTC

igi3ql wrote: post #28

yllus wrote: post #10

Earlier 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…

I haven't found PHP documentation to be better or worse than the documentation of other languages I've used. What I dislike about it is the comments that every page includes. Most of them are very poorly written snippets of code from 15 years ago. If you dislike those comments too, consider adding this to your ad blocker: php.net###usernotes

Seriously? On the spectrum of things worth ad blocking, this would never even hit my radar.

Re: PHP 8 to Add a JIT

#32

Post by igi3ql » Sun, Mar 31, 2019, 5:00 PM UTC

glennpratt wrote: post #31

igi3ql wrote: post #28

Earlier quoted context omitted.

I haven't found PHP documentation to be better or worse than the documentation of other languages I've used. What I dislike about it is the comments that every page includes. Most of them are very poorly written snippets of code from 15 years ago. If you dislike those comments too, consider adding this to your ad blocker: php.net###usernotes

Seriously? On the spectrum of things worth ad blocking, this would never even hit my radar.

I use uBlock Origin and its :style() feature to remove and modify parts of websites that I don't like.

I don't block user comments on PHP doc pages out of spite, I do it because they are very long, making it harder to scroll vertically on the actual documentation.

Re: PHP 8 to Add a JIT

#33

Post by bogdanu » Sun, Mar 31, 2019, 5:03 PM UTC

bratao wrote: post #14

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/

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.

Re: PHP 8 to Add a JIT

#34

Post by kyriakos » Sun, Mar 31, 2019, 5:04 PM UTC

igi3ql wrote: post #28

yllus wrote: post #10

Earlier 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…

I haven't found PHP documentation to be better or worse than the documentation of other languages I've used. What I dislike about it is the comments that every page includes. Most of them are very poorly written snippets of code from 15 years ago. If you dislike those comments too, consider adding this to your ad blocker: php.net###usernotes

fortunately the date the comment was posted is very prominent on the page

Re: PHP 8 to Add a JIT

#35

Post by bogdanu » Sun, Mar 31, 2019, 5:05 PM UTC

kyriakos wrote: post #29

bratao wrote: post #14

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/

Know any production grade projects using swoole? I was looking at it in the past but looks very early to trust a business on it.

Afaik the project is pretty old. Never heard of anyone using it in production. There are a few integrations with popular frameworks but nothing production ready because there werent made to live in a eventloop - so, a lot of memory leaks.

Re: PHP 8 to Add a JIT

#36

Post by kyriakos » Sun, Mar 31, 2019, 5:06 PM UTC

bogdanu wrote: post #33

bratao wrote: post #14

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/

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.

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.

Re: PHP 8 to Add a JIT

#37

Post by coldtea » Sun, Mar 31, 2019, 5:11 PM UTC

dexen wrote: post #8

kaoD wrote: post #4

Earlier quoted context omitted.

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

And yet lots of non-trivial systems have a single uniform router and are just fine with that. So there's that.

Re: PHP 8 to Add a JIT

#38

Post by badsectoracula » Sun, Mar 31, 2019, 5:25 PM UTC

the_trapper wrote: post #9

dexen wrote: post #2

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, 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.

The other thing it does excellently is that you can take any .html file, renamed it to .php and add some and it'll work.

In a previous site of mine i had the entire site be statically generated but needed some server-side stuff in one of the pages, so i put something like %%PHPCODEHERE%% and modified the script that built the site to replace the %%PHPCODEHERE%% with the contents of a .php script.

Re: PHP 8 to Add a JIT

#39

Post by [deleted] » Sun, Mar 31, 2019, 5:27 PM UTC

tyingq wrote: post #25

yllus wrote: post #10

Earlier 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.

[deleted]

Re: PHP 8 to Add a JIT

#40

Post by wvenable » Sun, Mar 31, 2019, 5:28 PM UTC

chrisseaton wrote: post #5

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…

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