Why are interpreters used?

  • (2 Pages)
  • +
  • 1
  • 2

23 Replies - 1732 Views - Last Post: 18 January 2019 - 08:32 AM

#1 Nwb   User is offline

  • D.I.C Head

Reputation: 1
  • View blog
  • Posts: 98
  • Joined: 11-November 18

Why are interpreters used?

Posted 11 January 2019 - 11:35 PM

What makes interpreters useful and preferred over compilers in some situations? What are the situations where interpreters are more useful?

Granted you have to spend a lot of time compiling whereas with interpreters you can directly start testing. But.. you can compile and link multiple files and that will reduce time needed to compile drastically. And interpreting would take the same resources as compilers would but compilers only need to compile once, so interpreters should be a very bad idea right (because they interpret every time they run)?

Another thing, what happens when you make a binary file (.exe) with an interpreter? Is the binary file still interpreted? How does that work.. does the binary file also need to include the interpreter itself..? Python is interpreted and it can be exported as a .py or a .exe that's why I asked. And you wouldn't use .py for distribution because .py allows users to read the file and users need Python to run .py files. If the binary file isn't interpreted then Python should be a compiled language..

Why are interpreters used! :dots:/>

This post has been edited by Nwb: 11 January 2019 - 11:40 PM


Is This A Good Question/Topic? 0
  • +

Replies To: Why are interpreters used?

#2 sepp2k   User is offline

  • D.I.C Lover
  • member icon

Reputation: 2740
  • View blog
  • Posts: 4,392
  • Joined: 21-June 11

Re: Why are interpreters used?

Posted 12 January 2019 - 09:40 AM

View PostNwb, on 12 January 2019 - 07:35 AM, said:

What makes interpreters useful and preferred over compilers in some situations? What are the situations where interpreters are more useful?


Given a sufficiently dynamic language, an interpreter with a decent JIT-compiler will usually lead to better performance than a traditional AOT compiler would for that language. That is, if you write a compiler that compiles, say, Javascript directly to machine code (as opposed to something that simply bundles the source code and an interpreter into an executable file), you'll very likely end up with worse performance than using the common Javascript engines.

Additionally using an interpreter (or something like Java or .net where you compile to some bytecode format and then interpret/JIT-compile that bytecode) means you don't have to provide binaries for every damn system you want to support (though technically you don't have to do that with a compiler either - you can just tell users to compile it themselves).

Quote

And interpreting would take the same resources as compilers would but compilers only need to compile once


This is not generally true. A bytecode-executing interpreter generally does significantly less work than an optimizing AOT-compiler (at the cost of the code being less optimized, of course). A JIT-compiler does more work, but still has to do less static analysis than an AOT-compiler (especially if you consider that if an AOT-compiler wants to achieve decent performance for a dynamic language, it'd have to do a lot more analysis than for a language like C), so still ends up doing less work.

Quote

Another thing, what happens when you make a binary file (.exe) with an interpreter?


What do you mean by that? If you have a tool that reads source code and produces an .exe file as output, then that tool is not an interpreter. Maybe you're referring to tools like py2exe, which some times refer to themselves as compilers, but are perhaps more accurately described as "bundlers" or something like that (but definitely not as interpreters). Those tools simply embed the source code (and its dependencies) and an interpreter into the .exe file and when you run the .exe, the interpreter will simply execute the source code.

Quote

Python is interpreted


Languages aren't interpreted or compiled. They can have many different implementations and each of those implementations could be an interpreter or a compiler. So it's perfectly possible to have both an interpreter and a compiler for the same language. That said, when you "export" a Python project to an .exe, you're most likely using py2exe and that indeed just bundles the source code with an interpreter.
Was This Post Helpful? 4
  • +
  • -

#3 sepp2k   User is offline

  • D.I.C Lover
  • member icon

Reputation: 2740
  • View blog
  • Posts: 4,392
  • Joined: 21-June 11

Re: Why are interpreters used?

Posted 12 January 2019 - 09:59 AM

View Postsepp2k, on 12 January 2019 - 05:40 PM, said:

Languages aren't interpreted or compiled.


To expand a bit on that: People often say things like "Langue X is compiled" or "Language Y is interpreted", but what they mean by that is simply that the language's primary implementation is a compiler or interpreter respectively (or even that all of the langauge's currently existing implementations are). However that's merely a statement about the tools that currently exist for the language, not a property inherent in the language itself (though there are definitely properties a language can have that make it more or less reasonable to compile or interpret it).
Was This Post Helpful? 2
  • +
  • -

