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

Deep Dive into PHP 8's JIT

thephp.website

Post reply on HN
Print view View original

21–30 of 66 posts

Re: Deep Dive into PHP 8's JIT

#21

Post by chubot »

remram wrote: post #18
chubot wrote: post #14

Earlier quoted context omitted.

What I've noticed is that JITs often can reach C speed in workloads like this: sum = 0 for i in xrange(n): for j in xrange(i): sum += A[i][j] And when they reach that milestone, some people call it "as fast as C". Never mind that that's not what people actually write in Python or PHP. It's a synthetic benchmark, not a real workload. The workloads in those languages are generally oriented around strings, hash tables,…

This is not what people write in Python or PHP, but this is what people write in C extensions for Python or PHP. Having your JIT be that fast allows you to forego those extensions and write the low-level hot loops in the same language, and that's a huge improvement. You usually don't care how your matrix multiplication/regex matching/unicode normalization/JSON parsing is implemented, but people had to make those, and…

Well, the problem is that Python and PHP are actually bad languages for expressing code like that. For expressing C. For one, they're not statically typed.

Julia is a dynamic language that seems to do better because it was designed for this purpose.

But it doesn't seem to have panned out in practice in Python, or PHP as far as I know. Those languages have huge piles of C, and whenever you call into C, the JIT gets confused. People don't seem to rewrite their huge piles of C in Python or PHP. In Python, it's more likely Cython.

I'd like to see pointers to counterexamples -- where people actually wrote some C-like code in Python or PHP and let the JIT do its work. I haven't seen it, aside from the PyPy project itself, and maybe a few other examples. I think you would still take a significant performance hit.

The issue is that C compilers in 2020 are even better at compiling the example I showed. They do amazing things with that kind of code that state-of-the-art JITs don't in practice.

Re: Deep Dive into PHP 8's JIT

#22

Post by jashmatthews »

chubot wrote: post #14
freelancercv wrote: post #10

"PHP as fast as C" - People who are in php language development may die laughing reading this statement. Truth can be harsh, but people sometime overvalue to such an extent is hard to understand.

What I've noticed is that JITs often can reach C speed in workloads like this: sum = 0 for i in xrange(n): for j in xrange(i): sum += A[i][j] And when they reach that milestone, some people call it "as fast as C". Never mind that that's not what people actually write in Python or PHP. It's a synthetic benchmark, not a real workload. The workloads in those languages are generally oriented around strings, hash tables,…

This is sort of contradictory but at the same time as expected speed up on "realistic" code isn't as big it's also easier for JIT compiling VMs to optimize high level abstractions than something like C.

JIT compilers have different optimizations available like:

Fast inlined heap allocation (normally much faster than malloc/free). V8 even does allocation combining

Transparent ropes for strings

High level alias analysis for hash tables and objects

Inlining dynamic dispatched functions and dynamically loaded functions

Re: Deep Dive into PHP 8's JIT

#23

Post by viraptor »

tyingq wrote: post #13
colejohnson66 wrote: post #7

Earlier quoted context omitted.

Theoretically, any language can be interpreted. Compilation is just interpreting what a program does and producing machine code (or other code in the case of transpilers) that computes the same thing. Interpreters are just that, but instead of producing code, they run code in themselves thats computes the results directly. One could even consider machine code just “obfuscated” assembly code. In that sense, machine co…

"question: is there a language that can’t be compiled?" There is some question whether Perl could be, because parsing it without running it has some ambiguity. https://www.perlmonks.org/?node_id=663393

That's not really a barrier. It's "can't be parsed without ambiguity", not "can't be parsed". You compile cases like that by compiling a check for the relevant condition, then compile the possible versions in the if/else branches. Unless you can prove which case it will be from other code - then you can simplify anyway.

Re: Deep Dive into PHP 8's JIT

#24

Post by ksec »

tyingq wrote: post #12
google234123 wrote: post #9

Didn't Facebook also develop is JIT for their PHP? Or have they moved on frmo PHP?

Hack/HHVM no longer has a goal to be PHP compatible, but it looks pretty much the same. It does have a JIT: https://hhvm.com/blog/2027/faster-and-cheaper-the-evolution-...

Do we know anyone outside of Facebook uses Hack/HHVM in production?

Re: Deep Dive into PHP 8's JIT

#25

Post by ksec »

May be everyone on HN has Adblock/ PiHole on.

