Speed Comparison Perl Python & C

[Bart Nessux]

Just fooling around this weekend. Wrote and timed programs in C, Perl and
Python. Each Program counts to 1,000,000 and prints each number to the
console as it counts. I was a bit surprised. I'm not an expert C or Perl
programming expery, I'm most familiar with Python, but can use the others
as well.

Here are my results:

C = 23 seconds
Python = 26.5 seconds
Perl = 34.5 seconds

Here are the programs:

-------------------------
#The C version:
-------------------------

#include <stdio.h>

int main(void)
{
int x = 0;
while (x < 1000000) {
printf("%d \n", x++);
}
}

-------------------------
#The Python version:
-------------------------

#!/usr/bin/python

x = 0
while x < 1000000:
x = x + 1
print x

-------------------------
#The Perl version:
-------------------------

#!/usr/bin/perl -Tw

use strict;

my $x = 0;
while($x < 1000000) {
print $x++, "\n";
}

What do you guys think of this? I don't know enough about Perl & C, and
perhaps Python, to know if this was indeed a fair test. I thought C would
do this much faster than it did. Any ideas?

 

[Bob Ippolito]

Just fooling around this weekend. Wrote and timed programs in C, Perl and
Python. Each Program counts to 1,000,000 and prints each number to the
console as it counts. I was a bit surprised. I'm not an expert C or Perl
programming expery, I'm most familiar with Python, but can use the others
as well. ----
What do you guys think of this? I don't know enough about Perl & C, and
perhaps Python, to know if this was indeed a fair test. I thought C would
do this much faster than it did. Any ideas?

What exactly are you trying to benchmark here? How fast your console
is? Which language buffers stdout the best?

-bob

 

[Ville Vainio]

Bart> fair test. I thought C would do this much faster than it
Bart> did. Any ideas?

Your program prints stuff at every iteration, so it mostly measures I/O
performance. Drop out the print, or print every 1000th item, and you
will start seeing a significant differences...

This is also a textbook example of a case where using C doesn't make
much sense performace-wise. Many seem to believe that using C/C++ also
magically speeds up I/O, and choose it over alternatives because their
network server "needs to be fast".

 

[Nick Patavalis]

Each Program counts to 1,000,000 and prints each number to the
console as it counts.

What do you guys think of this? I don't know enough about Perl & C, and
perhaps Python, to know if this was indeed a fair test. I thought C would
do this much faster than it did. Any ideas?

This is _not_ a meaningfull test! What you are actually measuring, is
the performance of your terminal, not the performance of the
language. Try the same, or a similar, test _without_printing_ (just
count to 1,000,000) and you'll see a huge differene!

/npat

 

[David Lees]

Just fooling around this weekend. Wrote and timed programs in C, Perl and
Python. Each Program counts to 1,000,000 and prints each number to the
console as it counts. I was a bit surprised. I'm not an expert C or Perl
programming expery, I'm most familiar with Python, but can use the others
as well.

Here are my results:

C = 23 seconds
Python = 26.5 seconds
Perl = 34.5 seconds

Here are the programs:

-------------------------
#The C version:
-------------------------

#include <stdio.h>

int main(void)
{
int x = 0;
while (x < 1000000) {
printf("%d \n", x++);
}
}

-------------------------
#The Python version:
-------------------------

#!/usr/bin/python

x = 0
while x < 1000000:
x = x + 1
print x

-------------------------
#The Perl version:
-------------------------

#!/usr/bin/perl -Tw

use strict;

my $x = 0;
while($x < 1000000) {
print $x++, "\n";
}

What do you guys think of this? I don't know enough about Perl & C, and
perhaps Python, to know if this was indeed a fair test. I thought C would
do this much faster than it did. Any ideas?

I don't think your times have much to do with the languages. They are
just how long whatever I/O library is used by a particular language
takes. I would guess that the loop overhead is small compared with the
I/O formatting and output times in your example.

You should do a Google search on 'Python+benchmarks'. Benchmarking is
tricky and you need to consider what you are trying to compare.

David Lees

 

[Jeremy Yallop]

Each Program counts to 1,000,000 and prints each number to the
console as it counts.

Run the programs again, redirecting the output to a file.

Jeremy.

 

[ziaran]

Just fooling around this weekend. Wrote and timed programs in C, Perl and
Python. Each Program counts to 1,000,000 and prints each number to the
console as it counts. I was a bit surprised. I'm not an expert C or Perl
programming expery, I'm most familiar with Python, but can use the others
as well.

Here are my results:

C = 23 seconds
Python = 26.5 seconds
Perl = 34.5 seconds

Here are the programs:

-------------------------
#The C version:
-------------------------

#include <stdio.h>

int main(void)
{
int x = 0;
while (x < 1000000) {
printf("%d \n", x++);
}
}

-------------------------
#The Python version:
-------------------------

#!/usr/bin/python

x = 0
while x < 1000000:
x = x + 1
print x

-------------------------
#The Perl version:
-------------------------

#!/usr/bin/perl -Tw

use strict;

my $x = 0;
while($x < 1000000) {
print $x++, "\n";
}

What do you guys think of this? I don't know enough about Perl & C, and
perhaps Python, to know if this was indeed a fair test. I thought C would
do this much faster than it did. Any ideas?

Last time I checked doing simple prime number searching, C++ was 30
times faster than Python.

 

[Dennis Lee Bieber]

Just fooling around this weekend. Wrote and timed programs in C, Perl and
Python. Each Program counts to 1,000,000 and prints each number to the
console as it counts. I was a bit surprised. I'm not an expert C or Perl
programming expery, I'm most familiar with Python, but can use the others
as well.

Here are my results:

C = 23 seconds
Python = 26.5 seconds
Perl = 34.5 seconds

Given that the slowest part of those programs is the conversion
from internal integer to printable format, followed by the actual I/O
operation... and that, at the lowest level, Python uses the C I/O
libraries, that isn't too surprising. All you've shown is the overhead
on top of the C I/O system.

You might want to read

http://www.pythonsoft.com/empirical_data.pdf

(Took me a while to find that -- the original author's site seems to
have closed down)

--

 

[Bart Nessux]

I don't think your times have much to do with the languages. They are
just how long whatever I/O library is used by a particular language
takes. I would guess that the loop overhead is small compared with the
I/O formatting and output times in your example.

You should do a Google search on 'Python+benchmarks'. Benchmarking is
tricky and you need to consider what you are trying to compare.

David Lees

Thanks, I was trying to do something very similar in each language. Just
wanted to see how fast they could do this, nothing more. I expected the
order of the results to be c, python and then perl, and I expected c to be
the *clear* winner. I don't know that much about programming... that's why
I have all these false notions in my head about speed.

 

[Bart Nessux]

Bart> fair test. I thought C would do this much faster than it
Bart> did. Any ideas?

Your program prints stuff at every iteration, so it mostly measures I/O
performance. Drop out the print, or print every 1000th item, and you
will start seeing a significant differences...

This is also a textbook example of a case where using C doesn't make
much sense performace-wise. Many seem to believe that using C/C++ also
magically speeds up I/O, and choose it over alternatives because their
network server "needs to be fast".

I would be one of the many that you refer to. I've listened to too many
people talk about the speed of C compared to python or other interpreted
languages. Obviously, these people talked of this speed difference to be a
generality (anything done is C is *much* faster than anything equivalent in
Python). My test doesn't support that. It is faster, but not significantly.

I think C is *significantly* faster when it's being used by someone who
*knows* what they're doing and more importantly, they understand *why* C is
faster for the task. That's something that I currently lack... that
understanding. That's why I experiment with the two and post to this group.

Thanks,
Bart

 

[Bart Nessux]

Given that the slowest part of those programs is the conversion
from internal integer to printable format, followed by the actual I/O
operation... and that, at the lowest level, Python uses the C I/O
libraries, that isn't too surprising. All you've shown is the overhead
on top of the C I/O system.

You might want to read

http://www.pythonsoft.com/empirical_data.pdf

(Took me a while to find that -- the original author's site seems to
have closed down)

--

Thanks for the link, looks like a good read.

 

[Ville Vainio]

Bart> I think C is *significantly* faster when it's being used by
Bart> someone who *knows* what they're doing and more importantly,
Bart> they understand *why* C is faster for the task. That's

I don't think knowing what you are doing matters all that much. When
you have to make a database query, you have to make database
query. Actually, Python code might even be faster in circumstances
like these, because you can write more sensible algorithms w/o
investing a week of debugging. So caching data in memory becomes more
appealing.

C is extremely fast when you are doing stuff that requires intensive
computation, loops with millions of iterations etc. Luckily this also
applies to Python modules written in C.

 

[Bob Ippolito]

Thanks, I was trying to do something very similar in each language. Just
wanted to see how fast they could do this, nothing more. I expected the
order of the results to be c, python and then perl, and I expected c to be
the *clear* winner. I don't know that much about programming... that's why
I have all these false notions in my head about speed.

