I gotta say that as number cruncher, iteration in python is my biggest
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/iterativ
>> I don't want to offend you or anything, but doesn't the second sentence mean
>> that someone DID do a speed comparison?
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 i
Peter Hansen enlightened us with:
> 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".
Sybren
--
The proble
Sybren Stuvel wrote:
> 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 com
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?
Sybren
--
The problem wi
I am going to be a bit blunt. Don't get offended.
>> 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
Hi all,
> 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 ?
rega
Terry Hancock wrote:
> On Tuesday 23 August 2005 05:35 am, bruno modulix wrote:
>
(snip)
>>
>>If you hope to be taken seriously, please abandon the sms-talk style here.
>>
>
>
> I think it's reasonably clear that neither poster hoped "to be taken
> seriously". :-D
>
Err... I guess that "to be
On Tuesday 23 August 2005 05:35 am, bruno modulix wrote:
> 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
Steve Holden 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
>
> Why are you lo
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
Steve Holden wrote:
(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
>
keyboar
Terry Reedy wrote:
> "Benjamin Niemann" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
(snip)
>>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 v
km wrote:
>>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 fal
computers are cheap. i am expensive. give me clear and maintainable
code every time.
randy
--
http://mail.python.org/mailman/listinfo/python-list
km wrote:
> 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 fas
> 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 proj
km wrote:
> 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 pyth
"Benjamin Niemann" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> km 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.
>
> In th
"km" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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 sh
km 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.
In that case, you are interested in IO performance. The time spent handling
the loop is not sign
km wrote:
> 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 wh
km wrote:
>>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
km a écrit :
> 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 ran
> 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.
+1 QOTW
(sometimes the zen master has to whack the student on the head)
Peace
Bill Mill
bill.mill at gmail.com
--
http:
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..1
They come out even in the computer language shootout:
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 <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> > thing.
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 spee
"km" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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
km wrote:
> 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 ...
>
> what more do i need to accept python is slow when it comes to
> loops concept ?
You've sort of missed some of the points being made,
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 p
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..1
km wrote:
> 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 loo
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)
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..
km <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> 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
> --
>
35 matches
Mail list logo