But this Blog, a single page has 5 Google Ads in it. I dont mind one or two, top and bottom. But 5, right in the middle of every section.

Re: Deep Dive into PHP 8's JIT

#26

Post by xioxox »

chubot wrote: post #21
remram wrote: post #18

Earlier quoted context omitted.

This is not what people write in Python or PHP, but this is what people write in C extensions for Python or PHP. Having your JIT be that fast allows you to forego those extensions and write the low-level hot loops in the same language, and that's a huge improvement. You usually don't care how your matrix multiplication/regex matching/unicode normalization/JSON parsing is implemented, but people had to make those, and…

Well, the problem is that Python and PHP are actually bad languages for expressing code like that. For expressing C. For one, they're not statically typed. Julia is a dynamic language that seems to do better because it was designed for this purpose. But it doesn't seem to have panned out in practice in Python, or PHP as far as I know. Those languages have huge piles of C, and whenever you call into C, the JIT gets co…

The Psyco project (now dead) used to get very reasonable speedups (factors of several) in pure Python code, particularly for numeric algorithms. It was retired because PyPy was being developed and was expected to solve all speed problems. I wonder why this approach worked while other python JITs did not.

Re: Deep Dive into PHP 8's JIT

#27

Post by muglug »

ksec wrote: post #24
tyingq wrote: post #12

Earlier quoted context omitted.

Hack/HHVM no longer has a goal to be PHP compatible, but it looks pretty much the same. It does have a JIT: https://hhvm.com/blog/2027/faster-and-cheaper-the-evolution-...

Do we know anyone outside of Facebook uses Hack/HHVM in production?

Slack is the only other company you might have heard of (but still, Slack).

Re: Deep Dive into PHP 8's JIT

#28

Post by chubot »

jashmatthews wrote: post #22
chubot wrote: post #14

Earlier quoted context omitted.

What I've noticed is that JITs often can reach C speed in workloads like this: sum = 0 for i in xrange(n): for j in xrange(i): sum += A[i][j] And when they reach that milestone, some people call it "as fast as C". Never mind that that's not what people actually write in Python or PHP. It's a synthetic benchmark, not a real workload. The workloads in those languages are generally oriented around strings, hash tables,…

This is sort of contradictory but at the same time as expected speed up on "realistic" code isn't as big it's also easier for JIT compiling VMs to optimize high level abstractions than something like C. JIT compilers have different optimizations available like: Fast inlined heap allocation (normally much faster than malloc/free). V8 even does allocation combining Transparent ropes for strings High level alias analysi…

Do you have pointers on those? I'd be interested in the rope optimizations, etc.

Re: Deep Dive into PHP 8's JIT

#29

Post by chubot »

xioxox wrote: post #26
chubot wrote: post #21

Earlier quoted context omitted.

Well, the problem is that Python and PHP are actually bad languages for expressing code like that. For expressing C. For one, they're not statically typed. Julia is a dynamic language that seems to do better because it was designed for this purpose. But it doesn't seem to have panned out in practice in Python, or PHP as far as I know. Those languages have huge piles of C, and whenever you call into C, the JIT gets co…

The Psyco project (now dead) used to get very reasonable speedups (factors of several) in pure Python code, particularly for numeric algorithms. It was retired because PyPy was being developed and was expected to solve all speed problems. I wonder why this approach worked while other python JITs did not.

C is frequently 100x faster than Python for code like the example I showed. With autovectorization and other optimizations it can be 500x.

So if a Python JIT does 10-50x better than CPython on a numeric workload, that sounds impressive, but it's still slow compared to C.

And again they don't get 10-50x on string/hash/method call workloads. I think they're lucky to get 2x in some of those cases.

Re: Deep Dive into PHP 8's JIT

#30

Post by jashmatthews »

chubot wrote: post #28
jashmatthews wrote: post #22

Earlier quoted context omitted.

This is sort of contradictory but at the same time as expected speed up on "realistic" code isn't as big it's also easier for JIT compiling VMs to optimize high level abstractions than something like C. JIT compilers have different optimizations available like: Fast inlined heap allocation (normally much faster than malloc/free). V8 even does allocation combining Transparent ropes for strings High level alias analysi…

Do you have pointers on those? I'd be interested in the rope optimizations, etc.

Off the top of my head something like

https://chrisseaton.com/truffleruby/ropes-manlang.pdf

https://static.googleusercontent.com/media/research.google.c...

https://www.reddit.com/r/programming/comments/wewx2/allocati...

Post reply on HN