4 ms·

I'm sorry, but there is a qualitative difference between, eg, a Java application running on a modern JVM and a Python application executing through the CPython

by another 16y ago

I'm sorry, but there is a qualitative difference between, eg, a Java application running on a modern JVM and a Python application executing through the CPython runtime, neither of which are toys. (Although it's true that CPython is one of the few extant members of a dying breed.) The connotations of "compiled" and "interpreted" might have plenty to do with vague expectations, but the words still mean something in the context of language implementation: even though it is reasonable to call the situations you list "compilation", it would not be accurate to call a language that was compiled to LLVM IR, then interpreted with lli, "compiled".

wisty 16y ago
Note, CPython hasn't strictly been an interpreter for a long long time. It compiles .py files into .pyc files, then runs them. It also does a fair bit of caching. However, it's virtual machine doesn't do much optimization. Yeah, it pre-allocates lots of common data-structures, and reuses old ones rather than using new ones if possible, and I think it might do some stuff with iterators ... but it's nothing like PyPy or a modern JVM.
stcredzero 16y ago
it would not be accurate to call a language that was compiled to LLVM IR, then interpreted with lli, "compiled". Why not? I wouldn't see that as being too different from compiling a Java application and running it on "a modern JVM." With most examples of that I've seen, I think I could fairly characterize them as being "compiled." For some reason, people think of things like MRI 1.8 as being "interpreted" and expect those things to be slow. One could just as well take the same language and run it on a tracing JIT VM. (after some considerable engineering) Semantically, the thing would still be "interpreting bytecodes," just doing it in a highly optimized way. Note that the step where the MRI reads the source and creates an AST is is fundamentally the same as parsing source code and outputting bytecode. There is nothing somehow special or sacred about an intermediate language in the form of bytecode. Given the compiler/VM technology we have today, even the degree to which things are (or aren't) late-bound is more flexible than in the past.
- sb 16y ago
  Regarding your Ruby example and the tracing JIT VM. I think the efforts of Mozilla regarding the TraceMonkey/JaegerMonkey efforts show that while tracing is indeed a very good optimization technique, it is not by all means clear that it performs well on all benchmarks, particularly when compared to V8, which is a traditional method-at-a-time JIT compiler. While I agree that there is nothing special about bytecode, interpreting it is regarded to be faster than AST interpreters. AFAIR, I read a paper about that, too, but cannot for the love of god remember its name/authors; also my impression is that Ruby 1.9 uses a bytecode interpreter (with some optimizations, such as direct threaded code interpreter).
  - lemming 16y ago
    ...particularly when compared to V8, which is a traditional method-at-a-time JIT compiler. Actually, my understanding is that V8 automatically compiles all JS code on load, it has no interpreter. So in a sense it's "method at a time" (i.e. its methods are compiled as units, it's not a trace system) but it's not traditional, and you could make an argument that it's not even a JIT.
    - sb 16y ago
      You are right, V8 does not have an interpreter. However, I think it is fairly accurately desribed as a JIT, because it compiles methods to native code when needed, i.e., before the first invocation/execution of any specific piece of code. Other approaches, like JVM, are more accurately described as "dynamic compilation" sub-systems of the virtual machine. At least that's my understanding of things, and I used to lump everything in that area into the "JIT" category, until (quite recently, actually) someone brought this small but important distinction to my attention. I don't see how one could make an argument not classifying V8 as a JIT compilation virtual machine, though...
- regularfry 16y ago
  > people think of things like MRI 1.8 as being "interpreted" and expect those things to be slow. One could just as well take the same language and run it on a tracing JIT VM. (after some considerable engineering) Off topic, but in case you weren't aware, that "considerable engineering" exists, and is called JRuby. It works (almost) exactly as you describe. And yes, it is rather fast :-)
