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

141–150 of 190 posts

Re: PHP 8 to Add a JIT

#141

Post by chrisseaton »

yazr wrote: post #140
chrisseaton wrote: post #137

Earlier quoted context omitted.

Right, and in a language where you are predominantly using strings, arrays, maps, unless you can remove and optimise through these data structures you spend your whole time allocating them, collecting them, doing lookup in them and you won't have any opportunity to apply other optimisations. You need to be able to understand these data structures at the level of an IR - DynASM or LLVM aren't going to remove a call to…

I understand that a JIT engine cant do this, due to speed. But would be surprised that a LLVM compiler with a custom-designed heuristic for specific optimizations cant manage this. These problems may be polynomial etc etc, but MOST of the code generated should follow common patterns I will have to give this some thought. Thanks for the reply (also GP)

> I understand that a JIT engine cant do this, due to speed.

Most serious JIT engines do! For example V8, LuaJIT, Graal, C2.

> But would be surprised that a LLVM compiler with a custom-designed heuristic for specific optimizations cant manage this.

Rubinius for example tried writing custom optimisations like you're describing and didn't get very far. LLVM is not designed for these kind of optimisations - it understands memory reads and writes, not high-level semantic information about arrays and objects.

In practice, it just doesn't seem to work.

As I say I think it's a bare minimum for making a dynamic language genuinely fast. I gave a lecture about this https://www.youtube.com/watch?v=b1NTaVQPt1E.

Re: PHP 8 to Add a JIT

#142

Post by lugg »

h1d wrote: post #134
lugg wrote: post #126

Earlier quoted context omitted.

I still use PHP a lot. PHP's problems are largely user driven. What drove you away in 2004 is likely still there. The community is still full of people who have no idea. Laravel is still king. Noun driven OO is still perceived as a good idea. But on the flip side, the language has some nice features now and performance got a big boost too. Still a couple of things missing but it's getting there.

Not too serious but I want to stop using a language still forcing me to type semi colons. CSS -> Stylus. I don't even have to type brackets and colons and not just semi colons. JS -> JS (TS). Some people may not be aware but you can fully write JS by omitting semi colons. (Except on a few occasions* but I can write a project without one just fine and decent editor will warn you when you're supposed to have one, like…

I'm a big fan of standardjs. Beats prettier and the rest. Takes more of a go fmt approach.

While debating myself on whether to learn rust or go next I fell into clojure. I'll probably pick go up next and then rust.

Re: PHP 8 to Add a JIT

#143

Post by chungleong »

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 once wrote a post comparing PHP to the Zerg in StarCraft. It's ugly as hell yet manages to spread everywhere. Purity of Essence trumps Purity of Form. PHP let you defeat competitors wielding superior technology through rapid time to market. A zergling rush, if you will.

Re: PHP 8 to Add a JIT

#145

Post by duskwuff »

the_fonz wrote: post #121

Doesn't this duplicate the effort of HHVM?

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

[2]: http://web.archive.org/web/20180305000053/https://kinsta.com...

Re: PHP 8 to Add a JIT

#146

Post by tylerjwilk00 »

sickcodebruh wrote: post #100

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.

PHP is faster than both Ruby [1] and Python [2] and unlike TypeScript the executed code is the same as the written code, no transpiling.

[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

[2] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: PHP 8 to Add a JIT

#147

Post by segmondy »

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…

Nah, PHP survived because it wasn't strict, it tolerated a lot of crap. It would process almost anything it can and not fail. Most other languages would error out seriously. Also it's model of running each request as a fresh process eliminated persistent bugs. PHP's documentation is garbage. I say this as someone that has made money handsomely from PHP. :-).

Re: PHP 8 to Add a JIT

#148

Post by EGreg »

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

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…

I wish PHP had classes spread across several files like ASP.NET.

Re: PHP 8 to Add a JIT

#149

Post by stephenr »

segmondy wrote: post #147
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…

Nah, PHP survived because it wasn't strict, it tolerated a lot of crap. It would process almost anything it can and not fail. Most other languages would error out seriously. Also it's model of running each request as a fresh process eliminated persistent bugs. PHP's documentation is garbage. I say this as someone that has made money handsomely from PHP. :-).

> PHP's documentation is garbage

Birds are Cats.

See, we can all make unsubstantiated claims.

Re: PHP 8 to Add a JIT

#150

Post by edoceo »

EGreg wrote: post #148
wvenable wrote: post #76

Earlier quoted context omitted.

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…

I wish PHP had classes spread across several files like ASP.NET.

The PHP way for that is Traits
Post reply on HN