benchmark

[Jack]

I know one benchmark doesn't mean much but it's still disappointing to see
Python as one of the slowest languages in the test:

http://blog.dhananjaynene.com/2008/0...-jruby-groovy/

[Jake Anderson]

Jack wrote:

I know one benchmark doesn't mean much but it's still disappointing to see
Python as one of the slowest languages in the test:

http://blog.dhananjaynene.com/2008/0...-jruby-groovy/
--
http://mail.python.org/mailman/listinfo/python-list

Something to note though, The python version is ~ half the length of the
rest of them ;->

[bearophileHUGS]

On Aug 7, 2:05 am, "Jack" <[e-mail]:

I know one benchmark doesn't mean much but it's still disappointing to see
Python as one of the slowest languages in the test:

http://blog.dhananjaynene.com/2008/0...rison-c-java-p...

That Python code is bad, it contains range() instead of xrange, the
big loop is in the main code instead of inside a function, uses ==
None, etc. That person can try this (with Psyco), I have changed very
little, the code is essentially the same:
import time, psyco
from psyco.classes import __metaclass__

class Person:
def __init__(self, count):
self.count = count
self.prev = None
self.next = None
def shout(self, shout, deadif):
if shout < deadif:
return shout + 1
self.prev.next = self.next
self.next.prev = self.prev
return 1

class Chain:
def __init__(self, size):
self.first = None
last = None
for i in xrange(size):
current = Person(i)
if self.first is None:
self.first = current
if last is not None:
last.next = current
current.prev = last
last = current
self.first.prev = last
last.next = self.first
def kill(self, nth):
current = self.first
shout = 1
while current.next != current:
shout = current.shout(shout, nth)
current = current.next
self.first = current
return current
def main():
ITER = 100000
start = time.time()
for i in xrange(ITER):
chain = Chain(40)
chain.kill(3)
end = time.time()
print 'Time per iteration = %s microseconds ' % ((end - start) *
1000000 / ITER)

psyco.full()
main()

us = microseconds
On my PC (that seems similar to his one) this version needs about 38.9
us/iter instead of 189.

On my PC the Java version takes 1.17 us, while the C++ version (with
MinGW 4.2.1) takes 9.8 us.
A raw D translation needs 14.34 us, while a cleaned up (that uses
structs, no getters/setters) needs 4.67 us.
I don't know why my C++ is so much slow (doing the same things to the C
++ version doesn't change its running time much).

Bye,
bearophile

[Stefan Behnel]

Jack wrote:

I know one benchmark doesn't mean much but it's still disappointing to see
Python as one of the slowest languages in the test:

http://blog.dhananjaynene.com/2008/0...-jruby-groovy/

Just ignore that. If the code had been designed for Python from the start, it
would have performed a lot better.

Currently it looks like syntax-adapted Java code to me.

Stefan

