Why does compiled take more RAM than interpreted

[Grime]

I don't get it.. Both should take the same memory for the same code right?

[helios]

I assume the question is supposed to be "why does a compiled program use more memory than an interpreted program?"

The answer is that it doesn't. Given two identical processes, one running the compiled version of a codebase, and another running an interpreted or semi-interpreted version of the same codebase, for the same input the interpreted version will require at least as much memory as the compiled version, simply because in the most optimistic case the interpreted version will only store in memory the exact same code as the compiled version. In reality, interpreters and VMs add space inefficiencies in various ways:
* The simplest problem is that the execution engine itself needs to be kept somewhere in memory. Additionally, compiler code will generally also be present, although in principle it could be unloaded (it's rarely worth the bother, though).
* Interpreters usually present to the program a second-level address space or memory model, so they add a little bit of overhead at various levels for its own memory accounting data structures. Usually it'll be overhead per object or per memory page.

[Grime]

I quote from my textbook:

"The process of compilation consumes a lot of memory and so systems with less amount of RAM always prefer interpreters where the source code is analyzed line by line and executed immediately and it reduced the need for larger RAM capacities."

Why does compilation consume a lot of memory? And why do interpreters take less RAM? I didn't understand that paragraph.

@helios compiled doesn't have larger file size than interpreted? Is that what you're saying? Because the interpreter is embedded in the executable file? I used to think to get an executable file you need to compile..


Why are interpreters used :'(. Whyyy are they used over compilers?

[helios]

"The process of compilation consumes a lot of memory and so systems with less amount of RAM always prefer interpreters where the source code is analyzed line by line and executed immediately and it reduced the need for larger RAM capacities."

That text is comparing the cost of compilation, to the cost of interpretation, which are strange things to compare. The book is basically making this argument:
"To record an album of an orchestra you need an orchestra, a studio, and a CD production plant, but to listen to a live orchestra you just need an orchestra, therefore when you want to listen to an orchestra at home it's better to pay for an orchestra to come to your home than to buy a CD."

Compilation does indeed take a lot of resources, particularly in complex languages like C++, which can execute code at compile time to generate more code. However, in the most resource-constrained environments, such as microcontrollers and embedded processors, this is irrelevant, because compilation and execution take place in different machines. To program a TV you don't bundle a compiler with the TV. You set up a build server that spits out a single binary blob that can be loaded and directly executed by the TV's CPU.
Additionally, compilation is a one-time cost. You compile once and then you can run that build as many times as you want. Interpretation is an on-going cost.

Why does compilation consume a lot of memory?

It depends on the particular language. In the particular case of C++, just parsing a file can take large amounts of memory (even for small source files) due to templates. For other languages it's not a given that compilation is memory-intensive.

And why do interpreters take less RAM?

They don't, as I explained earlier.

compiled doesn't have larger file size than interpreted?

It depends on how you're counting.

Suppose you have a hypothetical language X that provides both a compiler and an interpreted implementation, and you have this source file (hello.x):

print "Hello, World!\n"

When you compile this with the X compiler you get back a 40 KiB executable. That's quite larger than hello.x, isn't it? However, that's not a very useful comparison. You can copy the executable file to any computer with the same OS and run it, regardless of what other software may be installed there. If you copy hello.x by itself, the destination computer will probably not know what to do with it. No CPU on Earth directly implements the X language. At least you will need to copy the X interpreter as well, and given that it does quite a lot more than just print a string to the screen, it will definitely be a lot larger than 40 KiB.

Because the interpreter is embedded in the executable file?

No, that's not how executables work. An executable file contains code that is directly executable by a CPU (it may also contain other things that are not relevant to this discussion). On some simple platforms running an executable may simply consist of putting the entire file in memory and setting the CPU to start executing from the beginning. This is how games were executed in old consoles such as the NES and the Game Boy.

Modern platforms such as Windows or Linux have vastly more complex loading procedures, but at the heart the main active ingredient is that a block of a file is copied to memory and the CPU is set to execute that block.

I used to think to get an executable file you need to compile.

Well, yes (unless you hand-write the executable, of course).

[Grime]

Thanks a lot helios

Python has an extension .py which can be run on any platform. That's fine. But since .py files can be edited by the user, you probably want a .exe. So even though you're using an interpreted language, you are eventually compiling.

So the only time you're interpreting is for debugging. Is debugging better with interpreted (another point I saw online), if so how? And if interpreted were better, then why doesn't C++ use interpreting for debugging?

Is that right?

[helios]

So the only time you're interpreting is for debugging.

No, not really.

Is debugging better with interpreted (another point I saw online), if so how?

No, how easy it is debug a program and whether that program is interpreted or not are entirely unrelated. IMO the best language to debug is C# (or really any .NET language), which is arguably not interpreted (it depends on how you classify JIT compilation); I assume JVM languages are about equally easy to debug. The second best is C++.
On the other hand, JavaScript, which is JITted like C#, has horrible debugging support; figuring out what a JS program is doing at any given time without modifying the code is basically impossible.

And if interpreted were better, then why doesn't C++ use interpreting for debugging?

Regardless of the effect of interpretation on ease of debugging (which is none) there are basically no* C++ interpreters because C++ is such a complex language to implement. Just implementing a C++ compiler requires tremendous amounts of effort by itself. And nobody really wants to interpret C++. If someone is choosing C++ for their project it's because they want speed, which an interpreter is incapable of providing.


* There is one C++ interpreter, but last time I checked it doesn't support C++ exactly, but rather a modified dialect that adds some features and removes others.

[Grime]

No, not really.
Then when are you using the interpreting of the interpreter? Need to compile to get an executable right?

[helios]

Then when are you using the interpreting of the interpreter?

Umm... I don't know how to answer this question without falling into a tautology. You're using an interpreter when you use an interpreter, and any time you don't use an interpreter you're not using an interpreter.
You mentioned Python earlier. If the python process is running, then you're using the Python interpreter, and if there are no instances of python running then you're not using the Python interpreter (for the sake of argument let's ignore that the Python interpreter can be loaded as a library by other programs).

Need to compile to get an executable right?

I have no idea how this question relates to the question that precedes it. "Yes, you do need to execute a compiler to obtain an executable." What does it have to do with interpreters?

[E0p9LyTq]

I quote from my textbook:

That book is written by an idiot.

Compilation of source code is not execution of that code.

[Grime]

helios..
When you make a .exe of python.. The .exe is interpreted?
But you need to compile to get a .exe?
Or is what you are saying is that you compile to get a .exe that is interpreted? But you said executables need to be able to be read by the CPU..

Sorry for my lack of computer knowledge I might end up confusing you yourself if you spend enough time with me.. ;p

So anyways, why are interpreters used then? Seems to me that compilers beat interpreters in every way..

[helios]

When you make a .exe of python.

As far as I know, this is impossible, but sure, let's suppose that it's possible to compile Python into an executable.

The .exe is interpreted?

No. An executable is not interpreted. If it's interpreted it's not an executable.

Or is what you are saying is that you compile to get a .exe that is interpreted?

No, I never said anything like that.

But you said executables need to be able to be read by the CPU.

It's not that it needs to be. Being understood by the CPU is part of the definition of "executable". If the CPU can't understand it then it's not an executable.

So anyways, why are interpreters used then? Seems to me that compilers beat interpreters in every way..

Many reasons.
First a few facts:
* A full-fledged compiler (i.e. source code enters, machine code leaves) is a complex piece of software.
* Full compilation -- including optimization, machine code generation, etc. -- is a complex procedure.
* An interpreter can be very simple, especially if you can design a language specific for the application.

So, when will an interpreter be used?

1. When the code is modified very often. This is the case for example in video game development, where the engine, implementing the most resource-intensive functions will be written in C++ or some other compiled language, but the code implementing the rules of the game, events in the story, etc. will be written in an interpreted language, to speed up development and testing. Some scripting engines even support hotpatching (replacing code without stopping the program).
Another example of this, to some extent, is JS delivered over the web. Although modern web browsers use JIT compilation for JS to speed it up.

2. When some parts of the program need to be user-modifiable but compilation would add too much complexity without adding enough benefits. For example, Emacs has for ages included an interpreter for "Emacs Lisp", which allows the user to modify the behavior of the editor. People have used it to implement syntax highlighting, image viewers (in ASCII) web browsers, etc. The alternative would have been for Emacs to compile user scripts using the system's compiler, bundle its own compiler, or link to dynamic libraries instead of scripts (this latter method is used by some programs, such as Winamp, to implement plugins, because the developers considered that speed did matter).

[E0p9LyTq]

As far as I know, this is impossible, but sure, let's suppose that it's possible to compile Python into an executable.

Apparently it is possible.

https://mborgerson.com/creating-an-executable-from-a-python-script/

Now whether it creates a machine code executable as a C++ compiler does, or a byte code file that requires a VM like Java to run, I can't say.

[helios]

I would guess it bundles an interpreter and the bytecode into the executable. AFAIK Python requires a compiler (or at least a parser and VM) being present to support all its features. Apparently there's an AOT compiler called rpython that transpiles a subset of Python to plain C.

[Grime]

Because the interpreter is embedded in the executable file?

No, that's not how executables work.

I would guess it bundles an interpreter and the bytecode into the executable.

Me is confused. So it keeps in interpreter as a resource file?

When big companies make video games with Python (let's say), and use some C++ for parts and another language for parts of the game.. How do they link all of these bits?

They can't have .py files in their game resource folder because users can edit it right.. So how do they store their python files or do they compile python? Do they make their own encrypted file extension that only their interpreter can read? Or the code and interpreter are inside the executable itself..

If you could just store any file in .exe why wouldn't you just store everything?

Can you update to an already existing .exe (probably not..)? Otherwise how are games able to update only small amounts of data instead of having to redownload the entire thing.. Do they store their code outside the executable? How do they store it?

Is that situation where interpreters are preferred? For times when there's a lot of updating to do constantly.. but since C++ is faster, wouldn't it pay to compile several bits of code separately and then change the bit that needs to be updated..

Would it make sense to make a program in java or whatever language and use C++ only for computation or whatever parts C++ is faster in? Can communication b/w languages be fast enough?

[helios]

To clarify, my answer "no, that's not how executables work" was in response to your question about whether compilers bundle interpreters into their output. It's possible to develop a program (P) that accepts a source file as input and produces as output an executable file containing an interpreter, and that source as a resource, and that when the file is executed the interpreter interprets the source. In other words,

void interpret(const char *);

const char *source = "print \"Hello, World!\n\"\n";

int main(){
    interpret(source);
}

Personally, I would not consider such a program (P) a compiler, but others may have different opinions.

When big companies make video games with Python (let's say), and use some C++ for parts and another language for parts of the game.. How do they link all of these bits?

The Python library contains interfaces for a host program to interoperate with a guest script.

They can't have .py files in their game resource folder because users can edit it right.. So how do they store their python files or do they compile python? Do they make their own encrypted file extension that only their interpreter can read? Or the code and interpreter are inside the executable itself.

There's no single answer to your question. One developer might choose one solution and another might choose another. It depends on what their priorities are. Suffice it to say that all of those are possible solutions (although note that you can't really encrypt the scripts, since the computer needs to be able to execute them at some point. At best you can make it more difficult to find the scripts).

If you could just store any file in .exe why wouldn't you just store everything?

There are many valid reasons.
* You might want to actually support modding.
* If you support updates, the update procedure for a single monolithic file is much more complex, and you can't update only bits at a time. It's all or nothing.
* Your build procedure becomes more difficult if you have to produce a single file. For one, the amount of parallelism you can add to your build process is inherently limited because that one file has to be written in a specific order.
And so on. Ultimately, having just one file doesn't really solve any problems.

Do they store their code outside the executable? How do they store it?

Yes, as scripts or as dynamic libraries. For example, the game could unload the audio library, update it, and then reload it.

but since C++ is faster, wouldn't it pay to compile several bits of code separately and then change the bit that needs to be updated.

But then your code would have to stay very loosely coupled, because different bits may change independently. Open your task manager now. Imagine if every process that's currently running on your computer was instead each running on a separate computer and they were all communicating through a network. Do you think such a system would be faster or slower than your current system?

C++ may be faster, but that doesn't mean that it matters. For example if you have an AI routine that has to run once per second and the Python implementation finishes in 1 millisecond, what would be the point of rewriting it in C++ so it takes 100 microseconds?

Would it make sense to make a program in java or whatever language and use C++ only for computation or whatever parts C++ is faster in?

Usually Java is fast enough that this is not necessary, but yes, this does make sense sometimes.

Can communication b/w languages be fast enough?

Passing data accross a foreign function interface (FFI) is generally slow and best to a minimum. You can still do what I said in the previous paragraph, you just have to be a little careful in how you design the interface.