sb 16y ago
Regarding: "words still mean something in the context of language implementation" Since nobody mentioned it before, the primary advantages of interpreters in the field of pldi are: - ease of implementation - portability This has very important implications to the field of interpreter optimizations, too, since most of them are relatively easy to implement and portable. The ease of implementation advantage when compared to an optimizing native code compiler is usually very big, the same holds true for JIT compilers as well. Portability again is a nice thing to have for optimizations--particularly when compared to the portability of JITs, which need a dedicated native code generating backend for every supported architecture.
jemfinch 16y ago
If you mean by "qualitative difference" that they differ in some substantial way, please describe what that difference is, rather than asserting that it exists. Java interprets bytecodes, Python interprets bytecodes. Java has JIT, Python has a JIT (`import psyco`). Where is the substantial difference between these two? If all you mean by "qualitative difference" is that they use different bytecodes, then you're not saying very much.
- mfukar 16y ago
  Humans produce sounds, lions produce sounds. Humans have mouths, lions have mouths. Where is the substantial difference between the two? Even conceptually, interpreters and compilers differ in certain aspects. For me, the most striking one is that compilers do not fully emulate the results of the given program (one could argue that they do to some extent, when performing optimizations - like when gcc -O3 transforms the whole process to a single printf() call). There are many others, but I hope you get the point.
  - jemfinch 16y ago
    > Humans produce sounds, lions produce sounds. Humans have mouths, lions have mouths. Where is the substantial difference between the two? I asked you a question regarding your previous claim. You responded with a downvote and a rhetorical counter but, again, no answer. I'm mildly familiar with the JVM. I'm very familiar with Python's virtual machine implementation. I ask again: what is the substantial difference between the two? Rhetorical wizardry does not impress me: I actually want to know what your answer is. You said that there is a "qualitative difference" between the two and now have replied implying that it's a substantial difference. I don't understand your reticence to give a real answer here. > Even conceptually, interpreters and compilers differ in certain aspects. That has absolutely nothing to do with my question, and I don't see how it would substantially differentiate between the two implementations we're discussing.
    - mfukar 16y ago
      It wasn't my claim. I responded nonetheless. Whether you wish to accept my answer or not is not something I am interested in.
mfukar 16y ago
Languages can be both interpreted and compiled. However, there are clear differences between a compiler, and an interpreter. That's the fine print that everyone's missing when talking about the distinction between the two (or lack thereof).

by another 16y ago

wisty 16y ago

Note, CPython hasn't strictly been an interpreter for a long long time. It compiles .py files into .pyc files, then runs them. It also does a fair bit of caching. However, it's virtual machine doesn't do much optimization. Yeah, it pre-allocates lots of common data-structures, and reuses old ones rather than using new ones if possible, and I think it might do some stuff with iterators ... but it's nothing like PyPy or a modern JVM.

stcredzero 16y ago

it would not be accurate to call a language that was compiled to LLVM IR, then interpreted with lli, "compiled". Why not? I wouldn't see that as being too different from compiling a Java application and running it on "a modern JVM." With most examples of that I've seen, I think I could fairly characterize them as being "compiled." For some reason, people think of things like MRI 1.8 as being "interpreted" and expect those things to be slow. One could just as well take the same language and run it on a tracing JIT VM. (after some considerable engineering) Semantically, the thing would still be "interpreting bytecodes," just doing it in a highly optimized way. Note that the step where the MRI reads the source and creates an AST is is fundamentally the same as parsing source code and outputting bytecode. There is nothing somehow special or sacred about an intermediate language in the form of bytecode. Given the compiler/VM technology we have today, even the degree to which things are (or aren't) late-bound is more flexible than in the past.

sb 16y ago
Regarding your Ruby example and the tracing JIT VM. I think the efforts of Mozilla regarding the TraceMonkey/JaegerMonkey efforts show that while tracing is indeed a very good optimization technique, it is not by all means clear that it performs well on all benchmarks, particularly when compared to V8, which is a traditional method-at-a-time JIT compiler. While I agree that there is nothing special about bytecode, interpreting it is regarded to be faster than AST interpreters. AFAIR, I read a paper about that, too, but cannot for the love of god remember its name/authors; also my impression is that Ruby 1.9 uses a bytecode interpreter (with some optimizations, such as direct threaded code interpreter).
- lemming 16y ago
  ...particularly when compared to V8, which is a traditional method-at-a-time JIT compiler. Actually, my understanding is that V8 automatically compiles all JS code on load, it has no interpreter. So in a sense it's "method at a time" (i.e. its methods are compiled as units, it's not a trace system) but it's not traditional, and you could make an argument that it's not even a JIT.
  - sb 16y ago
    You are right, V8 does not have an interpreter. However, I think it is fairly accurately desribed as a JIT, because it compiles methods to native code when needed, i.e., before the first invocation/execution of any specific piece of code. Other approaches, like JVM, are more accurately described as "dynamic compilation" sub-systems of the virtual machine. At least that's my understanding of things, and I used to lump everything in that area into the "JIT" category, until (quite recently, actually) someone brought this small but important distinction to my attention. I don't see how one could make an argument not classifying V8 as a JIT compilation virtual machine, though...