#4 Nwb   User is offline

  • D.I.C Head

Reputation: 1
  • View blog
  • Posts: 98
  • Joined: 11-November 18

Re: Why are interpreters used?

Posted 12 January 2019 - 09:01 PM

Why is JIT better in performance than AOT? But it is said that C is faster right? But C is AOT primarily..

If JIT is better, why doesn't C/C++ also have a JIT interpreter?
Was This Post Helpful? 0
  • +
  • -

#5 sepp2k   User is offline

  • D.I.C Lover
  • member icon

Reputation: 2740
  • View blog
  • Posts: 4,392
  • Joined: 21-June 11

Re: Why are interpreters used?

Posted 12 January 2019 - 10:04 PM

View PostNwb, on 13 January 2019 - 05:01 AM, said:

Why is JIT better in performance than AOT?


For example, you can generate better code if you know the types of things or even if you know which definition of a function is used when a function is called (because functions can be redefined in many dynamic languages). A JIT knows which types a function has been called with thus far (and how often), so it can generate specialized versions of a function for those types. Similary a JIT knows which definition of a function is active at the moment, so it can optimize accordingly and then simply deoptimize (and then possibly reoptimize) when a function is redefined.

An AOT is generally stuck with the code it generated in the first place (unless you go with some sort of hybrid approach where the generated code contains the ability to JIT-compile new code at runtime).

Quote

If JIT is better, why doesn't C/C++ also have a JIT interpreter?


I said "given a sufficiently dynamic language". C and C++ are not dynamic languages.

This post has been edited by sepp2k: 12 January 2019 - 10:05 PM

Was This Post Helpful? 0
  • +
  • -

#6 Nwb   User is offline

  • D.I.C Head

Reputation: 1
  • View blog
  • Posts: 98
  • Joined: 11-November 18

Re: Why are interpreters used?

Posted 12 January 2019 - 11:37 PM

View Postsepp2k, on 12 January 2019 - 10:04 PM, said:

View PostNwb, on 13 January 2019 - 05:01 AM, said:

Why is JIT better in performance than AOT?


For example, you can generate better code if you know the types of things or even if you know which definition of a function is used when a function is called (because functions can be redefined in many dynamic languages). A JIT knows which types a function has been called with thus far (and how often), so it can generate specialized versions of a function for those types. Similary a JIT knows which definition of a function is active at the moment, so it can optimize accordingly and then simply deoptimize (and then possibly reoptimize) when a function is redefined.

An AOT is generally stuck with the code it generated in the first place (unless you go with some sort of hybrid approach where the generated code contains the ability to JIT-compile new code at runtime).

Quote

If JIT is better, why doesn't C/C++ also have a JIT interpreter?


I said "given a sufficiently dynamic language". C and C++ are not dynamic languages.


Okay so basically dynamic languages weren't designed to be compiled so they give better performance when interpreted. But compiling is still faster than interpreting.

Correct?
Was This Post Helpful? 0
  • +
  • -

#7 baavgai   User is offline

  • Dreaming Coder
  • member icon


Reputation: 7446
  • View blog
  • Posts: 15,440
  • Joined: 16-October 07

Re: Why are interpreters used?

Posted 13 January 2019 - 04:25 AM

