LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Programming (https://www.linuxquestions.org/questions/programming-9/)
-   -   are inter preted programs slower and is python interpreted (https://www.linuxquestions.org/questions/programming-9/are-inter-preted-programs-slower-and-is-python-interpreted-465856/)

amolgupta 07-20-2006 06:16 AM

are inter preted programs slower and is python interpreted
 
are interpreted programs slower and is python interpreted
or let me put it this way is python application slower than other compled languages
bcos i feel yum is slower than apt

Stephen Wilson 07-20-2006 08:08 AM

Python is interpreted and as such will run slower than a compiled source.

bigearsbilly 07-20-2006 08:48 AM

sort of by definition but not neccecelery in practice.

It depends on lots of things, how well programmed it is for a start.

I have found (with perl) that it will run as near as dammit as fast as C.
In fact, I found C was faster only when I didn't put safety checks in on
file reads and what not, which perl has automatically.

jlliagre 07-20-2006 09:21 AM

You can't beat assembly language when the unique metric is speed.

However, ease of development, portability, readability, maintainability, debuggability, developer skills are other elements that usually balance the choice toward other languages, like C, C++, Java, PHP, Python and the likes.

amolgupta 07-20-2006 10:46 AM

thanx alot

jayemef 07-20-2006 11:32 AM

Quote:

Originally Posted by amolgupta
bcos i feel yum is slower than apt

This has more to do with repositories and the differences between how yum and apt work than any differences in language.

osor 07-20-2006 12:42 PM

Quote:

Originally Posted by jlliagre
You can't beat assembly language when the unique metric is speed.

Nowadays, its really hard to make assembly programs that outperform the optimized assembly generated by a compiler. You'd have to memorize many processor-specific instructions and know which of many options to chose from.

You could always hand-tweak a compiler-generated assembly file ;).

Randux 07-20-2006 01:29 PM

Quote:

Originally Posted by osor
Nowadays, its really hard to make assembly programs that outperform the optimized assembly generated by a compiler.

I've seen people make this statement in a few places, but I find it difficult to believe. I'd like to know on what basis it's being said and with respect to exactly which compilers/assemblers/platforms. Could it be that people are just repeating what they've read? Or does someone have personal knowledge of this?

Quote:

Originally Posted by osor
You'd have to memorize many processor-specific instructions and know which of many options to chose from.

So do the guys writing the compilers. At the end of the day, a person is still "writing the assembler code" because a person (or people) wrote the compiler.

And so do good assembler programmers. They read the processor manuals continually, learn their hardware, and test to see what works best.

If, on the other hand we're comparing the output of a good optimizing compiler to the output of a mediocre assembler programmer, the outcome shouldn't surprise anybody.

Quote:

Originally Posted by osor
You could always hand-tweak a compiler-generated assembly file ;).

This sounds like mostly a waste of time unless you have a very good optimizing compiler for a very high level language doing some very specialized types of things for which the team who wrote the compiler knows better and more effective algorithms than the "human" competitor. But this is certainly a possible scenario.

alred 07-21-2006 08:50 AM

any language and api are there for a purpose , i think the slowness or the "intensity" of any things are not that important ... they usually serve the long-term purpose well enough ... its silly enough for a windows user to ask for a complete set of commandline flexibilities while linux is able to have complete set of both worlds , sometimes i would like to think that stuffs like these are really actually build for the linux world ...


:twocents:

.

urzumph 07-22-2006 12:20 AM

In the most literal sense, compiled code is faster than interpreted code (or byte code compiled code, like java), however, there are many other factors which affect the execution speed - Hard disk usage, communication with external hardware (eg, via serial cable) and network communication. On most programs, except perhaps for some very computation heavy projects (eg, scientific research, brute force algorithms, etc) are going to spend more time waiting for the HDD or network than waiting for the CPU to work.

KimVette 07-22-2006 03:38 AM

Compilers generate assembly? Wow, this is a new one. I was under the impression that one wrote code in assembly (which is human readable) and then it was compiled into machine language. Sorry, I just had to pick that nit! :)

Seriously though - more than anything else it's the architecture and implementation that will affect performance. You can write really sloppy assembly and clean C, and the C can vastly outperform the sloppy assembly routine. YMMV, batteries not included, etc.

spooon 07-22-2006 04:27 AM

Quote:

Originally Posted by KimVette
Compilers generate assembly? Wow, this is a new one.

Yes they do (see gcc -S); in fact that's what's properly called compilation.
Quote:

Originally Posted by KimVette
I was under the impression that one wrote code in assembly (which is human readable) and then it was compiled into machine language.

That's called the assembler.

blackhole54 07-22-2006 05:45 AM

Quote:

Originally Posted by KimVette
Compilers generate assembly? Wow, this is a new one. I was under the impression that one wrote code in assembly (which is human readable) and then it was compiled into machine language.

That's strange. I was under the impression that coders wrote code in assembly language, a higher level language, or a scripting language. (Or under extreme circumstances or with a very deranged coder, directly in machine language!) Assemblers then assembled, script interpreters then interpreted, and compilers compiled, either to assembly language or directly to machine language (making allowance for relocatable modules where not everything has been resolved yet) depending on the compiler (ah, Motorola MPL, we barely knew ya) or possibly options.

(Ah, this "philosiphising" is a nice break from cold hard technical problems!;) )

xhi 07-22-2006 09:17 AM

what is this assembly code you speak of.. is that something like visual basic?

jlliagre 07-22-2006 09:31 AM

Quote:

Originally Posted by xhi
what is this assembly code you speak of.. is that something like visual basic?

Vaguely, both are a more or less unreadable suite of instructions ...

jlliagre 07-22-2006 09:37 AM

Back to the subject, it can easily be proved than you cannot write a program in an higher level language that will outperform its assembly language competitor, assuming the development effort is not an issue.

Of course this is meaningless, as the development effort is always an issue.

Consequently assembly language is today a very specialized domain, largely because of the C language flexibility.

michaelk 07-22-2006 10:02 AM

To sum up what everyone has posted.

Assembly language is the human readable notation for CPU instructions and machine language basicaly is the assembly language converted to numeric form. The assembler is the program that converts the human notation into machine language. And yes it is the function of the compiler to convert a high level language into assembly language, from assembly to machine code and then linking which is the process of creating an executable program.


http://en.wikipedia.org/wiki/Assembly_language

xhi 07-22-2006 10:38 AM

Quote:

Originally Posted by jlliagre
Vaguely, both are a more or less unreadable suite of instructions ...

:D

i cant claim that assembly is easier for me to read, but it is definately preferred..

and to throw in something worthwhile.. i have several books on assembly, and most of the authors seem to suggest that tweaking compiler generated code will get you more performance if you know where to look in the code and know what you are doing.

however, in practical use, you still have a bottleneck of file access, network useage, and printing to console/gui to contend with. you have to look at the efficiency of your efficiency efforts..


All times are GMT -5. The time now is 06:35 AM.