[Steven D'Aprano]

On Thu, 07 Aug 2008 07:49:45 +0200, Stefan Behnel wrote:

Jack wrote:

>I know one benchmark doesn't mean much but it's still disappointing to
see Python as one of the slowest languages in the test:

http://blog.dhananjaynene.com/2008/0...arison-c-java-

python-ruby-jython-jruby-groovy/

>
Just ignore that. If the code had been designed for Python from the
start, it would have performed a lot better.

I recommend folks copy and paste his code into an interactive session,
and watch the thousands of <__main__.Person object at 0xb7f18e2cthat
flash onto the screen. You want to know why it's so slow? That's part of
the reason.

Doing so on my computer gives a final result of:

"Time per iteration = 502.890818119 microseconds"

When I make a single, two character modification to the program
(inserting "t=" at the beginning of the line "chain.kill(3)"), I get this
instead:

"Time per iteration = 391.469910145 microseconds"

In other words, about 20% of the time he measures is the time taken to
print junk to the screen.
--
Steven

[jlist]

I think what makes more sense is to compare the code one most
typically writes. In my case, I always use range() and never use psyco.
But I guess for most of my work with Python performance hasn't been
a issue. I haven't got to write any large systems with Python yet, where
performance starts to matter.

That Python code is bad, it contains range() instead of xrange, the
big loop is in the main code instead of inside a function, uses ==
None, etc. That person can try this (with Psyco), I have changed very
little, the code is essentially the same:

[alex23]

Steven D'Aprano wrote:

In other words, about 20% of the time he measures is the time taken to
print junk to the screen.

Which makes his claim that "all the console outputs have been removed
so that the benchmarking activity is not interfered with by the IO
overheads" somewhat confusing...he didn't notice the output? Wrote it
off as a weird Python side-effect?

I find his reluctance to entertain more idiomatic implementations
particularly telling. It's seems he's less interested in actual
performance comparisons and more into showing that writing static lang
style code in dynamic langs is bad, which isn't really anything new to
anyone anywhere, I would've thought.

All up, this reminds me of last years benchmarking fiasco that
demonstrated Storm's ORM handling being -incredibly-faster than
SQLAlchemy's SQL expression handling, something that just didn't seem
to be born out by user experience. Eventually, Mike Beyer reverse
engineered the benchmarks to discover that, surprise surprise, the
tests -weren't equal-; in one test SQLA was issuing a commit per
insert, while Storm was performing -no commits whatsoever-.

Benchmarks, IMO, are like statistics. You can tweak them to prove
pretty much any position you already take.

[Steven D'Aprano]

On Thu, 07 Aug 2008 00:44:14 -0700, alex23 wrote:

Steven D'Aprano wrote:

>In other words, about 20% of the time he measures is the time taken to
print junk to the screen.

Which makes his claim that "all the console outputs have been removed so
that the benchmarking activity is not interfered with by the IO
overheads" somewhat confusing...he didn't notice the output? Wrote it
off as a weird Python side-effect?

Wait... I've just remembered, and a quick test confirms... Python only
prints bare objects if you are running in a interactive shell. Otherwise
output of bare objects is suppressed unless you explicitly call print.

Okay, I guess he is forgiven. False alarm, my bad.
--
Steven

[Angel Gutierrez]

Steven D'Aprano wrote:

On Thu, 07 Aug 2008 00:44:14 -0700, alex23 wrote:

>Steven D'Aprano wrote:

>>In other words, about 20% of the time he measures is the time taken to
print junk to the screen.

Which makes his claim that "all the console outputs have been removed so
that the benchmarking activity is not interfered with by the IO
overheads" somewhat confusing...he didn't notice the output? Wrote it
off as a weird Python side-effect?

Wait... I've just remembered, and a quick test confirms... Python only
prints bare objects if you are running in a interactive shell. Otherwise
output of bare objects is suppressed unless you explicitly call print.

Okay, I guess he is forgiven. False alarm, my bad.

Well.. there must be somthing because this is what I got in a normal script
execution:

[angel@jaulat test]$ python iter.py
Time per iteration = 357.467989922 microseconds
[angel@jaulat test]$ vim iter.py
[angel@jaulat test]$ python iter2.py
Time per iteration = 320.306909084 microseconds
[angel@jaulat test]$ vim iter2.py
[angel@jaulat test]$ python iter2.py
Time per iteration = 312.917997837 microseconds

iter.py - Original script
iter2.py - xrange instead of range
iter2.py (2nd) - 't=' added

--
Angel

[M8R-n7vorv]

On Aug 7, 6:38*am, [e-mail] wrote:

On Aug 7, 2:05 am, "Jack" <[e-mail]:

I know one benchmark doesn't mean much but it's still disappointing to see
Python as one of the slowest languages in the test:

http://blog.dhananjaynene.com/2008/0...rison-c-java-p...

That Python code is bad, it contains range() instead of xrange, the
big loop is in the main code instead of inside a function, uses ==
None, etc. That person can try this (with Psyco), I have changed very
little, the code is essentially the same:

Yes, this was pointed out in the comments. I had updated the code to
use
xrange and is and is not instead of range, == and !=, which is how
the
benchmark got updated to 192 microseconds. Moving the main loop into
a main function resulted in no discernible difference.

Testing with psyco resulted in a time of 33 microseconds per
iteration.

On my PC the Java version takes 1.17 us, while the C++ version (with
MinGW 4.2.1) takes 9.8 us.
A raw D translation needs 14.34 us, while a cleaned up (that uses
structs, no getters/setters) needs 4.67 us.
I don't know why my C++ is so much slow (doing the same things to the C
++ version doesn't change its running time much).

Bye,
bearophile

Wonder what optimisation level you are using. I to the best of my
recollection used -O3

Cheers,
Dhananjay
http://blog.dhananjaynene.com

[Bruno Desthuilliers]

Steven D'Aprano a écrit :

On Thu, 07 Aug 2008 07:49:45 +0200, Stefan Behnel wrote:

>Jack wrote:

>>I know one benchmark doesn't mean much but it's still disappointing to
see Python as one of the slowest languages in the test:

http://blog.dhananjaynene.com/2008/0...arison-c-java-

python-ruby-jython-jruby-groovy/

>Just ignore that. If the code had been designed for Python from the
start, it would have performed a lot better.

I recommend folks copy and paste his code into an interactive session,
and watch the thousands of <__main__.Person object at 0xb7f18e2cthat
flash onto the screen. You want to know why it's so slow? That's part of
the reason.

This only happens when run in an interactive session.

[M8R-n7vorv]

On Aug 7, 12:44*pm, alex23 <[e-mail]:

Steven D'Aprano wrote:

In other words, about 20% of the time he measures is the time taken to
print junk to the screen.

Which makes his claim that "all the console outputs have been removed
so that the benchmarking activity is not interfered with by the IO
overheads" somewhat confusing...he didn't notice the output? Wrote it
off as a weird Python side-effect?

Gee, I really hope I am a little more capable than writing it off. And
to
answer your question bluntly no I did not notice the output because
there
wasn't any. Run a python program as "python filename.py" instead
of using the interactive console, and you will not get any output
except
exceptions or anything that your code explicitly spews out.

>
I find his reluctance to entertain more idiomatic implementations
particularly telling. It's seems he's less interested in actual
performance comparisons and more into showing that writing static lang
style code in dynamic langs is bad, which isn't really anything new to
anyone anywhere, I would've thought.

I am reluctant to entertain more idiomatic implementations was in the
context of what to me made sense as a part of the exercise. I have
fully
and in great detail explained the rationale in the post itself.

>
Benchmarks, IMO, are like statistics. You can tweak them to prove
pretty much any position you already take.

How's this position of mine for starters :
http://blog.dhananjaynene.com/2008/0...atest-project/
? And if you are not sure, you could browse this as well :
http://blog.dhananjaynene.com/2008/0...mic-languages/

Really how silly can it be when you suggest someone is taking a
position and tweaking the benchmarks to prove a point, when I am
actually quite enthusiastic about python, really like coding using it,
and it was disappointing to me just like to jack who started off this
thread that python did not do so well. In fact I would argue that it
wasn't entirely easy to actually publish the findings given the fact
that these would not have been the findings I would've been wished
for.

Cheers,
Dhananjay
http://blog.dhananjaynene.com

[bearophileHUGS]

jlist:

I think what makes more sense is to compare the code one most
typically writes. In my case, I always use range() and never use psyco.

If you don't use Python 3 and your cycles can be long, then I suggest
you to start using xrange a lot :-) (If you use Psyco you don't need
xrange).
M8R-n7v...:

Wonder what optimisation level you are using. I to the best of my
recollection used -O3

For this program I have used the best (simple) combination of flags I
have found by try & errors:
-O3 -s -fomit-frame-pointer

I'll try adding a freelist, to see (and probably show you) the
results. The HotSpot speeds up this code first of all because its GC
is much better than the current one used by D, because it optimizes
away the getters/setters that D is unable to do, and probably manages
the methods two classes as static ones (while D manages all of them as
virtual).

Bye,
bearophile

[Bruno Desthuilliers]

Stefan Behnel a écrit :

Jack wrote:

>I know one benchmark doesn't mean much but it's still disappointing to see
Python as one of the slowest languages in the test:

http://blog.dhananjaynene.com/2008/0...-jruby-groovy/

Just ignore that. If the code had been designed for Python from the start, it
would have performed a lot better.

Currently it looks like syntax-adapted Java code to me.

Yeps, sure. I don't have time for this now, but I think I would have
choose an itertool based solution here instead of that hand-made linked
list.

Stefan

[M8R-n7vorv]

On Aug 7, 5:05*am, "Jack" <[e-mail]:

I know one benchmark doesn't mean much but it's still disappointing to see
Python as one of the slowest languages in the test:

http://blog.dhananjaynene.com/2008/0...rison-c-java-p...

I was actually disappointed myself with the results from a python
perspective. One thing I did notice was that both ruby and groovy have
substantially improved performance in their new versions. There is a
likelihood that maybe this particular code is not best suited for
pythonic idioms, but the same would've been the case I guess for ruby,
jruby and groovy, yet they performed really well. While I am a
relative newcomer to the python world, from what I have seen, ruby /
jruby and groovy are all making substantial improvements in their
performance (If this post did not include the newer versions of these
languages, python would've been on top of all of them) but I haven't
seen any evidence of the same in upcoming versions of python.

Having said that the same code with psyco works really fast (and beats
all the other dynamic languages v. handsomely). But I did not include
it in the comparisons because psyco is really not a part of core
feature set of python and I was unclear of the implications thereof.

Is there any reason why the psyco is not a part of the core python
feature set ? Is there a particular reason it is better to be kept as
a separate extension ? Are there any implications of using psyco ?

Cheers,
Dhananjay
http://blog.dhananjaynene.com

[M8R-n7vorv]

On Aug 7, 2:52*pm, [e-mail] wrote:

On Aug 7, 6:38*am, [e-mail] wrote:

On Aug 7, 2:05 am, "Jack" <[e-mail]:

I know one benchmark doesn't mean much but it's still disappointing to see
Python as one of the slowest languages in the test:

>http://blog.dhananjaynene.com/2008/0...rison-c-java-p....

That Python code is bad, it contains range() instead of xrange, the
big loop is in the main code instead of inside a function, uses ==
None, etc. That person can try this (with Psyco), I have changed very
little, the code is essentially the same:

Yes, this was pointed out in the comments. I had updated the code to
use
xrange and is and is not instead of range, == and !=, which is how
the
benchmark got updated to 192 microseconds. Moving the main loop into
a main function resulted in no discernible difference.

Testing with psyco resulted in a time of 33 microseconds per
iteration.

I have since updated the post to reflect the python with psyco timings
as well.

[alex23]

On Aug 7, 8:08 pm, [e-mail] wrote:

Really how silly can it be when you suggest someone is taking a
position and tweaking the benchmarks to prove a point [...]

I certainly didn't intend to suggest that you had tweaked -anything-
to prove your point.

I do, however, think there is little value in slavishly implementing
the same algorithm in different languages. To constrain a dynamic
language by what can be achieved in a static language seemed like such
an -amazingly- artificial constraint to me. That you're a fan of
Python makes such a decision even more confusing.

It's great that you saw value in Python enough to choose it for actual
project work. It's a shame you didn't endeavour to understand it well
enough before including it in your benchmark.

As for it being "disappointing", the real question is: has it been
disappointing for you in actual real-world code?

Honestly, performance benchmarks seem to be the dick size comparison
of programming languages.

[cokofreedom]

>

Honestly, performance benchmarks seem to be the dick size comparison
of programming languages.

But in the honour of dick size:

http://shootout.alioth.debian.org/gp...t=all&lang=all
http://shootout.alioth.debian.org/de...t=all&lang=all

[Chris Mellon]

On Thu, Aug 7, 2008 at 8:12 AM, alex23 <wu*****@gmail.comwrote:

On Aug 7, 8:08 pm, [e-mail] wrote:

>Really how silly can it be when you suggest someone is taking a
position and tweaking the benchmarks to prove a point [...]

I certainly didn't intend to suggest that you had tweaked -anything-
to prove your point.

I do, however, think there is little value in slavishly implementing
the same algorithm in different languages. To constrain a dynamic
language by what can be achieved in a static language seemed like such
an -amazingly- artificial constraint to me. That you're a fan of
Python makes such a decision even more confusing.

It's great that you saw value in Python enough to choose it for actual
project work. It's a shame you didn't endeavour to understand it well
enough before including it in your benchmark.

As for it being "disappointing", the real question is: has it been
disappointing for you in actual real-world code?

Honestly, performance benchmarks seem to be the dick size comparison
of programming languages.
-

I actually think that modelling this problem the way he chose to, with
a Person class and by manually popping stuff out of a linked list
instead of more simply representing the alive/dead state of the
soldiers is a poor solution in general. Whenever you talk about
performance, you need to have a context to evaluate it in and you need
an idea of what you're trying to measure and why it's important for
your purposes. A solution which models the soldiers as bits in a
bitfield is going to run much, much, much faster in C/C++/D than the
current OO/linked list one (not to mention in much less space), and
the JIT in Java/C# and probably python with psyco can improve that as
well.

[Steven D'Aprano]

On Thu, 07 Aug 2008 06:12:04 -0700, alex23 wrote:

On Aug 7, 8:08 pm, [e-mail] wrote:

>Really how silly can it be when you suggest someone is taking a
position and tweaking the benchmarks to prove a point [...]

I certainly didn't intend to suggest that you had tweaked -anything- to
prove your point.

I do, however, think there is little value in slavishly implementing the
same algorithm in different languages. To constrain a dynamic language
by what can be achieved in a static language seemed like such an
-amazingly- artificial constraint to me.

I don't know about that... it can be very useful to (say) demonstrate
that Lisp-style lists are fast in Lisp, and slow in Python. Or that
try...except is fast in Python, and slow in Java.

And if your aim is to compare languages, then it's only fair to keep the
algorithm constant. Imagine how we would holler and shout if the
benchmark compared Ruby using Quicksort and Python using Bubblesort.

I guess what some of us are complaining about is that the algorithm
chosen doesn't suit Python's execution model very well, and hence Python
is slow. If the algorithm chosen had suited Python, and hence Python came
up looking really fast, we'd be ecstatic. How about that, hey? *wink*

....

Honestly, performance benchmarks seem to be the dick size comparison of
programming languages.

I can't disagree with that one bit.
--
Steven

[Chris Mellon]

On Thu, Aug 7, 2008 at 9:09 AM, Steven D'Aprano
<st***@remove-this-cybersource.com.auwrote:

On Thu, 07 Aug 2008 06:12:04 -0700, alex23 wrote:

>On Aug 7, 8:08 pm, [e-mail] wrote:

>>Really how silly can it be when you suggest someone is taking a
position and tweaking the benchmarks to prove a point [...]

I certainly didn't intend to suggest that you had tweaked -anything- to
prove your point.

I do, however, think there is little value in slavishly implementing the
same algorithm in different languages. To constrain a dynamic language
by what can be achieved in a static language seemed like such an
-amazingly- artificial constraint to me.

I don't know about that... it can be very useful to (say) demonstrate
that Lisp-style lists are fast in Lisp, and slow in Python. Or that
try...except is fast in Python, and slow in Java.

That's true, but note that the original post doesn't attempt to draw
any conclusions about what's fast or slow from the benchmark, which is
one reason why it's a poor example of benchmarking.

And if your aim is to compare languages, then it's only fair to keep the
algorithm constant. Imagine how we would holler and shout if the
benchmark compared Ruby using Quicksort and Python using Bubblesort.

That's definitely true, and (for example) the Alioth benchmarks are
intended to benchmark specific algorithms for comparisons sake.

I guess what some of us are complaining about is that the algorithm
chosen doesn't suit Python's execution model very well, and hence Python
is slow. If the algorithm chosen had suited Python, and hence Python came
up looking really fast, we'd be ecstatic. How about that, hey? *wink*

The "best" way to implement this problem, as bitfield manipulation,
would actually show python in even worse light. I suspect the main
thing that this benchmark is actually testing is loop overhead, and
secondarily object allocation speed. Python is pretty slow in the
former and reasonable in the latter, so I don't find the results very
surprising at all.

...

>Honestly, performance benchmarks seem to be the dick size comparison of
programming languages.

I can't disagree with that one bit.

As with genitals, the important thing about benchmark comparison is
what you're going to do with the results.

>
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list

[Dhananjay]

On Aug 7, 6:12*pm, alex23 <[e-mail]:

On Aug 7, 8:08 pm, [e-mail] wrote:

Really how silly can it be when you suggest someone is taking a
position and tweaking the benchmarks to prove a point [...]

I certainly didn't intend to suggest that you had tweaked -anything-
to prove your point.

While that was not how I read it first, I assume that was a misjudged
reading.

I do, however, think there is little value in slavishly implementing
the same algorithm in different languages. To constrain a dynamic
language by what can be achieved in a static language seemed like such
an -amazingly- artificial constraint to me. That you're a fan of
Python makes such a decision even more confusing.

It is a sufficiently well understood maxim, that any comparison
between two factors should attempt to keep other factors as equal as
possible (Ceteris Paribus - Everything else being equal), slavishly if
you will. It is my perception that had I changed the algorithms, I
would've been a much higher level of criticism a lot more for
comparing apples and oranges.

I simply could not understand your point with regards to dynamic vs.
static languages. If you are by any chance referring to make the code
a little less OO, I believe the entire exercise could be redone using
a procedural algorithm, and all the languages will run much much
faster than they currently do. But that would be essentially moving
from an OO based design to a procedural design. Is that what you are
referring to (I suspect not .. I suspect it is something else) ? If
not, would certainly appreciate you spending 5 mins describing that.

I am a fan of Python on its own merits. There is little relationship
between that and this exercise.

It's great that you saw value in Python enough to choose it for actual
project work. It's a shame you didn't endeavour to understand it well
enough before including it in your benchmark.

I have endeavoured hard, and maybe there's a shortcoming in the
results of that endeavour. But I haven't quite understood what it is I
haven't understood (hope that makes sense :) )

As for it being "disappointing", the real question is: has it been
disappointing for you in actual real-world code?

I am extremely happy with it. But there definitely are some projects I
worked on earlier I would simply not choose any dynamic language for
(not ruby / not python / not ruby / not groovy). These languages
simply cannot be upto the performance demands required of some
projects.

Honestly, performance benchmarks seem to be the dick size comparison
of programming languages.

Not sure if there is a real life equivalent use case if I was to use
this analogy further. But there are some days (mind you not most days)
one needs a really big dick. Always helpful to know the size.

[Terry Reedy]

M8********@mailinator.com wrote:

Is there any reason why the psyco is not a part of the core python
feature set ?

Psyco was a PhD project. I do not believe the author ever offered it.
Last I knew, it was almost but not completely compatible.

Is there a particular reason it is better to be kept as
a separate extension ?

If he did, he would have to commit to updating it to work with new
version of Python (2.6/3.0) which I don't believe he wants to do. Last
I know, he was working with the PyPy project instead and its JIT
technology. On the otherhand, extensions are also restricted by
Python's release schedule, including no new features in bug-fix
(dot-dot) releases. So library extensions need to be rather stable but
maintained.

Are there any implications of using psyco ?

It compiles statements to machine code for each set of types used in the
statement or code block over the history of the run. So code used
polymorphically with several combinations of types can end up with
several compiled versions (same as with C++ templates). (But a few
extra megabytes in the running image is less of an issue than it was
even 5 or so years ago.) And time spent compiling for a combination
used just once gains little. So it works best with numeric code used
just for ints or floats.

Terry J. Reedy

[bearophileHUGS]

alex23:

Honestly, performance benchmarks seem to be the dick size comparison
of programming languages.

I don't agree:
- benchmarks can show you what language use for your purpose (because
there are many languages, and a scientist has to choose the right tool
for the job);
- it can show where a language implementation needs improvements (for
example the Haskell community has improved one of their compilers
several times thank to the Shootout, the D community has not yet done
the same because the language is in a too much fast evolving phase
still, so performance tunings is premature still);
- making some code faster for a benchmark can teach you how to make
the code faster in general, how CPUs work, or even a some bits of
computer science;
- if the benchmarks are well chosen and well used, they can show you
what are the faster languages (you may say 'the faster
implementations', and that's partially true, but some languages have a
semantic that allows better or much better optimizations). A computer
is a machine useful for many purposes, programming languages allow
some users to make the machine act as they want. So computers and
languages give some power, they allow you to do something that you
can't do without a computer. A language can give you power because it
gives you the ability to write less bug-prone code, or it can give you
more pre-built modules that allow you to do more things in less time,
or it can give you the power to perform computations in less time, to
find a specific solution faster. So Python and C give you different
kinds of power, and they are both useful. Other languages like D/Java
try to become a compromise, they try to give you as much as possible
of both "powers" (and they sometimes succeed, a D/Ocaml program may be
almost as fast as C, while being on the whole much simpler/safer to
write than C code).

Bye,
bearophile

[Dhananjay]

On Aug 7, 11:58*pm, Terry Reedy <[e-mail]:

[e-mail] wrote:
*Are there any implications of using psyco ?

It compiles statements to machine code for each set of types used in the
statement or code block over the history of the run. *So code used
polymorphically with several combinations of types can end up with
several compiled versions (same as with C++ templates). *(But a few
extra megabytes in the running image is less of an issue than it was
even 5 or so years ago.) *And time spent compiling for a combination
used just once gains little. *So it works best with numeric code used
just for ints or floats.

Terry J. Reedy

Sounds to me very much like polymorphic inline caching / site caching,
which
is something I have seen been worked upon and getting introduced in
recent
versions of groovy / jruby and ruby 1.9 (and I read its being looked
at in
Microsoft CLR as well .. but I could be wrong there). I am no expert
in this
so please correct me if I deserve to be.

But if site caching is indeed being adopted by so many dynamic
language
runtime environments, I kind of wonder what makes python hold back
from
bringing it in to its core. Is it that a question of time and effort,
or
is there something that doesn't make it appropriate to python ?

Cheers,
Dhananjay

[sturlamolden]

On Aug 7, 2:05*am, "Jack" <[e-mail]:

I know one benchmark doesn't mean much but it's still disappointing to see
Python as one of the slowest languages in the test:

http://blog.dhananjaynene.com/2008/0...rison-c-java-p...

And how does this reflect the performance of real world Python
programs?

Google uses Python to run the YouTube web site. NASA uses Python to
process image data from the Hubble space telescope. Would they do that
if Python was unbearably sluggish? Do you get faster downloads from a
bittorrent client written in Java (e.g. Azureus) than the original
BitTorrent client (a Python program)?

Using a high level language efficiently is an art. The key is using
Python's built-in data types and extension libraries (e.g. PIL and
NumPy). That is the opposite of what authors of these 'benchmarks'
tend to do.


It seems the majority of these 'benchmarks' are written by people who
think like C++ programmers.

[alex23]

On Aug 8, 2:49*pm, Dhananjay <[e-mail]:

Is it that a question of time and effort,
or is there something that doesn't make it appropriate to python ?

I don't think I've ever seen anyone who has raised concerns about the
speed of python actually offer to contribute to resolving it, so I'm
guessing it's the former.

[cokofreedom]

On Aug 8, 9:08 am, alex23 <[e-mail]:

On Aug 8, 2:49 pm, Dhananjay <[e-mail]:

Is it that a question of time and effort,
or is there something that doesn't make it appropriate to python ?

I don't think I've ever seen anyone who has raised concerns about the
speed of python actually offer to contribute to resolving it, so I'm
guessing it's the former.

Contribute to resolve it? Part of me just wants to say that to "speed"
up python would be such a huge undertaking, the outcome would alter
the language beyond what people liked. Another part thinks, why speed
it up, it is pretty fast presently, and I've rarely seen real-world
applications that need that 80/20 rule applied heavily.

Benchmarks for showing what languages are good at is fine, but in
general most conform to a standard range of speed. I cannot find the
article but there was a good piece about how it takes most programmers
the same time to program in any language. Reading through the code is
another matter, I think Python is faster than most in that respect.

I'd look to increase the worst-case scenario's of Python before trying
to speed up everything. Hell the tim_sort is pretty damn fast.

[Kris Kennaway]

Angel Gutierrez wrote:

Steven D'Aprano wrote:

>On Thu, 07 Aug 2008 00:44:14 -0700, alex23 wrote:

>>Steven D'Aprano wrote:
In other words, about 20% of the time he measures is the time taken to
print junk to the screen.
Which makes his claim that "all the console outputs have been removed so
that the benchmarking activity is not interfered with by the IO
overheads" somewhat confusing...he didn't notice the output? Wrote it
off as a weird Python side-effect?

Wait... I've just remembered, and a quick test confirms... Python only
prints bare objects if you are running in a interactive shell. Otherwise
output of bare objects is suppressed unless you explicitly call print.

Okay, I guess he is forgiven. False alarm, my bad.

Well.. there must be somthing because this is what I got in a normal script
execution:

[angel@jaulat test]$ python iter.py
Time per iteration = 357.467989922 microseconds
[angel@jaulat test]$ vim iter.py
[angel@jaulat test]$ python iter2.py
Time per iteration = 320.306909084 microseconds
[angel@jaulat test]$ vim iter2.py
[angel@jaulat test]$ python iter2.py
Time per iteration = 312.917997837 microseconds

What is the standard deviation on those numbers? What is the confidence
level that they are distinct? In a thread complaining about poor
benchmarking it's disappointing to see crappy test methodology being
used to try and demonstrate flaws in the test.

Kris

[Kris Kennaway]

jlist wrote:

I think what makes more sense is to compare the code one most
typically writes. In my case, I always use range() and never use psyco.
But I guess for most of my work with Python performance hasn't been
a issue. I haven't got to write any large systems with Python yet, where
performance starts to matter.

Hopefully when you do you will improve your programming practices to not
make poor choices - there are few excuses for not using xrange ;)

Kris

[M8R-n7vorv]

On Aug 10, 10:10*pm, Kris Kennaway <[e-mail]:

jlist wrote:

I think what makes more sense is to compare the code one most
typically writes. In my case, I always use range() and never use psyco.
But I guess for most of my work with Python performance hasn't been
a issue. I haven't got to write any large systems with Python yet, where
performance starts to matter.

Hopefully when you do you will improve your programming practices to not
make poor choices - there are few excuses for not using xrange ;)