We seem to be hung up on term "interpreted." If a fundamental sense, all code is interpreted, the distinction is what is done with that interpretation.

C/C++ source ends at executable machine code. Stage one, compilation, essentially run a interpreter that reads and parses source and spits out "object code." You could argue that this object code is machine code, but since it can't actually run until linked up, it's still basically p-code for a linker. The linker then produces a final machine code stand alone executable, presumably, but not necessarily, without any linker artifacts.

Contrast with BASIC, the oldest(?) interpreter, where the lines of code would parsed, staged internally as p-code, then passed off to an internal processor. The interpreter and the development environment were intrinsically integrated and you suffered for low memory to start with: this is the origin of the myth of slow interpreted code.

Java re branded the interpretation process. It "compiles" into p-code that is then run in an entirely separate virtual machine. From a design perspective, this is effectively like a C program where the final piece, the JVM, must always be linked at runtime. Sure, there is overhead at startup, but it is not as dire as a "bare metal or die" zealot might have you believe.

Python is kind of a BASIC/Java hybrid, in this respect. It caches p-code files, .pyc, so while the interpreter must be present, it needn't reinvent the wheel every time. This architecture is why import antigravity works. The program doesn't need to have all the pieces to hand, they only need to be somewhere on the system when asked for.

Posted Image

If you make an executable from Java, Python, or anything else that doesn't deploy as such, you're essentially just using a wrapper that will run the interpreters internally so you don't have to fret about it.

So, if Java compiled to an executable, it would loose the ability for the same p-code (.jar/.class files) to be deployed on multiple platforms, which was kind of the point of the language. If Python compiled to an executable, you'd loose the ability to import all the things, which is debatably a selling point of that language.
Was This Post Helpful? 1
  • +
  • -

#8 baavgai   User is offline

  • Dreaming Coder
  • member icon


Reputation: 7446
  • View blog
  • Posts: 15,440
  • Joined: 16-October 07

Re: Why are interpreters used?

Posted 13 January 2019 - 04:37 AM

View PostNwb, on 13 January 2019 - 01:37 AM, said:

Okay so basically dynamic languages weren't designed to be compiled

Generally, no. However, this is more a function of priorities than anything else. Anyone with enough wit to design a language would completely understand what a "compiler" does and doesn't buy them.

This one seems entirely based on the belief that compiled is gooder:

Quote

Julia is a high-level general-purpose[13] dynamic programming language that was originally designed to address the needs of high-performance numerical analysis and computational science, without the typical need of separate compilation to be fast,
-- https://en.wikipedia...ing_language%29


For a less arcane example: OCaml, a language I quite like, has a native code option. This is the language on which F# was based. I'm not sure if it entirely fits the "dynamic" requirement in all respects, but it can certainly function in that domain.
Was This Post Helpful? 0
  • +
  • -

#9 sepp2k   User is offline

  • D.I.C Lover
  • member icon

Reputation: 2740
  • View blog
  • Posts: 4,392
  • Joined: 21-June 11

Re: Why are interpreters used?

Posted 13 January 2019 - 11:31 AM

View PostNwb, on 13 January 2019 - 07:37 AM, said:

Okay so basically dynamic languages weren't designed to be compiled so they give better performance when interpreted. But compiling is still faster than interpreting.


What do you mean by that? If you mean "AOT-compiling any given language X leads to faster code than JIT-compiling it", then you're directly contradicting your previous sentence. If you mean "AOT-compiling C leads to faster code than JIT-compiling Javascript", you're comparing apples to oranges. Also there are probably cases where that isn't even true.

