loop in python
km
Why is it that the implementation of empty loop so slow in python when compared to perl ?
#i did this in python (v 1.5)
for x in xrange(1000):
print x
# this took 0.017 seconds
--------------------------
#similar code in perl (v 5.6):
for $x (0..1000)
{
print $x;
}
# this took 0.005 seconds only !!!
Is python runtime slow at all aspects when compared to perl ?
I really wonder what makes python slower than perl ?
Is there any proposal to make python faster in future versions ?
curious to know all these ...
regards,
KM
Rick Wotnaz
news:mailman.3360.1124720...@python.org:
It appears that Python is not optimized for empty loops.
--
rzed
bruno modulix
> Hi all,
>
> Why is it that the implementation of empty loop so slow in python when compared to perl ?
>
> #i did this in python (v 1.5)
Python 1.5.2 was released in april 1999. Current Python version is 2.4.1.
Please consider upgrading - unless of course you just want to troll...
> for x in xrange(1000):
> print x
This is not an empty loop. An empty loop is
for x in xrange(1000):
pass
> Is python runtime slow at all aspects when compared to perl ?
Is your question serious or are you just trolling ?
> I really wonder what makes python slower than perl ?
I really wonder what makes my old P133/32mo running w98 slower that my
more recent XP1200/256mo running gentoo/linux.
> Is there any proposal to make python faster in future versions ?
The future is already here....
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'on...@xiludom.gro'.split('@')])"
Daniel Dittmar
> Why is it that the implementation of empty loop so slow in python when compared to perl ?
> Is python runtime slow at all aspects when compared to perl ?
No
> I really wonder what makes python slower than perl ?
It could be that the Perl compiler recognizes such a for loop and emits
special code (e.g. an integer loop variable that gets incremented).
Python creates an xrange object and then has the overhead of 1000 next()
calls.
You should benchmark other features before jumping to conclusions: calls
to functions, calls to methods, calls to inherited methods.
Others will probably chime in with arguments whether such micro
benchmarks are a useful indication of the speed a complete program at all.
> Is there any proposal to make python faster in future versions ?
Yes in the general case, probably no in this specific case.
Daniel
D H
> Hi all,
>
> Why is it that the implementation of empty loop so slow in python when compared to perl ?
>
> #i did this in python (v 1.5)
> for x in xrange(1000):
> print x
> # this took 0.017 seconds
> --------------------------
> #similar code in perl (v 5.6):
> for $x (0..1000)
> {
> print $x;
> }
> # this took 0.005 seconds only !!!
>
> Is python runtime slow at all aspects when compared to perl ?
> I really wonder what makes python slower than perl ?
Yeah but the python version took 2.1 less seconds to type.
Python runs as fast as Perl.
km
ya i am sorry i tried with an empty loop first and then one which emits a value as the snippet. I have tested it on my machine and now ...
1) perl (v 5.8) does the job in 0.005 seconds
2) but python (v 2.4.1) is horribly slow its 0.61 seconds.
and using range() instead of xrange() in python snippet, it not better , it takes 0.57 seconds. just test it urself and see.
what more do i need to accept python is slow when it comes to loops concept ?
PS : my linux box is running fedora core 2 with 256 MB RAM
regards,
KM
-----------------------------------------------------------------------
On Tue, Aug 23, 2005 at 12:25:01PM +0530, km wrote:
> Hi all,
>
> Why is it that the implementation of empty loop so slow in python when compared to perl ?
>
> #i did this in python (v 1.5)
> for x in xrange(1000):
> print x
> # this took 0.017 seconds
> --------------------------
> #similar code in perl (v 5.6):
> for $x (0..1000)
> {
> print $x;
> }
> # this took 0.005 seconds only !!!
>
> Is python runtime slow at all aspects when compared to perl ?
> I really wonder what makes python slower than perl ?
> Is there any proposal to make python faster in future versions ?
>
> curious to know all these ...
>
> regards,
> KM
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>
Peter Hansen
> ya i am sorry i tried with an empty loop first and then one which
> emits a value as the snippet. I have tested it on my machine
> and now ...
>
> loops concept ?
You've sort of missed some of the points being made, which in essence
are saying "your benchmark is less than useless, and you're confused
about what matters".
One key point about benchmarking is to make the test representative. If
you are going to be running empty loops, then you're doing the right
thing. If *all* your loops are going to do is print stuff, then you're
doing the right thing with the version that "emits values".
On the other hand, if you are really doing something else entirely, then
your tests are telling you nothing about your real problem, and are in
fact confusing you greatly, which is why they are less than useless.
With the part about "confused about what matters" I mean that you are
trying to optimize something a) when you don't have working code, and b)
when you don't know that you need to make it any faster.
The first rule of optimization is to make your code work first, and only
then consider making it fast. The second rule of optimization is that
you shouldn't waste time doing it unless you really need faster results
(and it requires actual elapsed time or response time measurements to
know this). Since you haven't got any working code, it's not possible
that you *need* whatever negligible speed difference there might be
between Python and Perl.
And, lastly, in case this thought didn't get through either: Python is
*not* significantly slower than Perl except in certain uncommon cases --
perhaps including useless empty loops -- so if you really want to use
Python, don't let your first attempts at benchmarking dissuade you.
Really, trust us.
Python's strengths lie in four things: the readability of the code, the
huge range of library modules available, the elegance of its object
oriented constructs, and the helpfulness of its community. Raw speed is
not one of its strengths, but there are tens of thousands of people
using it quite effectively and without daily concern for its speed (same
as Perl, by the way since, again, they are _not_ significantly different
in speed no matter what an empty loop test shows).
-Peter
Terry Reedy
"km" <k...@mrna.tn.nic.in> wrote in message
news:20050823084...@mrna.tn.nic.in...
> ya i am sorry i tried with an empty loop first and then one which emits
> a value as the snippet. I have tested it on my machine and now ...
>
> 2) but python (v 2.4.1) is horribly slow its 0.61 seconds.
> and using range() instead of xrange() in python snippet, it not better ,
> it takes 0.57 seconds. just test it urself and see.
I did. "for x in xrange(10000000): pass" (cut and pasted, Python 2.2, 10
million passes) takes about 1.5 second (estimated by 'one thousand and
one...' method). Divide by 10000 for your 1000 iteration test.
> what more do i need to accept python is slow when it comes to loops
> concept ?
Valid comparitive data from honest and competant testers with different but
properly functioning systems.
Terry J. Reedy
km
> thing. If *all* your loops are going to do is print stuff, then you're
> doing the right thing with the version that "emits values".
ya most of the loops print values.
> know this). Since you haven't got any working code, it's not possible
> that you *need* whatever negligible speed difference there might be
> between Python and Perl.
>
> Python, don't let your first attempts at benchmarking dissuade you.
> Really, trust us.
ya i do.
> Python's strengths lie in four things: the readability of the code, the
> huge range of library modules available, the elegance of its object
> oriented constructs, and the helpfulness of its community. Raw speed is
> not one of its strengths, but there are tens of thousands of people
> using it quite effectively and without daily concern for its speed (same
> as Perl, by the way since, again, they are _not_ significantly different
> in speed no matter what an empty loop test shows).
I agree that python emphasizes on readability which i didnt see in many of the languages, but when the application concern is speed, does it mean that python is not yet ready? even most of the googling abt python vs perl convince me that perl is faster than python in most of the aspects. Also the first thing any newbie to python asks me is abt "raw speed in comparison with similar languages like perl" when i advocate python to perl.
regards,
KM
Bill Mill
http://shootout.alioth.debian.org/benchmark.php?test=all&lang=python&sort=fullcpu
(tied 8-8 in execution time, although perl wins 4-12 on memory consumption)
Peace
Bill Mill
On 8/23/05, km <k...@mrna.tn.nic.in> wrote:
> Hi all,
>
> > thing. If *all* your loops are going to do is print stuff, then you're
> > doing the right thing with the version that "emits values".
>
> ya most of the loops print values.
>
> > know this). Since you haven't got any working code, it's not possible
> > that you *need* whatever negligible speed difference there might be
> > between Python and Perl.
> >
> > Python, don't let your first attempts at benchmarking dissuade you.
> > Really, trust us.
>
> ya i do.
>
> > Python's strengths lie in four things: the readability of the code, the
> > huge range of library modules available, the elegance of its object
> > oriented constructs, and the helpfulness of its community. Raw speed is
> > not one of its strengths, but there are tens of thousands of people
> > using it quite effectively and without daily concern for its speed (same
> > as Perl, by the way since, again, they are _not_ significantly different
> > in speed no matter what an empty loop test shows).
>
> I agree that python emphasizes on readability which i didnt see in many of the languages, but when the application concern is speed, does it mean that python is not yet ready? even most of the googling abt python vs perl convince me that perl is faster than python in most of the aspects. Also the first thing any newbie to python asks me is abt "raw speed in comparison with similar languages like perl" when i advocate python to perl.
>
>
Steve Holden
> Hi all,
>
> Why is it that the implementation of empty loop so slow in python when compared to perl ?
>
> #i did this in python (v 1.5)
> for x in xrange(1000):
> print x
> # this took 0.017 seconds
> --------------------------
> #similar code in perl (v 5.6):
> for $x (0..1000)
> {
> print $x;
> }
> # this took 0.005 seconds only !!!
>
> Is python runtime slow at all aspects when compared to perl ?
> I really wonder what makes python slower than perl ?
> Is there any proposal to make python faster in future versions ?
>
> curious to know all these ...
>
> regards,
> KM
>
Unfortunately it gets the answer to every problem wrong unless the
answer is 42, but boy it runs quickly. The code for the whole
interpreter (it's written in Python) follows:
print 42
Why are you looking for a "fast language" without any regard for the
kind of problems you actually want (or need) to solve? Speed of
execution is so insignificant for the majority of programming problems
that this obsession reveals a certain inexperience.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Bruno Desthuilliers
> Hi all,
>
> ya i am sorry i tried with an empty loop first and then one which emits a value as the snippet. I have tested it on my machine and now ...
>
> 1) perl (v 5.8) does the job in 0.005 seconds
> 2) but python (v 2.4.1) is horribly slow its 0.61 seconds.
> and using range() instead of xrange() in python snippet, it not better , it takes 0.57 seconds. just test it urself and see.
>
> what more do i need to accept python is slow when it comes to loops concept ?
>
#python -> python2.4.1:
for i in xrange(100000):
print i
real 0m8.997s
user 0m1.355s
sys 0m0.483s
/* C -> gcc -Wall -ansi -pedantic -O3 */
# include <stdio.h>
int main(void)
{
int i;
for (i = 0; i < 100000; i++)
printf("%d\n", i);
return 0;
}
real 0m7.165s
user 0m0.276s
sys 0m0.430s
Well... seems that Python is not *so* slow when compared to C on this
one. But wait... Could it be possible that we're in fact merely
benchmarking IO's ?-)
lol...
And what about this:
# loops2.pl
for $x (0..100000){}
real 0m0.038s
user 0m0.030s
sys 0m0.002s
# loops2.c
int main(void)
{
int i;
for (i = 0; i < 100000; i++);
return 0;
}
real 0m0.002s
user 0m0.001s
sys 0m0.001s
Oh my ! What more do you need to accept Perl is *so awfully slow*.
If you want to keep on trolling on this, I suggest that you "benchmark"
(lol) a Java, a PHP and a Ruby versions too...
But I don't despair... Chances are that, one day, you understand that
what is important is what you going on in the loop - not the loop itself.
Bill Mill
> Unfortunately it gets the answer to every problem wrong unless the
> answer is 42, but boy it runs quickly.
+1 QOTW
(sometimes the zen master has to whack the student on the head)
Peace
Bill Mill
bill.mill at gmail.com
Peter Hansen
>>thing. If *all* your loops are going to do is print stuff, then you're
>>doing the right thing with the version that "emits values".
>
> ya most of the loops print values.
No, you missed my point. I said if *all* the loops are going to do is
print stuff. In other words, no other calculations, no function calls,
no nothing. Just simple "print" statements. Doing this in your test
just tests I/O in the C library and operating system, not anything to do
with the speed of Python, as Bruno has clarified in detail.
-Peter
rafi
> Also the first thing any newbie to python asks me is abt "raw speed
> in comparison with similar languages like perl" when i advocate
> python to perl.
Always the same chorus... Just tell the newbies that speed is not on
their top list.
If most of the world's computer programs where running two times slower
but with two times less bugs, imagine how many hours we would benefit...
--
rafi
"Imagination is more important than knowledge."
(Albert Einstein)
Benjamin Niemann
> Hi all,
>
>> thing. If *all* your loops are going to do is print stuff, then you're
>> doing the right thing with the version that "emits values".
>
> ya most of the loops print values.
In that case, you are interested in IO performance. The time spent handling
the loop is not significant compared to the time spent executing the
'print' statement - which is a very complex operation despite its simple
usage.
An implementation where a simple control flow structure has an measurable
impact on the overall timing of an IO bound program would really suprising.
Python suprises me often, but in different ways ;)
Perhaps you could try to use sys.stdout.write() directly, avoiding the
overhead of 'print'. Perhaps there are differences between the (default)
output buffering settings of perl and python.
--
Benjamin Niemann
Email: pink at odahoda dot de
WWW: http://www.odahoda.de/
Terry Reedy
> I agree that python emphasizes on readability which i didnt see in many
> of the languages, but when the application concern is speed, does it
> mean that python is not yet ready? even most of the googling abt python
Funny you should mention 'googling'. Are you aware that at least the first
versions of the Google web spider and indexer were written in Python?
Google continues to use Python. But then, they are smarter than most
people when it comes to business economics and competitive advantage.
> vs perl convince me that perl is faster than python in most of the
> aspects.
Total cost of a computer program project includes human programmer time to
write, test, revise, and maintain. For many people, Python wins on this
sometimes dominant aspect. For commercial projects, calendar time to
market is also critical.
> Also the first thing any newbie to python asks me is abt "raw speed in
> comparison with similar languages like perl" when i advocate python to >
> perl.
I presume by 'raw speed' you/they mean cpu execution speed as opposed to
human read, write, and understanding speed. I really don't know what to
say to someone who counts their own time as worthless in comparision to
penny a minute CPU time. But also, I would not advocate Python over Perl
to a full-time programmer who is both comfortable and productive with Perl.
Terry J. Reedy
Terry Reedy
"Benjamin Niemann" <pi...@odahoda.de> wrote in message
news:dedgo7$mru$1...@online.de...
According to postings some years ago, the perl folks have worked specially
hard to speed I/O, even to the point of replacing or rewriting some of the
C stdio library, at least for some systems. Hence, at that time, Perl was
expected and known to be noticeably faster than Python on such systems.
Since then, Python I/O has been sped up to at least make better use of
stdio, so the gap may be less.
This suggests to me:
1. One should not generalize to other aspects of computation. If, for
instance, Python got Numerical Python before Perl got the equivalent, then
it would have been multiples faster at numerical computation.
2. One should compare the lastest with the lastest to compare the results
of catch up with stay ahead efforts.
3. One should test computations that are relevant to the question being
asked. Python I/O speedups were aimed at 'for line in somefile: ...' and
equivalent outputs, not in quickly writing thousands or millions of
characters one at a time.
Terry J. Reedy
Gregory Bond
> Is python runtime slow at all aspects when compared to perl ?
And in addition to all that everyone else has said.... most of this is
startup time. The python interpreter is a fair bit slower to start up
(i.e. does much more at startup time) than the perl one:
> lenford$ time python -c "pass"
>
> real 0m0.298s
> user 0m0.030s
> sys 0m0.030s
> lenford$ time perl -e "0"
>
> real 0m0.037s
> user 0m0.000s
> sys 0m0.000s
[on a fairly fast Solaris box]. This is mainly because much more of
python is written in python and needs to be loaded / dynamically linked
when the process starts up. On my system, python loads 14 .so files and
13 .pyc files. Perl loads 7 .so files.
km
> Unfortunately it gets the answer to every problem wrong unless the
> interpreter (it's written in Python) follows:
> print 42
great ! u can use it for ur own projects. but pls donot suggest it to anyone else. i think u can get an award for developing such a fast language in such a shorter time ;-) may be u can also be called 'Guido Holden Rossum' ;-) anyway improve it - its quite buggy now :-D
> Speed of execution is so insignificant for the majority of programming problems
I donot agree with that.
If thats the case then no one would be using C or C++ etc for instance.
one important thing is that i am not comparing python with C but with similar language, Perl. well ofcourse i dont jump into conclusion, just with just a simple 'loops' snippet, that python is slower than perl. but when speed is important then ? also i hate people recommending "if u need speed code it as a C extension module". ofcourse i donot expect pure python/perl program to execute at the speed of a C program.
> that this obsession reveals a certain inexperience.
its neither obsession nor inexperience ... its just the requirement.
i think less buggy code is not the main concern for all. if thats the case there are better languages (like Ada with better built in exception classes) and so used in mission critical applications. even perl is still popular even its difficult to maintain, but when one looks for speed (naturally), rather than the readability & maintainability of the code, does python suit perl ?
i am aware one of the main principle python isn founded is better readability but is that a feature which decreases execution speed ? then what is it ? even perl is still popular even if its difficult to maintain after a certian stage of coding. there obviously will be a bias in this list towards python but i need a honest opinion of python vs perl. (especially when it comes to webscripting)
> regards
> Steve
"The inventor of Holden"
regards,
KM
Peter Otten
> the first thing any newbie to python asks me is abt "raw speed in
> comparison with similar languages like perl" when i advocate python to
> perl.
In that case it is easy enough to follow the common industry practice and
tweak your test cases until your favourite product comes out faster.
$ time perl -e $'sub f() {for $i (0..10000000) {}} f();'
real 0m1.075s
user 0m1.073s
sys 0m0.000s
$ time python2.4 -c $'def f():\n for i in xrange(10000001): pass\nf()'
real 0m0.878s
user 0m0.871s
sys 0m0.005s
Working hypothesis: All benchmarks where Python comes out slower than Perl
are not done properly :-)
Peter
Randy Bush
code every time.
randy
rafi
>>that this obsession reveals a certain inexperience.
>
> its neither obsession nor inexperience ... its just the requirement.
> i think less buggy code is not the main concern for all.
Argh (choking)
Then you are definitely a dangerous person! If your program is fast to
give a false answer, it is like driving a truck with the eyes closed in
down town ("I can go fast, I am not scared, I do not see the dangers").
Please tell us for you are working in order for us to avoid the software
/ services you are providing.
bruno modulix
> "Benjamin Niemann" <pi...@odahoda.de> wrote in message
> news:dedgo7$mru$1...@online.de...
>
>>In that case, you are interested in IO performance. The time spent
>>handling
>>the loop is not significant compared to the time spent executing the
>>'print' statement - which is a very complex operation despite its simple
>>usage.
>>
>>An implementation where a simple control flow structure has an measurable
>>impact on the overall timing of an IO bound program would really
>>suprising.
>>Python suprises me often, but in different ways ;)
>>
>>Perhaps you could try to use sys.stdout.write() directly, avoiding the
>>overhead of 'print'. Perhaps there are differences between the (default)
>>output buffering settings of perl and python.
>
>
> According to postings some years ago, the perl folks have worked specially
> hard to speed I/O, even to the point of replacing or rewriting some of the
> C stdio library, at least for some systems. Hence, at that time, Perl was
> expected and known to be noticeably faster than Python on such systems.
The truth is that the Perl version of the "print loop" program is
incredibly faster than it's C counterpart (at least on my gentoo/linux
box). Since the "no-op loop" program is faster in C (I guess that GCC
'optimizes out' the whole loop !-), it seems clear that Perl's IO do not
relie on the stdlib implementation.
> Since then, Python I/O has been sped up to at least make better use of
> stdio, so the gap may be less.
The Python and C versions of the "print loop" program have execution
times that are close enough...
> 3. One should test computations that are relevant to the question being
> asked.
Of course !-)
bruno modulix
(snip)
> If you want a fast language, try Holden. I've just invented it.
> Unfortunately it gets the answer to every problem wrong unless the
> answer is 42, but boy it runs quickly. The code for the whole
> interpreter (it's written in Python) follows:
>
> print 42
>
keyboard !
bruno modulix
>>If you want a fast language, try Holden. I've just invented it.
>>Unfortunately it gets the answer to every problem wrong unless the
>>answer is 42, but boy it runs quickly. The code for the whole
>>interpreter (it's written in Python) follows:
>
>
>>print 42
>
>
> great ! u can use it for ur own projects. but pls donot suggest it to
anyone else.
<ot>
If you hope to be taken seriously, please abandon the sms-talk style here.
</ot>
> anyway improve it - its quite buggy now :-D
Nope, it works just as described. "It's not a bug, Sir, it's a feature" !-)
>
>>Speed of execution is so insignificant for the majority of programming problems
>
> I donot agree with that.
> If thats the case then no one would be using C or C++ etc for instance.
1/ "for the majority of programming problems" : "the majority", not "all
and every".
2/ Apache is coded in C, but there are cases where it can be
outperformed by a specializd Python-coded HTTP server.
3/ OpenOffice is coded in C++ and it's one of the slowest app I ever saw
(even Photoshop 6 on a dying P133/32mo Win98 box is more responsive)
In most systems, the parts that can be performance bottlenecks are the
presentation and the data persistence layers. That's the parts that are
*already* coded in low-level languages and optimized as can be - if of
course you use existing tools (GUI Toolkit, RDBMS etc) instead of trying
to reimplement'em in Perl/Python/whatever !-)
> one important thing is that i am not comparing python with C but with
similar language, Perl.
What you are "comparing" is either IO times (the "print loop" program),
where Perl beats C - which means that Perl's IO have been written at a
very low level instead of relying on the stdlib's IO - or absolutely
meaningless (I just don't care if no-op loops are slow since I don't
write no-op loops).
> well ofcourse i dont jump into conclusion,
Yes you did.
> just
with just a simple 'loops' snippet, that python is slower than perl.
for i in xrange(100000):
print "this 'benchmark' is ABSOLUTELY MEANINGLESS"
> but
when speed is important then ? also i hate people recommending "if u
need speed code it as a C extension module". ofcourse i donot expect
pure python/perl program to execute at the speed of a C program.
In some cases, they can be fastest than the C version.
>
>>that this obsession reveals a certain inexperience.
>
>
> its neither obsession nor inexperience ... its just the requirement.
Which "requirement" ?
> i think less buggy code is not the main concern for all.
+1 QOTW
> i am aware one of the main principle python isn founded is better
readability but is that a feature which decreases execution speed ?
Nope. It has to do with implementation (of the language), not design.
> there obviously will be a bias
in this list towards python
Oh, really ? Err, wait, what's the name of this group, exactly ?
> but i need a honest opinion of python vs
perl. (especially when it comes to webscripting)
This is another question, and has nothing to do with your "benchmark",
but FWIW, Google uses Python, not Perl.
Fredrik Lundh
> If you want a fast language, try Holden. I've just invented it.
> Unfortunately it gets the answer to every problem wrong unless the
> answer is 42, but boy it runs quickly. The code for the whole
> interpreter (it's written in Python) follows:
>
> print 42
>
> Why are you looking for a "fast language" without any regard for the
> kind of problems you actually want (or need) to solve?
isn't measuring speed by timing for-loops a 70's thing? I remember doing that
back when I used Z80 BASIC machines (on a 3.58 MHz machine using floating
point variables, each iteration took almost exactly 1 millisecond).
I also remember that the compiler for my first custom language for that machine
contained exactly one optimization: empty loops were replaced with plain assign-
ments. everyone was mightly impressed.
(for another view of Python's performance, see John Walker's floating point
benchmarks: http://www.fourmilab.ch/fourmilog/archives/2005-08/000567.html
from what I can tell, Python's the fastest interpreter in that test...)
</F>
Terry Hancock
> km wrote:
> >>If you want a fast language, try Holden. I've just invented it.
> >>Unfortunately it gets the answer to every problem wrong unless the
> >>answer is 42, but boy it runs quickly. The code for the whole
> >>interpreter (it's written in Python) follows:
> >
> >>print 42
> >
> > great ! u can use it for ur own projects. but pls donot suggest it to
> anyone else.
>
> <ot>
> If you hope to be taken seriously, please abandon the sms-talk style here.
> </ot>
I think it's reasonably clear that neither poster hoped "to be taken
seriously". :-D
--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks http://www.anansispaceworks.com
bruno modulix
> On Tuesday 23 August 2005 05:35 am, bruno modulix wrote:
>
>><ot>
>>If you hope to be taken seriously, please abandon the sms-talk style here.
>></ot>
>
>
> I think it's reasonably clear that neither poster hoped "to be taken
> seriously". :-D
>
sérieux") has some other meaning in english :-/
km
> What you are "comparing" is either IO times (the "print loop" program),
> where Perl beats C - which means that Perl's IO have been written at a
> very low level instead of relying on the stdlib's IO -
i'd like to know what aspects are really coded in very low level for python ?
regards,
KM
James
>> Also the first thing any newbie to python asks me is abt "raw speed in comparison with similar languages like perl" when i advocate python to perl.
Judging by your other posts, you are a newbie yourself. You are not
really in a position to 'advocate' any language over others.
>> I agree that python emphasizes on readability which i didnt see in many of the languages, but when the application concern is speed, does it mean that python is not yet ready? even most of the googling abt python vs perl convince me that perl is faster than python in most of the aspects.
One does not compare speed when they use Perl/Python/Ruby/Tcl. They are
all more or less in the same performance ball park.
Next don't make up your own benchmarks and jump to conclusions. Writing
good benchmarks is an art. If you need data, look at peer reviewed
benchmarks such as this one. http://shootout.alioth.debian.org/
As with all benchmarks, it is really hard to make general conclusions.
And you are simply looking at the wrong issue. Even if Python is 20
times slower than it's current implementation, it would still serve my
purposes. Do you believe that you need more speed? Tell us what is it
exactly that you are building and we will tell you what to do. Fetishes
with Speed and executable size are very common for young newbies. I
know because I had been there myself several years ago.
Python has been more than ready as far as speed goes. Real people, real
enterprises have been using Python in high load applications for quite
a while now and there is nothing really left to proove. People have
written entire application servers and databases in Python.
I taught myself atleast half a dozen ways to write native extensions
for Python, just in case. In the past 4 yrs or so that I have been
using Python as my main language, I did not need to speed up my Python
program even once with a custom extension. And I process multi giga
byte data sets. Why? Because, if your program is slow, chances really
are that your algorithm is slow, not the language. And most of the
Python modules that are available that need speed (GUIs, image
processing etc), are already written in C so that you, as a user, don't
have to worry.
Just get over your imaginary need for speed and learn to use Python for
what it is intended. Once again, post your actual application need, not
vague requirements with artificial conditions (I don't want C modules).
You said, elsewhere that you are writing a web application. People have
been using CGI, which has a terrible performace record for decades on
very slow machines compared to modern PCs. My point is, web
applications, "generally" aren't exactly the kind of applications that
have a lot of computational overhead, atleast not from the logic that
runs your site and is likely to be written in Python.
Sybren Stuvel
> One does not compare speed when they use Perl/Python/Ruby/Tcl. They
> are all more or less in the same performance ball park.
I don't want to offend you or anything, but doesn't the second
sentence mean that someone DID do a speed comparison?
Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa
Peter Hansen
> James enlightened us with:
>
>>One does not compare speed when they use Perl/Python/Ruby/Tcl. They
>>are all more or less in the same performance ball park.
>
>
> I don't want to offend you or anything, but doesn't the second
> sentence mean that someone DID do a speed comparison?
Yes, and has shown that they are in the same ballpark, and therefore one
does not _need_ to compare speed any more. At least, that's how I read
what James posted.
-Peter
Sybren Stuvel
> Yes, and has shown that they are in the same ballpark, and therefore
> one does not _need_ to compare speed any more.
Ok. I'd worded it as "there have been tests already, so there is no
need to do your own", instead of "one does not test".
James
I did provide Language Shootout link in the next paragraph of the post
you referred to along with an obligatory caution about interpreting
benchmarks. The Language Shootout is a general enough benchmark to
cover all popular languages not just comparing between
Perl/Python/Ruby/Tcl (which I said was pointless). So the statements
are not in conflict.
travlr
nightmare. I do what is possible with numpy, but element by element
processing is a hassle. My programming experience is still pretty fresh
at a year, so "exotics" as such are not in play yet. I also wish python
looping/iterative features could be improved as best possible (what
ever extent that may be). Generators are a friend, but not as
performance friendly as when I am able to do all the needed work in
numpy. I dunno I guess I got spoiled :)