Kris

And can you shed some light on how that relates with one of the zens
of python ?

There should be one-- and preferably only one --obvious way to do it.

Dhananjay

[cokofreedom]

On Aug 11, 10:55 am, [e-mail] wrote:

On Aug 10, 10:10 pm, Kris Kennaway <[e-mail]:

jlist wrote:

I think what makes more sense is to compare the code one most
typically writes. In my case, I always use range() and never use psyco.
But I guess for most of my work with Python performance hasn't been
a issue. I haven't got to write any large systems with Python yet, where
performance starts to matter.

Hopefully when you do you will improve your programming practices to not
make poor choices - there are few excuses for not using xrange ;)

Kris

And can you shed some light on how that relates with one of the zens
of python ?

There should be one-- and preferably only one --obvious way to do it.

Dhananjay

And that is xrange, but if you need a list range is better :P

[Peter Otten]

M8********@mailinator.com wrote:

On Aug 10, 10:10Â*pm, Kris Kennaway <[e-mail]:

>jlist wrote:

I think what makes more sense is to compare the code one most
typically writes. In my case, I always use range() and never use psyco.
But I guess for most of my work with Python performance hasn't been
a issue. I haven't got to write any large systems with Python yet,
where performance starts to matter.

Hopefully when you do you will improve your programming practices to not
make poor choices - there are few excuses for not using xrange ;)