regularfry 16y ago
> people think of things like MRI 1.8 as being "interpreted" and expect those things to be slow. One could just as well take the same language and run it on a tracing JIT VM. (after some considerable engineering) Off topic, but in case you weren't aware, that "considerable engineering" exists, and is called JRuby. It works (almost) exactly as you describe. And yes, it is rather fast :-)

sb 16y ago

Regarding: "words still mean something in the context of language implementation" Since nobody mentioned it before, the primary advantages of interpreters in the field of pldi are: - ease of implementation - portability This has very important implications to the field of interpreter optimizations, too, since most of them are relatively easy to implement and portable. The ease of implementation advantage when compared to an optimizing native code compiler is usually very big, the same holds true for JIT compilers as well. Portability again is a nice thing to have for optimizations--particularly when compared to the portability of JITs, which need a dedicated native code generating backend for every supported architecture.

jemfinch 16y ago

If you mean by "qualitative difference" that they differ in some substantial way, please describe what that difference is, rather than asserting that it exists. Java interprets bytecodes, Python interprets bytecodes. Java has JIT, Python has a JIT (`import psyco`). Where is the substantial difference between these two? If all you mean by "qualitative difference" is that they use different bytecodes, then you're not saying very much.

mfukar 16y ago
Humans produce sounds, lions produce sounds. Humans have mouths, lions have mouths. Where is the substantial difference between the two? Even conceptually, interpreters and compilers differ in certain aspects. For me, the most striking one is that compilers do not fully emulate the results of the given program (one could argue that they do to some extent, when performing optimizations - like when gcc -O3 transforms the whole process to a single printf() call). There are many others, but I hope you get the point.
- jemfinch 16y ago
  > Humans produce sounds, lions produce sounds. Humans have mouths, lions have mouths. Where is the substantial difference between the two? I asked you a question regarding your previous claim. You responded with a downvote and a rhetorical counter but, again, no answer. I'm mildly familiar with the JVM. I'm very familiar with Python's virtual machine implementation. I ask again: what is the substantial difference between the two? Rhetorical wizardry does not impress me: I actually want to know what your answer is. You said that there is a "qualitative difference" between the two and now have replied implying that it's a substantial difference. I don't understand your reticence to give a real answer here. > Even conceptually, interpreters and compilers differ in certain aspects. That has absolutely nothing to do with my question, and I don't see how it would substantially differentiate between the two implementations we're discussing.
  - mfukar 16y ago
    It wasn't my claim. I responded nonetheless. Whether you wish to accept my answer or not is not something I am interested in.

mfukar 16y ago

Languages can be both interpreted and compiled. However, there are clear differences between a compiler, and an interpreter. That's the fine print that everyone's missing when talking about the distinction between the two (or lack thereof).