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

61–66 of 66 posts

Re: Deep Dive into PHP 8's JIT

#61

Post by pjmlp »

nawarian wrote: post #53
pjmlp wrote: post #36

Unless we are speaking about Java before Java 1.2, it is definitely not interpreted, there are plenty of JIT and AOT implementations without any kind of interpretation step. Since 25 years, time to learn that implementations and languages are not the same.

I might be wrong here, as I'm not so close to Java development. But a language implementing JIT, at least to me, is interpreted. Could you please point an implementation detail where a JIT-capable engine doesn't include interpretation in its runtime? In every case, thanks a lot for your feedback!

Well, from CS compiler theory point of view it is not.

For example in .NET, MSIL goes directly into a pipeline that produces native. You can easily validate that RyuJIT has no interpretation.

Or for example, watchOS applications packaged with bitcode, get JIT compiled at installation time.

Re: Deep Dive into PHP 8's JIT

#62

Post by aardvark179 »

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…

It’s not that the JIT gets confused, it’s that the C APIs for these languages can do almost anything - even stuff that you can’t normally do in the language. So you are faced with a giant optimization boundary.

However a call to a shared library that isn’t linked against your language API is not very expensive as you have a much better handle on the values that are escaping and can make much better optimization choices.

In the Truffle project we are using an LLVM bitcode interpreter that allows us to JIT right through that language boundary and still link to native shared libraries. This means people shouldn’t have to rewrite their C extensions and we can hopefully still run the combination of high level language and C extension faster.

Re: Deep Dive into PHP 8's JIT

#63

Post by colejohnson66 »

smabie wrote: post #19
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…

Of course not, just compile your interpreter but instead of reading input from a file, have it read input from a fixed string (the source code) that is embedded in the binary. You've just created a super shitty compiler!

I personally wouldn’t consider that a compiler but just an interpreter bundled with the source. For example: Electron based desktop programs aren’t considered compiled (by anyone I know) even though they pack the interpreter (Chromium) with the source.

Re: Deep Dive into PHP 8's JIT

#64

Post by todotask »

rovr138 wrote: post #20
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,…

What I want to see a benchmark like this one, https://kinsta.com/blog/php-benchmarks/ I think a workload like this is more common in the PHP world. Not saying that others don’t exist, but handling routing, queries, cached content is very different from simply doing mathematical/memory intensive applications.

You could do that on VPS or your machine but heavyweight plugin like Woocommerce can incurred performance and memory issues that they can do little to improve if you’re referring to benchmark with CMS.

Re: Deep Dive into PHP 8's JIT

#65

Post by jashmatthews »

aardvark179 wrote: post #62
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…

It’s not that the JIT gets confused, it’s that the C APIs for these languages can do almost anything - even stuff that you can’t normally do in the language. So you are faced with a giant optimization boundary. However a call to a shared library that isn’t linked against your language API is not very expensive as you have a much better handle on the values that are escaping and can make much better optimization choic…

That optimization boundary seems like it's much more of a problem for TruffleRuby than it is for language-specific native implementations? IIRC TruffleRuby relies a lot on being able to optimize away Ruby objects and frames and there's quite a performance cliff if you have to materialize full escaping objects?

JSC and LuaJIT have simpler ways to deal with calling native code which might do weird stuff.

Re: Deep Dive into PHP 8's JIT

#66

Post by nym3r0s »

njuw wrote: post #46
nym3r0s wrote: post #34

Earlier quoted context omitted.

Wikipedia runs on HHVM IIRC. https://hhvm.com/blog/7205/wikipedia-on-hhvm

Wikipedia was moved back to PHP: - https://phabricator.wikimedia.org/T176370 - https://phabricator.wikimedia.org/T229792 - https://launchdarkly.com/blog/how-the-wikimedia-foundation-s...

Didn't know that. Thanks for the info!
Post reply on HN