The true notion of speed is that it's relative. In general, don't
worry too much about it until it becomes a problem, or until you have a
lot of free time to go optimizing things that *already work*.
Premature optimization is just about as bad as it sounds.

-bob

 

[Cameron Laird]

.
.
.

query. Actually, Python code might even be faster in circumstances
like these, because you can write more sensible algorithms w/o
investing a week of debugging. So caching data in memory becomes more
appealing.

.
.
.
Yup; I'm now sufficiently arrogant/provocative/confident/experienced/...
to tell people to expect that their Python codings will be *faster* than
what they achieve with C.

 

[beliavsky]

<SNIP>

As others pointed out, your programs mostly test the speed of I/O.
Here is a simple comparison of the speed of integer arithmetic using
Python and Fortran 95 (Compaq Visual Fortran 6.6, with full
optimization).

Python:

i = 1
j = 0
while i < 100000000:
j = j + i
i = i + 1
print j

Fortran 95:

program add
integer*8 :: i,j
j = 0
do i=1,99999999
j = j + i
end do
print*,j
end program add

numerical result: 4999999950000000
elapsed times in seconds, using timethis.exe command on Windows XP
Professional:

Python 93.4
Fortran 0.28

The Fortran program is more than 300 times faster. The benchmarks at
http://www.polyhedron.co.uk/compare/win32/f90bench_p4.html suggest
that the Fortran/Python speed gap is even larger if the Intel Fortran
compiler is used.
The speed ratio of the fastest to slowest Fortran compiler is about
two, so ANY Fortran compiler beats Python by more than two orders of
magnitude here.

The Intel Fortran compiler for Linux can be obtained free for
noncommercial use at
http://www.intel.com/software/products/compilers/flin/noncom.htm .

 

[Richard Brodie]

The Fortran program is more than 300 times faster.

Yes. Although this example does suit very aggressive optimization.
It doesn't quite precompute the answer but there is some fancy
parallelisation going on.

 

[Neil Hodgson]

(e-mail address removed):

As others pointed out, your programs mostly test the speed of I/O.
Here is a simple comparison of the speed of integer arithmetic using
Python and Fortran 95 (Compaq Visual Fortran 6.6, with full
optimization).

It actually compares the speed of integers large enough to need 64 bits
of precision where Fortran can use a 64 bit integer and Python uses an
unbounded integer. The test can be sped up in two ways, first by using
floating point (which is fixed length in Python) and by using Psyco. On my
machine:

Original test: 245 seconds
Using floats: 148 seconds
Using psyco with integers: 69 seconds
Using psyco with floats: 18.4 seconds

Therfore gaining a speed up of 13 times. This leads to Fortran likely
remaining 22 times faster.

from psyco.classes import *
import psyco

def xx():
i = 1.0
j = 0.0
while i < 100000000.0:
j = j + i
i = i + 1
print int(j)

psyco.profile()

xx()

Neil

 

[Josiah Carlson]

i = 1

j = 0
while i < 100000000:
j = j + i
i = i + 1
print j

Python 93.4
Fortran 0.28

Not quite fair. The Python version does long-integer
(infinite-precision) math when i is greater than 65534 on a 32 bit
processor. You are really counting is the time to do 100,065,535
integer additions and 99934465 long-integer additions.

Furthermore, you allow fortran to optimize the loop, but you don't
optimize the python loop yourself, using those portions built-in that
are known to be fast.

print sum(xrange(100000000))
takes half-as long as the while loop on my machine, yet does the exact
same calculations.


Your Fortran definition includs a message saying "use 64-bit integers here":
integer*8 :: i,j


You are comparing apples to oranges on multiple levels. Don't.

- Josiah

 

[Paul Rubin]

Not quite fair. The Python version does long-integer
(infinite-precision) math when i is greater than 65534 on a 32 bit
processor.

Why is that unfair? It's showing a difference between Fortran and
Python, that Fortran supports 64-bit integers, while Python has to
resort to longs.

Furthermore, you allow fortran to optimize the loop, but you don't
optimize the python loop yourself, using those portions built-in that
are known to be fast.

Nothing stops Python from optimizing the loop. It just doesn't do so.
Again, it's an implementation vs implementation comparison, with
Fortran winning.

 

[Michael Hudson]

Nothing stops Python from optimizing the loop. It just doesn't do so.
Again, it's an implementation vs implementation comparison, with
Fortran winning.

I haven't read the rest of this thread, but my curiosity is almost
(but not quite) piqued enough by this statement to go back and find
out why it's being said

Cheers,
mwh