Kris

And can you shed some light on how that relates with one of the zens
of python ?

There should be one-- and preferably only one --obvious way to do it.

For the record, the impact of range() versus xrange() is negligable -- on my
machine the xrange() variant even runs a tad slower. So it's not clear
whether Kris actually knows what he's doing.

For the cases where xrange() is an improvement over range() "Practicality
beats purity" applies. But you should really care more about the spirit
than the letter of the "zen".

Peter

[M8R-n7vorv]

On Aug 11, 2:09*pm, [e-mail] wrote:

On Aug 11, 10:55 am, [e-mail] wrote:

On Aug 10, 10:10 pm, Kris Kennaway <[e-mail]:

jlist wrote:
I think what makes more sense is to compare the code one most
typically writes. In my case, I always use range() and never use psyco.
But I guess for most of my work with Python performance hasn't been
a issue. I haven't got to write any large systems with Python yet, where
performance starts to matter.

Hopefully when you do you will improve your programming practices to not
make poor choices - there are few excuses for not using xrange ;)

Kris

And can you shed some light on how that relates with one of the zens
of python ?

There should be one-- and preferably only one --obvious way to do it.

Dhananjay

And that is xrange, but if you need a list range is better :P

Interesting to read from PEP-3000 : "Python 2.6 will support forward
compatibility in the following two ways:

* It will support a "Py3k warnings mode" which will warn
dynamically (i.e. at runtime) about features that will stop working in
Python 3.0, e.g. assuming that range() returns a list."

[Kris Kennaway]

Peter Otten wrote:

M8********@mailinator.com wrote:

>On Aug 10, 10:10 pm, Kris Kennaway <[e-mail]:

>>jlist wrote:
I think what makes more sense is to compare the code one most
typically writes. In my case, I always use range() and never use psyco.
But I guess for most of my work with Python performance hasn't been
a issue. I haven't got to write any large systems with Python yet,
where performance starts to matter.
Hopefully when you do you will improve your programming practices to not
make poor choices - there are few excuses for not using xrange ;)

Kris

And can you shed some light on how that relates with one of the zens
of python ?

There should be one-- and preferably only one --obvious way to do it.

For the record, the impact of range() versus xrange() is negligable -- on my
machine the xrange() variant even runs a tad slower. So it's not clear
whether Kris actually knows what he's doing.

You are only thinking in terms of execution speed. Now think about
memory use. Using iterators instead of constructing lists is something
that needs to permeate your thinking about python or you will forever be
writing code that wastes memory, sometimes to a large extent.

Kris

[Peter Otten]

Kris Kennaway wrote:

Peter Otten wrote:

>M8********@mailinator.com wrote:

>>On Aug 10, 10:10 pm, Kris Kennaway <[e-mail]:
jlist wrote:
I think what makes more sense is to compare the code one most
typically writes. In my case, I always use range() and never use
psyco. But I guess for most of my work with Python performance hasn't
been a issue. I haven't got to write any large systems with Python
yet, where performance starts to matter.
Hopefully when you do you will improve your programming practices to
not make poor choices - there are few excuses for not using xrange ;)

Kris
And can you shed some light on how that relates with one of the zens
of python ?

There should be one-- and preferably only one --obvious way to do it.

For the record, the impact of range() versus xrange() is negligable -- on
my machine the xrange() variant even runs a tad slower. So it's not clear
whether Kris actually knows what he's doing.

You are only thinking in terms of execution speed.

Yes, because my remark was made in the context of the particular benchmark
supposed to be the topic of this thread.

Now think about memory use.

Now you are moving the goal posts, But still, try to increase the chain
length. I guess you'll find that the impact of range() -- in
Chain.__init__() at least -- on the memory footprint is also negligable
because the Person objects consume much more memory than the tempory list.

Using iterators instead of constructing lists is something
that needs to permeate your thinking about python or you will forever be
writing code that wastes memory, sometimes to a large extent.

