Any ideas why they’ve moved from a method-based JIT to tracing?
AFAIK tracing JITs are generally inferior to method-based ones, which is why none of the major JavaScript engines use tracing. Their only advantage seems to be (relative) simplicity, which is essential for the lightweight LuaJIT but not for PHP.
Tiny nitpick: the article describes JavaScript as an interpreted language without JIT when most major JS engines do have JIT optimisation. It’s difficult to make this call about any language with more than one implementation.
But anyway, kudos to the PHP folks for yet another improvement. It’s been a long time since I used it but I’m continually impressed by how far it’s come. And it’s a useful test to how flexible a developer is willing to be to ask them to code some PHP, there are fewer and fewer reasons against it these days other than personal style preference.
The whole idea of "language X is interpreted/compiled" is a simplification I wish people were more careful with.
Cpython is interpreted, pypy has JIT, mypyc is compiled. It's the implementation, or even implementation's specific runtime options that decide about things like that, not the language.
I should probably add this kind of thing to the article then. It is nearly impossible to state "Language X is compiled/interpreted/jitted".
I didn't explicitly say that JS doesn't come with JIT, because I'd be putting Node.JS and every browser engine in the same bag. I simply can't be sure about all of them.
I'll add very soon this caveat that the dialect (js, php, python) doesn't really matter and make it clear that I'm talking about engines, possibly directly point to them.
I hope you understand, though, that I wanted to make JIT as a concept understandable. The language comparisons are secondary.
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, and function/method calls.
And the JITs don't seem to do nearly as good a job there. I tested PyPy on Oil [1] a few years ago, and it made it slower, not faster. And it used more memory. (Though PyPy is an amazing project in many respects.)
The irony of "as fast as C" comparison, is that anyone doing 8 and 16 bit coding on home micros remembers how lousy C compilers used to be (like most other high level languages), to the point that any junior Assembly developer could easily write much better code.
Any language can eventually reach that point with enough money, time, and in C's case doing 200+ optimizations with unexpected results.
Well, most of PHP is calling into C functions (all the standard libs), and as for the rest a JIT can absolutely be as fast (or faster, due to micro-optimizations, profiling, knowledge of non-aliasing, etc) than C.
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.
Good point, but are there really "plenty" of Java implementations that lack an interpreter? There's Graal and Excelsior JET for AOT. Any others? Which implementations do JIT without any interpretation?
There is a small error in the text. When describing the opcache.jit setting it shows examples where the third flag is set to 5, eg 1255, but the table of possible values for the third flag, 'T - JIT trigger', goes from 0 to 4.
Thanks a lot! I blindly fetched this from the reference mentioned there. I'll update this as soon as I have time (probably during this week) and also let the author of the referenced post know about it.
jashmatthews|5 years ago
https://github.com/php/php-src/pull/5874
https://github.com/php/php-src/commit/4bf2d09edeb14467ba7955...
pansa2|5 years ago
AFAIK tracing JITs are generally inferior to method-based ones, which is why none of the major JavaScript engines use tracing. Their only advantage seems to be (relative) simplicity, which is essential for the lightweight LuaJIT but not for PHP.
untog|5 years ago
But anyway, kudos to the PHP folks for yet another improvement. It’s been a long time since I used it but I’m continually impressed by how far it’s come. And it’s a useful test to how flexible a developer is willing to be to ask them to code some PHP, there are fewer and fewer reasons against it these days other than personal style preference.
viraptor|5 years ago
Cpython is interpreted, pypy has JIT, mypyc is compiled. It's the implementation, or even implementation's specific runtime options that decide about things like that, not the language.
nawarian|5 years ago
I didn't explicitly say that JS doesn't come with JIT, because I'd be putting Node.JS and every browser engine in the same bag. I simply can't be sure about all of them.
I'll add very soon this caveat that the dialect (js, php, python) doesn't really matter and make it clear that I'm talking about engines, possibly directly point to them.
I hope you understand, though, that I wanted to make JIT as a concept understandable. The language comparisons are secondary.
Thanks a lot for your feedback!
agumonkey|5 years ago
freelancercv|5 years ago
Truth can be harsh, but people sometime overvalue to such an extent is hard to understand.
chubot|5 years ago
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, and function/method calls.
And the JITs don't seem to do nearly as good a job there. I tested PyPy on Oil [1] a few years ago, and it made it slower, not faster. And it used more memory. (Though PyPy is an amazing project in many respects.)
[1] https://www.oilshell.org
pjmlp|5 years ago
Any language can eventually reach that point with enough money, time, and in C's case doing 200+ optimizations with unexpected results.
bouncycastle|5 years ago
coldtea|5 years ago
So there's nothing really funny about it....
pjmlp|5 years ago
Since 25 years, time to learn that implementations and languages are not the same.
ptx|5 years ago
nawarian|5 years ago
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!
fetbaffe|5 years ago
nawarian|5 years ago
google234123|5 years ago
tyingq|5 years ago
ksec|5 years ago
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.
iKevinShah|5 years ago
Is that not a thing anymore? Genuinely curious
Edit: Yes, some initial searches reveal that it's not a thing anymore.
geek_at|5 years ago
unknown|5 years ago
[deleted]
nawarian|5 years ago
Cheers!
rurban|5 years ago
Deep dives were handled before: https://wiki.php.net/rfc/jit And its discussion https://externals.io/message/103903
CountHackulus|5 years ago