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]

Maboroshi wrote:

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]

On Fri, 04 Jun 2004 17:14:44 -0700, Maboroshi wrote:

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.

--
Mark J. Nenadov
Python Byte Solutions
http://www.pythonbyte.com

[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]

Irmen de Jong wrote:

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.

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]

djw wrote:

http://www.razorvine.net/python/PythonSpeed

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]

Irmen de Jong wrote:

djw wrote:

http://www.razorvine.net/python/PythonSpeed

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

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
"Irmen de Jong" <[e-mail]> wrote in message
news:40*********************@news.xs4all.nl...

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.

[Irmen de Jong]

Donald 'Paddy' McCarthy wrote:

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]

djw <dw******@comcast.net> wrote in message news:<iFmwc.46547$3x.9329@attbi_s54>...

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]

"Mark J. Nenadov" <ma**@freelance-developer.com> wrote in message news:<pa****************************@freelance-developer.com>...

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]

mi***************@poste.it (Michele Simionato) wrote in message news:<95*************************@posting.google.c om>...

"Mark J. Nenadov" <ma**@freelance-developer.com> wrote in message news:<pa****************************@freelance-developer.com>...

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.

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]

"Maboroshi" <n/a> writes:

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]

Maboroshi wrote:

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]

"Terry Reedy" <tj*****@udel.edu> writes:

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]

Peter Hickman <pe***@semantico.com> writes:

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]

Jacek Generowicz wrote:

Peter Hickman <pe***@semantico.com> writes:

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.

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]

Peter Hickman wrote:

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

[Jacek Generowicz]

Peter Hickman <pe***@semantico.com> writes:

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.

You're forgetting other claptrap, such as "correctenss of
program". All irrelevant twaddle, I completely agree.

I see that Peter Hansen has neatly re-iterated my original point
(which you appear to have missed), so I won't address that.
[Warning to the reader: The above message was brought to you with a
higher level of irony than you may be used to.]

[Paramjit Oberoi]

> 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.

Very true, and I would replace the "sometimes not the way to write the
fastest code" with "almost never...". Especially when optimizing code for
a modern processor, a compiler will be much better at reordering
instructions so that they pass through the execution pipeline more
smoothly.

If you are writing a critical 20-instruction inner loop and are willing to
spend hours, if not days, experimenting with different instruction
sequences, you may be able to get slightly better performance than the
code generated by the compiler; but in most other cases it's best to leave
it to the compiler.

-param

[beliavsky]

Peter Hickman <pe***@semantico.com> wrote in message news:<40**********************@news.easynet.co.uk> ...

<snip>

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.

Do you have experience to back up your claims?

I have not written assembler, but sources I respect tell me that good
C++ and Fortran (especially Fortran 95 with its array operations)
compilers DO let you write programs in a high-level language that are
more efficient than the hand-coded assembly you might produce (taking
infinitely longer to write).

Given an infinite amount of programming time, very few programmers are
going to write assembly code that outperforms LAPACK (in Fortran) for
linear algrebra or FFTW (in C) for Fourier transforms.

Your point that Python is a productive language despite its slower
execution speed is valid, but don't pretend that the natural
alternative is assembly language.

[David M. Cooke]

At some point, be*******@aol.com wrote:

Peter Hickman <pe***@semantico.com> wrote in message news:<40**********************@news.easynet.co.uk> ...

<snip>

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.

Do you have experience to back up your claims?

I have not written assembler, but sources I respect tell me that good
C++ and Fortran (especially Fortran 95 with its array operations)
compilers DO let you write programs in a high-level language that are
more efficient than the hand-coded assembly you might produce (taking
infinitely longer to write).

Given an infinite amount of programming time, very few programmers are
going to write assembly code that outperforms LAPACK (in Fortran) for
linear algrebra or FFTW (in C) for Fourier transforms.

Those are interesting examples: FFTW actually uses routines coded in
assembly language, and ATLAS (a common implmentation of BLAS, which
underlies LAPACK), also uses assembly language.

The difference is the code is generated by a program: basically, the
authors have made custom compilers to determine the best combination
for the architecture. In the case of ATLAS, benchmarks can be run to
determine which combinations of parameters are the best for a
particular machine (taking into account cache size, for instance).

