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

51–60 of 190 posts

Re: PHP 8 to Add a JIT

#51

Post by jashmatthews »

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…

LuaJIT and WebKit both produce their IR from the bytecode, IIUC.

Re: PHP 8 to Add a JIT

#52

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

Re: PHP 8 to Add a JIT

#53

Post by cutler »

wbl wrote: post #3
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…

PHP also didn't make the mistake Perl did. A shame because Perl tried very hard to make the right thing easy with security.

Perl's decline relative to PHP is a bit more nuanced. With mod_perl you had to be really careful with global variables otherwise another process could access them in memory. Mod_php did a better job of isolating processes so mod_perl gained a reputation as a security headache which most cheap hosting companies were not prepared to deal with. It's often overlooked that a lot of cheap hosts only offer PHP as a CGI so the benefits over Perl/CGI appear, at first glance, to be minimal but even as a CGI PHP has templating built-in where Perl, Python and Ruby don't. Perl only has CGI.pm when limited to CGI. Sure, you can try to run Perl web frameworks such a Mojolicious, Dancer and Catalyst under CGI but they're not going to compete with PHP since they don't run as drop-in templated pages. Perl did have a PHP clone - HTML::Mason - but it wasn't worth using unless you ran it with mod_perl. That's where Perl lost to PHP.

When PHP gained full OOP support with PHP5 the Perl community was still tearing itself apart over introducing a MOP and which of the dozen Moose clones should reign supreme. That was the final nail in Perl's coffin, at least in it's bid to compete with PHP.

Re: PHP 8 to Add a JIT

#54

Post by kyberias »

skrebbel wrote: post #50
wvenable wrote: post #40

Earlier quoted context omitted.

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

That looks it merely needs some reflection support (variable name lookup).

Re: PHP 8 to Add a JIT

#55

Post by chessturk »

yllus wrote: post #10
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 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…

> Better documented is better.

I was talking to some kid who wanted to be a developer, and I echoed this sentiment. A complex tool with good documentation is easier to use than a simple tool with bad documentation.

Re: PHP 8 to Add a JIT

#56

Post by chessturk »

kyberias wrote: post #54
skrebbel wrote: post #50

Earlier quoted context omitted.

Well, you can do $moo = "hello"; $zork = "moo"; echo $$zork; // hello It doesn't get much more dynamic than that.

That looks it merely needs some reflection support (variable name lookup).

Isn't reflection slow as hell?

If not please correct me.

Re: PHP 8 to Add a JIT

#57

Post by dmortin »

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…

> There is something to be said about PHP's staying power.

The only reason I use php for my own sites is because I don't want to administer any server and I don't want to be tied to a provider.

PHP is a good fit for this, because it's available at practically all cheap hosting providers (I don't need to administer the server with shared hosting) and I'm not tied to a single provider, because I can switch to an other hosting provider without too much effort.

With other langauges I either have to manage my own VPS (I don't want to pay for managed VPS), or I'm tied to a provider (Appengine, etc.).

Re: PHP 8 to Add a JIT

#58

Post by Tarean »

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.

It's also very much frowned upon so a slow path is fine.

The _get and _set magic methods (called when getting/setting missing properties) are quite common especially for frameworks.

Re: PHP 8 to Add a JIT

#59

Post by chrisseaton »

kyberias wrote: post #54
skrebbel wrote: post #50

Earlier quoted context omitted.

Well, you can do $moo = "hello"; $zork = "moo"; echo $$zork; // hello It doesn't get much more dynamic than that.

That looks it merely needs some reflection support (variable name lookup).

The whole point of a JIT is that you don't do naive variable name lookup.

With a proper intermediate representation you'd connect that $$ variable lookup directly to the original variable's edge.

Post reply on HN