Python Speed Question and Opinion

[Maboroshi]

Hi I am fairly new to programming but not as such that I am a total beginner

From what I understand C and C++ are faster languages than Python. Is this
because of Pythons ability to operate on almost any operating system? Or is
there many other reasons why?
I understand there is ansi/iso C and C++ and that ANSI/ISO Code will work on
any system

If this is the reason why, than why don't developers create specific Python
Distrubutions for there operating system.

Please don't take this the wrong way I am totally one for standards. I am
just looking at these forums and there is a lot of stuff about Python and it
inability to match C or C++

Also from what I understand there are Interpreted and Compiled languages
with Interpreted languages memory is used at runtime and Compiled languages
the program is stored in memory.

Or is this wrong?

Python is an Interpreted Language, am I right? than wouldn't it be possible
if there was OS specific Python distrubutions, that you could make Python a
Compiled language

Or is this completely wrong?

Thanks if you answer my questions

Bye For Now

 

[Peter Hansen]

Hi I am fairly new to programming but not as such that I am a total beginner

Total beginners sometimes don't realize that questions such as yours
have been asked repeatedly, many times, in the past. Searching Google
Groups (http://groups.google.com) for such discussions in this newsgroup
will save yourself and others much time rehashing the argument all
over again. (And it does generally become an argument, after the
initial factual responses.

From what I understand C and C++ are faster languages than Python. Is this
because of Pythons ability to operate on almost any operating system?

True, they are often faster, but not always. The reason is simply that
Python (at least, the C implementation of Python) is an interpreted
language, whereas C/C++ are compiled to native machine code.

Please don't take this the wrong way I am totally one for standards. I am
just looking at these forums and there is a lot of stuff about Python and it
inability to match C or C++

Some people are inappropriately obsessed with speed and think that just
because C can provide better performance for certain types of problem,
it must therefore be a better language for all purposes. Other people
think that speed of *development* is far more important, and choose
Python even for those applications where it is slower. Often, perhaps
surprisingly, they find it can run at quite acceptable speeds, and
in some cases even faster than what they could get from C with a
similar amount of development time invested.

Also from what I understand there are Interpreted and Compiled languages
with Interpreted languages memory is used at runtime and Compiled languages
the program is stored in memory.

Or is this wrong?

I can't say if it's wrong because it's very befuddled.... doesn't
mean anything to me. With both types of languages the program is
"stored in memory" and with both types "memory is used at runtime".

Stop worrying about performance and interpreted vs. compiled.
Try Python, use it for more and more stuff if you like it, less
stuff or nothing at all if you don't, and focus on writing good
quality code, not the fastest code you can write...

-Peter

 

[Mark J. Nenadov]

Hi I am fairly new to programming but not as such that I am a total beginner

From what I understand C and C++ are faster languages than Python. Is this
because of Pythons ability to operate on almost any operating system? Or is
there many other reasons why?
I understand there is ansi/iso C and C++ and that ANSI/ISO Code will work on
any system

If this is the reason why, than why don't developers create specific Python
Distrubutions for there operating system.

Please don't take this the wrong way I am totally one for standards. I am
just looking at these forums and there is a lot of stuff about Python and it
inability to match C or C++

Also from what I understand there are Interpreted and Compiled languages
with Interpreted languages memory is used at runtime and Compiled languages
the program is stored in memory.

Or is this wrong?

Python is an Interpreted Language, am I right? than wouldn't it be possible
if there was OS specific Python distrubutions, that you could make Python a
Compiled language

Or is this completely wrong?

Thanks if you answer my questions

Bye For Now

Generally speaking, you will find C and C++ to be the fastest languages.
Implementations of C/C++ are generally much faster than anything else
(whether it be Python, Java, Perl, etc.) I don't think the speed
difference is because of portability. Python is interpreted, but not
completely. It deals with compiled byte-code in a way *roughly* similar to
Java.

Personally, I think people often get bent out of shape about speed for no
good reason. I'm not saying speed does not matter, it matters very much in
SOME situations. But people will discard a language just because it
performs a benchmark in 0.005 seconds, whereas C can do it in 0.00002
seconds. To me that is unintelligent. You need to evaluate a language
implementation in all categories, not just bench-marked runtime speed

Scenario A: A person chose to do a project in pure C because C is faster.
However, they didn't have a good understand of C, and as a result their
algorithm implementations were sloppy.

Scenario B: A person chose Python for a project. They realized the Python
implementation may be slower than the C implementation, but since their
algorithm implementations were much clearer in a high-level language, they
ended up having an easier time optimizing and actually ended up with
better performance results.

While speed is important and C implementations will usually be faster, we
need to remember that there are many other factors to consider. In my
opinion, things like programmer productivity and simplicity of
implementation are usually more valuable than raw runtime performance. I
think that there are not many languages that can match Python in terms of
programmer productivity and simplicity.

 

[Maboroshi]

Hello Peter Hansen

Total beginners sometimes don't realize that questions such as yours

have been asked repeatedly, many times, in the past. Searching Google
Groups (http://groups.google.com) for such discussions in this newsgroup
will save yourself and others much time rehashing the argument all
over again. (And it does generally become an argument, after the
initial factual responses.

Sorry I have a bad habit of not searching google first I will have to
remember to do that before my next post

Try Python, use it for more and more stuff if you like it, less
stuff or nothing at all if you don't, and focus on writing good
quality code, not the fastest code you can write...

In my opinion Python is the best language there is and I love it. The
reason for me asking these questions was because I saw a lot of people
trying to compare python to C and I had to find out what the big deal was
and why C would be a faster language - I like to know how things work -

Stop worrying about performance and interpreted vs. compiled.

I will definitley take your advice on this - But to be honest I was never
really concerned or worried about speed - I just love python

 

[Irmen de Jong]

Maboroshi wrote:

In my opinion Python is the best language there is and I love it. The
reason for me asking these questions was because I saw a lot of people
trying to compare python to C and I had to find out what the big deal was
and why C would be a faster language - I like to know how things work -

I have taken the liberty of taking a few of the comments made
in this thread and writing them down here:
http://www.razorvine.net/python/PythonSpeed
I've added a few other things related to Python's performance,
such as a short reference to Psyco.


--Irmen de Jong.

 

[djw]

Maboroshi wrote:





I have taken the liberty of taking a few of the comments made
in this thread and writing them down here:
http://www.razorvine.net/python/PythonSpeed
I've added a few other things related to Python's performance,
such as a short reference to Psyco.


--Irmen de Jong.

I don't think I agree with your statement at the bottom that says "if
all else fails, try Psyco." Since using Psyco is so effortless and may
produce dramatic speedups, I would recommend to people that they try it
before resorting to writing extension modules in C/C++. Sending people
that are new to Python down the extension writing path may turn them off
to Python altogether.

-Don

 

[Irmen de Jong]

I don't think I agree with your statement at the bottom that says "if
all else fails, try Psyco." Since using Psyco is so effortless and may
produce dramatic speedups, I would recommend to people that they try it
before resorting to writing extension modules in C/C++. Sending people
that are new to Python down the extension writing path may turn them off
to Python altogether.

I think you're right. So I changed the order a bit and removed the
"if all else fails"

Feel free to add other suggestions to the page. It's a WIKI page after all.

--Irmen

 

[Donald 'Paddy' McCarthy]

I think you're right. So I changed the order a bit and removed the
"if all else fails"

Feel free to add other suggestions to the page. It's a WIKI page after all.

--Irmen

Hi I read the page and think you have missed out a critical point: it is
not the absolute speed that is important, you should think about what us
an acceptable speed of execution. Optimisations beyond achieving this
acceptable speed are wasteful of resources (your time).

Could we think of "speed" as being a coordinate system of (td,tr,tm)
where:
td is the development time
tr is the time to run the developed program
tm is the time to maintain/modify/debug-once-released the program.

Then, comparing C/C++ with Python (spot the generalisations folks)
td(C) is much greater than td(python)
tr(C) is much less than tr(python)
tm(C) is much greater than tm(python)

Cheers, Pad.

 

[Maboroshi]

Interesting Thank You

Maboroshi wrote:




I have taken the liberty of taking a few of the comments made
in this thread and writing them down here:
http://www.razorvine.net/python/PythonSpeed
I've added a few other things related to Python's performance,
such as a short reference to Psyco.


--Irmen de Jong.

 

[Irmen de Jong]

Hi I read the page and think you have missed out a critical point: it is
not the absolute speed that is important, you should think about what us
an acceptable speed of execution. Optimisations beyond achieving this
acceptable speed are wasteful of resources (your time).

I copied this on the page, thanks for pointing it out.

Could we think of "speed" as being a coordinate system of (td,tr,tm)
where:

[...]

Perhaps. But I doubt it would clarify things

--Irmen

 

[Lothar Scholz]

I don't think I agree with your statement at the bottom that says "if
all else fails, try Psyco." Since using Psyco is so effortless and may
produce dramatic speedups, I would recommend to people that they try it
before resorting to writing extension modules in C/C++. Sending people

But Psyco can consume really huge amounts of memory.

 

[Michele Simionato]

Generally speaking, you will find C and C++ to be the fastest languages.
Implementations of C/C++ are generally much faster than anything else

except Fortran. People keep forgetting about the oldest languages, but they
are still the best for the purposes they were invented for.


M. Simionato

 

[beliavsky]

except Fortran. People keep forgetting about the oldest languages, but they
are still the best for the purposes they were invented for.

Thanks, Michele. I was debating whether to write the same thing .
Although Fortran is the oldest language still in widespread use, it is
continuing to be updated, with Fortran 2003 supporting OOP and
interoperability with C, among other features.

A relatively recent speed comparison by Scott Robert Ladd at
http://www.coyotegulch.com/reviews/almabench.html of Fortran and C++
on Linux ia32, using the Intel Fortran and C++ compilers, found the
speeds to be very close. Gcc was often twice as slow.

If one has numerical code in Python using Numeric or Numarray, and one
needs to speed up the code, translating to Fortran 95 may be a good
alternative to C++. The multidimensional array of C is low-level and
is not comparable to the Numeric array. There are several templated
array classes in C++ with more functionality (allowing whole-array
operations, for example), but I do not know of any with general array
slices (corrections requested). Since Fortran 90, Fortran arrays have
had both array operations and slices.

 

[Jacek Generowicz]

Hi I am fairly new to programming but not as such that I am a total beginner

From what I understand C and C++ are faster languages than Python.

Languages cannot be fast or slow. Their implementations, however,
differ in the speed with which they execute algorithims expressed in
those languages.

It is true that, today, most C++ implementations will tend to execute
a C++ implementation of some algorithm more quickly that Python
implementations execute a Python rendition of the same algorithm.

It is true that, today, if speed of execution of the final product is
the only factor you take into account when assessing the "speed" of a
language[1], then C and C++ will appear to be "faster" than Python.

Also from what I understand there are Interpreted and Compiled
languages

Languages are a means of expressing information. Whether or not they
are compiled and interpreted, depends on what one choses to do with
them.

There are computer programs which interpret some computer programming
languages[2]; these are called interpreters.

There are computer programs which translate some computer programming
languages into other computer programming languages; these are called
compilers.

There are computer programs which do a mixture of interpreting and
translating; these are sometimes called partial evaluators.

If it were to mean anything to say that a given language is compiled,
then I propose that it would mean that a compiler for that language
exists. An interpreted language would therefore be one for which an
interpreter exists.

Given those working definitions of "interpreted language" and
"compiled language", your statement seems correct: there are languages
which are both interpreted and compiled[3]. An example of such a
language is Common Lisp; most implementations of Common Lisp systems
include both an interpreter and a compiler for Common Lisp.

C++ is an interpreted language:

http://root.cern.ch/root/Cint.html

C++ is, of course, also a compiled language:

http://gcc.gnu.org/

so, C++ is another example of an "Interpreted and Compiled language",
lending further support to your sattement.

Python is an Interpreted Language, am I right?

Python is most certainly a compiled language. Python source code is
first compiled into Python bytecode. Python bytecode is usually
interpreted.

You should also note, that the languages that one typically talks
about as "fast" and "compiled" languages, are compiled to an
_interpreted_ language: machine language. The interpreter which
interprets the latter is implemented in the hardware itself.

Please think about that last point, if you are ever tempted to suggest
that interpreters, or the languages that they interpret are slow.

Or is this completely wrong?

I'll let you draw your own conclusions.


In case I made my point too subtly:

Try to avoid pigeonholing languages. Trying to find out how to use
each to your best advantage, is far more productive.

Don't put too much faith in common wisdom.

Try not to get in the habit of throwing mere words around.
Understand the concepts which are represented by the words
you use, in the context in which you use them.

Expressing yourself precisely and accurately is important in
computer programming, and not only in computer programming.


HTH,



[1] Thereby overlooking two factors which, in real-world programs, are
often at least as important, and sometimes much more important:
speed of development, and speed of maintenance.

[2] I really should be saying "... interpret programs written in some
computer programming languages ...", but these sentences are
convoluted enough as it is.

[3] I am deliberately interpreting the original, ambiguous, statement
in a way in which it was not intended to be understood.

 

[Terry Reedy]

Given those working definitions of "interpreted language" and
"compiled language", your statement seems correct: there are languages
which are both interpreted and compiled[3]. An example of such a
language is Common Lisp; most implementations of Common Lisp systems
include both an interpreter and a compiler for Common Lisp.

So is C. At least some unix distributions once had a C *interpreter* for
tutorial purposes.

TJR

 

[Peter Hickman]

Hi I am fairly new to programming but not as such that I am a total beginner

From what I understand C and C++ are faster languages than Python. Is this
because of Pythons ability to operate on almost any operating system? Or is
there many other reasons why?

Although code written in C and C++ may run faster that is rarely the main issue,
you can *write* the code a lot faster in python and have much smaller source
files than in C / C++. Maintaining code written in python is also much easier as
it is generally smaller and clearer. So updating and extending is easier than in
C / C++.

However with pyhon if part of the code is too slow then you can look at coding
just that part in C / C++. A very usfull feature should you need it.

I understand there is ansi/iso C and C++ and that ANSI/ISO Code will work on
any system

This is not always the case, they should be portable but in some cases it just
doesn't work that way.

Also from what I understand there are Interpreted and Compiled languages
with Interpreted languages memory is used at runtime and Compiled languages
the program is stored in memory.

Or is this wrong?

There are very few 'pure' interpreted languages. Most modern interpreted
languages compile down to bytecode that is then run on a virtual machine. This
allows for optimisations based on runtime usage ('hotspot' and 'jit' are
keywords in this area) which can significantly reduce the performance gap. Tools
like psyco are available.

Python is an Interpreted Language, am I right? than wouldn't it be possible
if there was OS specific Python distrubutions, that you could make Python a
Compiled language

Or is this completely wrong?

The python executable (python.exe or whatever) is a compiled from C program. The
programs that it runs are interpreted (actually compiled into bytecode and run
on a vm).

If you want pure speed you need assembler! No ifs, ands or buts.

 

[Jacek Generowicz]

Given those working definitions of "interpreted language" and
"compiled language", your statement seems correct: there are languages
which are both interpreted and compiled[3]. An example of such a
language is Common Lisp; most implementations of Common Lisp systems
include both an interpreter and a compiler for Common Lisp.

So is C. At least some unix distributions once had a C *interpreter* for
tutorial purposes.

Yes, this very point was made (or at least one very similar to it),
just after the text you quoted ...

 

[Jacek Generowicz]

There are very few 'pure' interpreted languages.

Well, every native machine language is purely interpreted, for a
start.

If you want pure speed you need assembler! No ifs, ands or buts.

Lots of "if"s and "but"s actually. While it is theoretically possible
to write any program you want, in some assembly language, and to write
it in a way which overcomes some low-level inefficiencies introduced
by higher-level languages, in practice you won't find many people
writing efficent large-scale programs in assembler. Higher-level, more
expressive, languages allow you to try out different approaches more
easily. Getting the architecture of your program right, is far more
important for overall speed of execution that the low-level details
are.

 

[Peter Hickman]

Lots of "if"s and "but"s actually. While it is theoretically possible
to write any program you want, in some assembly language, and to write
it in a way which overcomes some low-level inefficiencies introduced
by higher-level languages, in practice you won't find many people
writing efficent large-scale programs in assembler. Higher-level, more
expressive, languages allow you to try out different approaches more
easily. Getting the architecture of your program right, is far more
important for overall speed of execution that the low-level details
are.

You are correct, it is just that if all you are concerned about is speed then
assembler is what you need. However when you put this to people you find out
that what they really want is 'easy to write fast programs'. Assembler comes
with many hurdles but you are not going to get any faster using a higher level
language.

It's just like marathon running, first they say they want to win but when they
see the training plan they settle for 'a respectable position'.

No one that has ever said to me that all they are concerned about is speed has
actually gone for assembler, they tend to start eulogizing 'rapid development',
'ease of debugging' and other claptrap.

Wimps.

 

[Peter Hansen]

You are correct, it is just that if all you are concerned about is speed
then assembler is what you need.

Jacek already made this point, but I'll make it again. Assembler
is sometimes *not* the way to write the fastest code. (Though
sometimes it is.) Optimizing compilers for some languages such as
C can actually produce *faster* code by choosing combinations of
opcodes and side-effects that even an assembly programmer would be
nuts to use in most cases, largely because it would make the code
even more obscure than it already is but also because they might not
even think of it.

A simplistic example (and one which many x86 programmers learned
about and started using, but probably did not initially) is how
to clear a register. The chip provided a CLR instruction, but it
actually took (originally, maybe not now) longer to execute than
if one would XOR the register with itself and thus clear it.
There are many other and more complicated examples which compiler
optimizers can use but which are too hard to keep track of for
most assembly writers.

-Peter