Deep Dive into PHP 8's JIT

Re:Deep Dive into PHP 8's JIT by viraptor on Saturday August 29, 2020 @08:07PM (#24320303)

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.

[ Parent | on HN ]

Re:Deep Dive into PHP 8's JIT by userbinator on Saturday August 29, 2020 @08:22PM (#24320364)

The statement would be far more accurate as "language X is [almost always/sometimes/often/commonly/etc.] interpreted/compiled". Unfortunately a lot of people seem to like speaking in absolutes.

C can be interpreted too: https://en.wikipedia.org/wiki/CINT

[ Parent | on HN ]

Re:Deep Dive into PHP 8's JIT by colejohnson66 on Saturday August 29, 2020 @08:38PM (#24320426)

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 code is just another language that also could be interpreted (intepretation-based emulators like Bochs) or compiled again (JIT-based emulators like DOSBox).

This brings up a slightly related question: is there a language that can’t be compiled?

[ Parent | on HN ]

Re:Deep Dive into PHP 8's JIT by smabie on Saturday August 29, 2020 @10:59PM (#24321012)

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!

[ Parent | on HN ]

Re:Deep Dive into PHP 8's JIT by colejohnson66 on Sunday August 30, 2020 @12:54PM (#24324050)

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.

[ Parent | on HN ]

Re:Deep Dive into PHP 8's JIT by chrisseaton on Saturday August 29, 2020 @09:55PM (#24320721)

> This brings up a slightly related question: is there a language that can’t be compiled?

Not sure if you're asking this platonically, but Futamura shows us that if you can built an interpreter then you can always transform that automatically to be a compiler.

This is used in practice by some compilers today - they automatically produce a compiler from an interpreter!

[ Parent | on HN ]

Re:Deep Dive into PHP 8's JIT by tyingq on Saturday August 29, 2020 @09:30PM (#24320625)

"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

[ Parent | on HN ]

Re:Deep Dive into PHP 8's JIT by viraptor on Sunday August 30, 2020 @12:29AM (#24321380)

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.

[ Parent | on HN ]

Re:Deep Dive into PHP 8's JIT by Kednicma on Saturday August 29, 2020 @09:44PM (#24320675)

By wielding the Futamura projections [0][1][2], any interpreter may be turned into a compiler. Perl is handled as one case. Crucially, the resulting compiler need not be fast; if the interpreter is slow, then the compiler will be slow too (this is a special case of the central meme from [3], "if the N'th Futamura projection has quality Q, then the N+1'th Futamura projection will also have quality Q.")

[0] https://en.wikipedia.org/wiki/Partial_evaluation#Futamura_pr...

[1] http://blog.sigfpe.com/2009/05/three-projections-of-doctor-f...

[2] https://www.gwern.net/docs/cs/2009-gluck.pdf

[3] https://www.itu.dk/people/sestoft/pebook/

[ Parent | on HN ]

Re:Deep Dive into PHP 8's JIT by coldtea on Sunday August 30, 2020 @04:39AM (#24322187)

>Unfortunately a lot of people seem to like speaking in absolutes.

People like speaking in the general case. It saves time from enumeating any inconsequential / statistically not relevant exception.

The real problem is people misunderstanding casual discussion absolutes (which mean "for the large majority/for the ones people care about") with mathematical absolutes (i.e. "X is Y for each and every X")

[ Parent | on HN ]

Re:Deep Dive into PHP 8's JIT by lights0123 on Saturday August 29, 2020 @08:37PM (#24320420)

And the Rust compiler ships with a Rust interpreter, used to evaluate const fns (functions whose output can be determined at compile time).

[ Parent | on HN ]

Re:Deep Dive into PHP 8's JIT by richardwhiuk on Saturday August 29, 2020 @08:46PM (#24320455)

const fns can only use a subset of the language AIUI

[ Parent | on HN ]

Re:Deep Dive into PHP 8's JIT by coldtea on Sunday August 30, 2020 @04:37AM (#24322181)

Well, the idea being that CPython is 99% of what people use, and the other are nearly irrelevant projects...

[ Parent | on HN ]