I like and use an iterator/generator/itertools-based idiom myself, but
for "small" sequences lists are quite competitive, and the notion of what a
small list might be is constantly growing.

In general I think that if you want to promote a particular coding style you
should pick an example where you can demonstrate actual benefits.

Peter

[bearophileHUGS]

Peter Otten:

In general I think that if you want to promote a particular coding style you
should pick an example where you can demonstrate actual benefits.

That good thing is that Python 3 has only xrange (named range), so
this discussion will be mostly over ;-)

Bye,
bearophile

[Kris Kennaway]

Peter Otten wrote:

Kris Kennaway wrote:

>Peter Otten wrote:

>>M8********@mailinator.com wrote:

On Aug 10, 10:10 pm, Kris Kennaway <[e-mail]:
jlist wrote:
>I think what makes more sense is to compare the code one most
>typically writes. In my case, I always use range() and never use
>psyco. But I guess for most of my work with Python performance hasn't
>been a issue. I haven't got to write any large systems with Python
>yet, where performance starts to matter.
Hopefully when you do you will improve your programming practices to
not make poor choices - there are few excuses for not using xrange ;)
>
Kris
And can you shed some light on how that relates with one of the zens
of python ?

There should be one-- and preferably only one --obvious way to do it.
For the record, the impact of range() versus xrange() is negligable -- on
my machine the xrange() variant even runs a tad slower. So it's not clear
whether Kris actually knows what he's doing.

You are only thinking in terms of execution speed.

Yes, because my remark was made in the context of the particular benchmark
supposed to be the topic of this thread.

No, you may notice that the above text has moved off onto another
discussion.

Kris