It's just more complicated than that. You can't boil it down to "X is better than Y". Generally I'd say, the more dynamic a language, the more it benefits from JITting over AOT, but that doesn't mean that JITting static languages would be bad. For long-running programs, JITting can beat AOT for any language, I'd say. After all, theoretically (if you don't care about warm up time at all), a JIT can perform any optimization an AOT can and then some (but then you usually do care at least somewhat about warm up time). Also note that, unless you make your users compile the code themselves on their system using -march=native (or your compiler's equivalent), AOTs won't be able to make optimal use of CPU-specific features the way that JITs can.

So it's a trade-off. If you need programs to be fast right off the bat without any warm up phase, nothing beats AOT on a sufficiently static language. In many other cases JITs can be better.
Was This Post Helpful? 0
  • +
  • -

#10 sepp2k   User is offline

  • D.I.C Lover
  • member icon

Reputation: 2740
  • View blog
  • Posts: 4,392
  • Joined: 21-June 11

Re: Why are interpreters used?

Posted 13 January 2019 - 12:03 PM

View Postbaavgai, on 13 January 2019 - 12:25 PM, said:

C/C++ source ends at executable machine code.


Which is to say that the common implementations of those languages work that way. As I've said before, it is important to distinguish between a language and its implementation. It is perfectly possible to write an interpreter for C or C++.

Quote

Stage one, compilation, essentially run a interpreter that reads and parses source and spits out "object code."


That's a very non-standard use of the word "interpreter".

Quote

Java re branded the interpretation process. It "compiles" into p-code that is then run in an entirely separate virtual machine. From a design perspective, this is effectively like a C program where the final piece, the JVM, must always be linked at runtime.


I do not agree with that at all. The process of a JVM interpreting and/or JIT-compiling Java bytecode is fundamentally different from what a linker does. When a non-JITting JVM executes Java bytecode, it works as an interpreter that executes the instructions directly. At no point is any machine code being generated, the only machine code is that of the JVM itself. A JITting JVM will (eventually) translate the bytecode to machine code. That's a lot more than a linker does: it doesn't just replace symbols with addresses - it translates from one instruction set into a completely different one. If anything, it's like a combination phase of an AOT compiler where the IR (LLVM, GIMPLE, etc.) is translated to object plus the linking phase.

Quote

Python is kind of a BASIC/Java hybrid, in this respect. It caches p-code files, .pyc, so while the interpreter must be present, it needn't reinvent the wheel every time. This architecture is why import antigravity works.


What? Importing modules would work just fine if .pyc didn't exist - it would just be slower (after the first time).


View Postbaavgai, on 13 January 2019 - 12:37 PM, said:

OCaml, a language I quite like, has a native code option. This is the language on which F# was based. I'm not sure if it entirely fits the "dynamic" requirement in all respects, but it can certainly function in that domain.


I don't know what you mean by "function in that domain", but there's nothing dynamic about OCaml. It's statically typed, has no run-time reflection and no ways of defining or redefining anything (functions, modules, etc.) at run time.
Was This Post Helpful? 0
  • +
  • -

#11 Nwb   User is offline

  • D.I.C Head

Reputation: 1
  • View blog
  • Posts: 98
  • Joined: 11-November 18

Re: Why are interpreters used?

Posted 14 January 2019 - 10:18 AM

So for something where utilising the users machine properly is necessary then JIT beats AOT (and about runtime optimization) . Does that mean commercial games are more commonly made with JIT?

But for bare metal and bones AOT could be faster than JIT.

Why isn't there an interpreter for c!

This post has been edited by Nwb: 14 January 2019 - 10:19 AM

Was This Post Helpful? 0
  • +
  • -

#12 sepp2k   User is offline

  • D.I.C Lover
  • member icon

Reputation: 2740
  • View blog
  • Posts: 4,392
  • Joined: 21-June 11

Re: Why are interpreters used?

Posted 14 January 2019 - 10:55 AM

View PostNwb, on 14 January 2019 - 06:18 PM, said:

So for something where utilising the users machine properly is necessary then JIT beats AOT (and about runtime optimization) . Does that mean commercial games are more commonly made with JIT?


Often the game engine is written in C++ (and compiled using standard AOT C++ compilers) and the game logic is possibly written in another language (some games are entirely written in C++, but others use Python or LUA - the Unity engine uses C#).

JITting the performance-sensitive engine code is probably a bad idea because you want reliable performance. It's not a good user experience if the game starts with a bad frame rate and then only stabilizes as the warm up phase is over. And in a more general sense, at the level where you hand-craft code for maximum performance, you want the code to act predictably performance-wise - you don't want the code to perform differently each time based on whether it's been JITted, deoptimized, reoptimized etc. You want it to perform the same each time.
Was This Post Helpful? 1
  • +
  • -

#13 Skydiver   User is offline

  • Code herder
  • member icon

Reputation: 6968
  • View blog
  • Posts: 23,678
  • Joined: 05-May 12

Re: Why are interpreters used?

Posted 14 January 2019 - 02:35 PM

As an aside, one of Microsoft's "secret sauce" for it's C++ based products a special linking pass. Testers do performance runs on programs using commonly used scenarios to find hotspots. That information is then fed back into the linker and so the linker will optimize the code based on those hotspots and commonly used scenarios. The linker is given the freedom to not only re-arrange blocks of code, but also break up blocks of code and re-assemble them so that the memory cache and pipeline are fully utilized. So it's almost like the JIT-ter adapting to how the program is used, but in this case the adaptation process is pre-baked.

On another topic about compiled vs. interpreted, would you consider SQL as compiled or interpreted? Or does it depend on the DBMS and whether is always re-parses and evaluates the SQL, or if it parses once, analyzes, optimizes, and then evaluates?

And yet another avenue to explore/discuss is that the first C++ compiler actually generated C code, and then that C code would be compiled.

And then there is also YACC (Yet Another Compiler Compiler)? Is it actually compiling? Or is it interpreting?
Was This Post Helpful? 1
  • +
  • -

#14 sepp2k   User is offline

  • D.I.C Lover
  • member icon

Reputation: 2740
  • View blog
  • Posts: 4,392
  • Joined: 21-June 11

Re: Why are interpreters used?

Posted 14 January 2019 - 02:46 PM

View PostSkydiver, on 14 January 2019 - 10:35 PM, said:

And yet another avenue to explore/discuss is that the first C++ compiler actually generated C code, and then that C code would be compiled.


I wouldn't make a distinction between compiling and translating like that. I'd say the first C++ compiler compiled to C.

Quote

And then there is also YACC (Yet Another Compiler Compiler)? Is it actually compiling? Or is it interpreting?


Do you mean yacc itself or the yacc-generated code? I've always felt that yacc is somewhat misnamed because 1. there's more to a compiler than the parser and yacc only generates the parser for you and 2. you can use yacc in projects that aren't compiler. So it should really be called yet-another-parser-compiler or yet-another-parser-generator.

So I'd say the code generated by yacc is a parser and whether that parser is part of a compiler or an interpreter (or something else entirely - like a configuration file reader) depends on what the rest of the code does (or what you do inside the actions).

And for YACC itself, I'd say it's fair to call it a compiler. It reads code in one language (the YACC grammar language) and outputs code in another © - so that's a compiler in my book. Though the term "parser generator" has become much more popular than "compiler compiler" in the mean time.
Was This Post Helpful? 1
  • +
  • -

#15 Skydiver   User is offline

  • Code herder
  • member icon

Reputation: 6968
  • View blog
  • Posts: 23,678
  • Joined: 05-May 12

Re: Why are interpreters used?

Posted 14 January 2019 - 02:47 PM

View PostSkydiver, on 14 January 2019 - 04:35 PM, said:

As an aside, one of Microsoft's "secret sauce" for it's C++ based products a special linking pass.

Looks like "secret sauce" is now publicly available: Profile-Guided Optimizations
Was This Post Helpful? 0
  • +
  • -

  • (2 Pages)
  • +
  • 1
  • 2