• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Junilu Lacar
  • Martin Vashko
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Scott Selikoff
  • salvin francis
  • Piet Souris

Performance of Compiled languages

 
Greenhorn
Posts: 22
Python Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey Guys,

Why are Compiled languages like C and C++ have much performance than an interpreted language like Python?

And is that the only reason that Operating system and driver software are written only using compiled language. Are they other good reasons to chose compiled language over interpreted especially for operating system?

Cheers,
Ashish.
 
Marshal
Posts: 66635
251
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Java® is an interpreted language and its performance is just as fast as C/C++.
In many cases there is a compilation process which has to be carried out before the code is run; in a compiled language, it is only necessary to do that once, but interpreted languages may require hat process for every run of the program.
It may be necessary to access memory locations directly to write an OS, which C/C++ is good for.
 
Saloon Keeper
Posts: 10875
235
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't think it's correct to say "Java is an interpreted language", and it's definitely not the whole story.

Java is compiled in two phases. When you run the Java compiler, it gets compiled to Java byte-code. This is a greatly simplified language that runs in a stack machine. It already looks a lot like native machine code, except it has some special operations that can only be further compiled when the type of processor is known, i.e. at runtime.

The second phase is done by the JVM and is called Just-In-Time compiling (JIT). Parts of the byte-code that get executed a lot will get compiled to machine code, so that the translation doesn't have to be done every time the byte-code is executed.

A fully interpreted language translates a piece of code every time it is executed. As Campbell said, because this translation happens every time the code is executed (for instance, a statement inside a loop), it makes the total runtime much longer.

The benefit of interpreting code is that you can execute it without compilation and immediately see what it does before you write the final version.
 
Campbell Ritchie
Marshal
Posts: 66635
251
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Unlike C/C++ which have to be compiled into machine code, Java® produces bytecode which is interpreted by the virtual machine, which is why Java® has the status of an interpreted language. It doesn't require repeated compilation however unlike Basic or Python, so there is interpreted and there is interpreted. If you only count languages as interpreted if the whole codebase has to be interpreted rather than an intermediate representation, then Java® is a different kind of language. I believe C# works similarly.
 
Stephan van Hulst
Saloon Keeper
Posts: 10875
235
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:Java® has the status of an interpreted language.


Do you have any sources that state Java is an interpreted language? I know this was true in the old days, but who says that now?
 
Campbell Ritchie
Marshal
Posts: 66635
251
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It was one of the original plans for Java®, as you hinted. Maybe that has changed in its twenty‑year lifetime. You are right; I can't find any recent references to Java® being interpreted. Wikipedia even says this:-

The terms interpreted language and compiled language are not well defined because, in theory, any programming language can be either interpreted or compiled.

 
Saloon Keeper
Posts: 5917
152
Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:

Campbell Ritchie wrote:Java® has the status of an interpreted language.


Do you have any sources that state Java is an interpreted language? I know this was true in the old days, but who says that now?


Indeed it's not, or at least not entirely. While the Hotspot JVM (which has been the default JVM for many years) sometimes chooses not to compile bytecode, it generally does. https://www.oracle.com/technetwork/java/javase/tech/index-jsp-136373.html says

The Java HotSpot Virtual Machine is a core component of the Java SE platform. ... It includes dynamic compilers that adaptively compile Java bytecodes into optimized machine instructions

 
Saloon Keeper
Posts: 21312
140
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Back in simpler times, the general rule was that an interpreted language (like BASIC) would run about 10 times slower than a compiled language such as COBOL. A compiled language would be converted straight to executable machine code and all you'd need to do to run it would be to load it into memory and call its main() function - whatever it might be named. Actually in Unix, C would often be converted to assembly, which would then run through the assembler to get executable machine code, but the same net effect, just extra steps.

BASIC source code, on the other hand, was converted into machine-readable tokens, generally at the point where you typed them in. It's worth noting that back then compilers generally ran as a batch process, taking something like a deck of punched cards and producing (at least temporarily) a disk or tape file (but occasionally an output punched card deck). Interpreted languages, though, were often entered and edited interactively via some sort of typewriter device.