Some routines *are* hand-written assembly, but they're small enough,
and used enough that someone sat down and thought about it long and
hard.

--
|>|\/|<
/--------------------------------------------------------------------------\
|David M. Cooke
|cookedm(at)physics(dot)mcmaster(dot)ca

[A. Lloyd Flanagan]

Irmen de Jong <[e-mail]> wrote in message news:<40*********************@news.xs4all.nl>...

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.

Nice page. May I suggest you link into the "official" python wiki at
http://www.python.org/cgi-bin/moinmoin/? I'd like to see a lot more
contribution to that one.

[Jacek Generowicz]

co**********@physics.mcmaster.ca (David M. Cooke) writes:

Those are interesting examples: FFTW actually uses routines coded in
assembly language,

Just to expand on FFTW, as it is a very good example (which I was
tempeted to mention in my initial message). FFTW is based around
"codelets" written in C. But the codelets themselves were not written
by a human, they were written by an OCaml program, which itself was
written by a human. The really fascinating point about this is that
the codelet generator came up with a few very domain-specific
algorithms which were actually more efficent than any known to man
until that time, in spite of it having been a set of algorithms which
had been studied for decades.

http://fftw.org/pldi99.pdf

So, the moral of the story is, once again, that generating low-level
code by hand is likely not to be the way to get the fastest performing
code in the end; getting a higher level language to do it for you is
likely to be a better way to go.

[Peter Hickman]

be*******@aol.com wrote:

Do you have experience to back up your claims?
Yes, I used to write assembler (and C and Fortran).
I have not written assembler, but sources I respect tell me that good
C++ and Fortran (especially Fortran 95 with its array operations)
compilers DO let you write programs in a high-level language that are
more efficient than the hand-coded assembly you might produce (taking
infinitely longer to write).
At a basic level any C, C++ or Fortran compiler must produce machine code, and
that is what an assembler will produce. So if it can be compiled from C to
machine code it can also be written in assembler. Take you C compiler and add
the -S switch, see that *.s file that it kicked out, that is the assembler for
your C. So as your C is now just assembler, if a machine can write it then so
can a human.
Given an infinite amount of programming time, very few programmers are
going to write assembly code that outperforms LAPACK (in Fortran) for
linear algrebra or FFTW (in C) for Fourier transforms.
No one has ever claimed that assembler was easy or quick to develop, and good
assembler programmers are very hard to find. For that matter competent assembler
programmers are hard to find. They also have off days which compilers don't have
so the quality of their work is not consistent, but then again compilers lack
problem specific knowledge that would allow an assembler programmer to shave a
few op codes out of a routine.

It all comes down to just how important is speed of execution, most people will
say that it is number one until they find out just what it takes. There is also
the economic issue that faster hardware is probably cheaper than the development
costs.
Your point that Python is a productive language despite its slower
execution speed is valid, but don't pretend that the natural
alternative is assembly language.

I have never pretended that python was a natural alternative to assembler only
that what people want 'ease of development' and what they say they want 'speed
of execution' means that they should be looking at languages like python which
provide many good things with respectable performance and the option to drop
down to C for the critical parts and tools like psyco to help things along.

If speed of execution is really an issue but they can't stomach assembler then
you want C, C++ or Fortran, if you can't stomach that then give up on the 'speed
of execution'.

Anyone who is writing python and has speed of execution as a priority has a
screw loose, just as anyone writing assembler and expecting ease of development.

[Aaron Brady]

>

Anyone who is writing python and has speed of execution as a priority has a
screw loose, just as anyone writing assembler and expecting ease of
development.

http://www.dadgum.com/james/performance.html

The above essay, while dealing with Erlang, does something to dispell the
myth that performace == assembler.

A sequential-scan in assembler is still a sequential-scan - if you can
implement, for example, BTrees easily in Python, then on large datasets
that's a win.

Aaron

http://insom.me.uk/blog/

[Irmen de Jong]

Irmen de Jong 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

Thomas Waldmann convinced me to move the page to the
'official' Python Wiki at python.org. so for the record,
the current URL of that page is:
http://www.python.org/cgi-bin/moinmoin/PythonSpeed

--Irmen