Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP 8 to Add a JIT

blog.krakjoe.ninja

Post reply on HN
Print view View original

41–50 of 190 posts

Re: PHP 8 to Add a JIT

#41

Post by michaelmrose »

kijin wrote: post #17
the_trapper wrote: post #9

Earlier quoted context omitted.

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.

PHP was practically "serverless" before serverless was even a thing. You just deploy your code with ftp, rsync, git, or whatever. There's no step 2.

How is syncing your PHP code with the server serverless?

Re: PHP 8 to Add a JIT

#42

Post by tyingq »

pas wrote: post #26
beberlei wrote: post #21

Earlier quoted context omitted.

Not sure if this qualifies as intermediate representation in the LLVM sense, but PHP has opcodes already, it is not fully interpreted anymore (like it was in PHP 3). These opcodes are used for optimizations and cached for the lifetime of the PHP process (across multiple requests).

That's probably too low-level. Usually an AST is needed that is void of all syntactic sugar, yet can express the required data flows and dependencies so the trivial substitutions/replacements/caching and refactorings can be done at this level. Lower level bytecode lacks these higher level references (it usually has a lot of indices that index into raw lookup tables, but no real symbols that refer to results of comput…

There does appear to be an internal AST in php7: https://github.com/nikic/php-ast

Re: PHP 8 to Add a JIT

#43

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

Re: PHP 8 to Add a JIT

#44

Post by ryanmccullagh »

pas wrote: post #26
beberlei wrote: post #21

Earlier quoted context omitted.

Not sure if this qualifies as intermediate representation in the LLVM sense, but PHP has opcodes already, it is not fully interpreted anymore (like it was in PHP 3). These opcodes are used for optimizations and cached for the lifetime of the PHP process (across multiple requests).

That's probably too low-level. Usually an AST is needed that is void of all syntactic sugar, yet can express the required data flows and dependencies so the trivial substitutions/replacements/caching and refactorings can be done at this level. Lower level bytecode lacks these higher level references (it usually has a lot of indices that index into raw lookup tables, but no real symbols that refer to results of comput…

PHP has had an AST for years now.

Re: PHP 8 to Add a JIT

#45

Post by ronsor »

michaelmrose wrote: post #41
kijin wrote: post #17

Earlier quoted context omitted.

PHP was practically "serverless" before serverless was even a thing. You just deploy your code with ftp, rsync, git, or whatever. There's no step 2.

How is syncing your PHP code with the server serverless?

and now you see why "serverless" is misleading.

"serverless" now means you don't run your own web server, you use someone else's.

Re: PHP 8 to Add a JIT

#46

Post by cutler »

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.

Not sure about lighter. Mod-perl at least was quite RAM-hungry if I remember.

Re: PHP 8 to Add a JIT

#47

Post by pjmlp »

petepete wrote: post #6
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 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

#48

Post by tyingq »

cutler wrote: post #46
tyingq wrote: post #25

Earlier quoted context omitted.

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

Not sure about lighter. Mod-perl at least was quite RAM-hungry if I remember.

Lighter than original CGI-BIN, fork() and exec() for every request.

Re: PHP 8 to Add a JIT

#49

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

Re: PHP 8 to Add a JIT

#50

Post by skrebbel »

wvenable wrote: post #40
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.

Well, you can do

    $moo = "hello";
    $zork = "moo";
    echo $$zork; // hello
It doesn't get much more dynamic than that.
Post reply on HN