So when it came time to run an interpreted program, you had all those tokenized lines of code which required an interpreter to read and execute, token by token. The interpreter and editor were commonly the same program.

Originally, most compilers were pretty stupid themselves, and the machine code they produced wasn't all that efficient. But since it was produced for the purpose and in consideration of all lines of code at once (more or less), it was still faster than an interpreter which, for the most part, effectively treated each line of code as a separate program and didn't take any other executable lines into account.

Time passed. Compilers started optimizing. New interpreter technologies were explored, such as the Threaded Interpretive Language (TIL) architecture used by the FORTH progamming language (we've discussed FORTH recently elsewhere on the Ranch). Bytecodes replaced tokens - an early adopter of bytecodes was the Smalltalk language.

When Java was created back in the early 1990s, they found bytecodes to be an ideal way of creating a portable semi-compiled environment. It was relatively easy to set up a bytecode interpreter on a new machine, compared to realizing an entire compiler stack, and since bytecode modules are processed as a unit (that is, as a batch process) instead of line-by-line like BASIC, and that means that optimization could be done between lines, not just within a line. So it was slow compared to native code, but still a little faster than traditional interpretation.

Come the New Millenium, though, and various JVM implementers came up with Just-in-Time (JIT) compiling. With JIT, you put the backend of the compiler in the JVM. That is, the original lexical tasks have already been done by javac, and only the task of generating executable code from bytecodes remains.  JIT, as its name implies, doesn't actually produce machine code until it needs it. In JVMs, in fact, it had the option to simply interpret the bytecodes directly and never actually product machine code, or to compile to native code, based on JVM settings and code usage.

Which brings up a point. The original interpreters simply edited, tokenized and executed token code. Post-millenial JVMs actually contain a LOT of self-analysis. As I said, they can decide what's worth compiling to native and what isn't, as well as make many other choices based on their observation of how things are going. In fact, one feature of JIT is that by monitoring code execution, they can actually re-optimize code on the fly.

For example, back when CPUs were simpler, a two-way branch instruction (if x then goto Y) might have two different timing values. If the branch was not taken (not-x), then it might take 1 millisecond to execute. BUT, if the branch was taken, it might take 1.5 milliseconds. Modern JVMs can do things like look at passes over such code statistically, decide that the branch case was the more common case, and then re-write the code to flip the branch to make the jump the exception instead of the rule. As a result, a JVM can, in some cases actually out-perform statically-compiled languages like C.

Of course, this comes with a price. The JVM is a big heavy machine, in order to have all these functions, and it works best on large code samples where it has more statistics it can gather. So let's look at Python.

Python started out as an interpreted language. Even today, it's not uncommon to see examples in python where they open up an interactive python command window. But in production it's often used for batch processes - for example, the Anaconda subsystem that auto-configures hardware in the Red Hat and Fedora Linux boot processes. Batch processes, of course, lend themselves to global code optimization. So it's no surprise that running Python on a ".py" source file can produce a ".pyc" file. As in Python Compiled. A PYC isn't an actual native OS executable. It can't be because it has to be able to interact with non-compiled services, but it's still much more efficient than operating on simple tokes or (shudder) raw source code every time you run it.

So, as you can see, the lines have gotten pretty blurry, and this is just at the language levels. CPU technology has long since passed the point where you can just sit down with an adding machine and a chart and compute timings by looking at source instructions individually. So now more than ever, if you want to know performance, you need to measure it in real-world environments.

And, of course, remember. Hardware is now much cheaper than people. Efficiency for efficiency's sake is good for Geek Points, but doesn't impress people who write paychecks. If a "less efficient" language makes you a more efficient person, that's what they count. Alas, not always correctly, since there's more than one way for people to be efficient, and some of them are less true efficiency than they are in kicking the inefficiencies temporarily out of sight.
 
Shaik Ashish
Greenhorn
Posts: 22
Python Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks guys, got some insight into it
 
this is supposed to be a surprise, but it smells like a tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!