Python is faster than C

[Jacek Generowicz]

Re: Python is faster than C

"Michel Claveau/Hamster" <No.Spam.mc@No. Spam.mclaveau.N o.Spam.com> writes:
[color=blue]
> Yes, but Psyco is writted in C & Python, and it use an C module.
> Said "Psyco is faster than C", it's like said "Psyco is faster than Psyco".[/color]

You appear to be missing the point completely.

The language used to implement the tools you use is irrelevant. What
is important is the language in which you are programming.

Armin's point is that (in certain circumstances) you can achieve a
significant speedup by one of two ways

- Recode some Python code in C

- import psyco; psyco.full()

Note: in the second case, this is _all_[*] you have to do; it takes
about 2 seconds of work. In the first case it take many
hours/days/weeks of tedious and error-prone work.


The point is: Why code in C when you can get just as good program
speed performance by coding in Python.

Put another way: Why code in a low-level, tedious, rigid,
error-inducing language, when you can get just as good program speed
performance by writing in a high-level, flexible, dynamic, pleasant
language.


[*] Yes, I'm deliberately keeping things simple in order not to draw
attention away from the real point.

[Paul Prescod]

Re: Python is faster than C

Raymond Hettinger wrote:
[color=blue]
> ...
>
> P.S. If some experimentation shows your code to be useful at the
> interactive prompt, please submit a patch on SF so it won't be lost.[/color]

Why put this behaviour in the interactive prompt rather than in repr()?

Paul Prescod

[Josiah Carlson]

Re: Python is faster than C

> Yes, but Psyco is writted in C & Python, and it use an C module.[color=blue]
> Said "Psyco is faster than C", it's like said "Psyco is faster than Psyco".[/color]

You probably meant "C is faster than C". That is a reasonable
statement, but users of Psyco don't need to write anything special
beyond a handful of extra statements in Python.

To the user, Psyco is a module that makes things fast. They wrote
everything in Python, so to them, "Python with Psyco is faster than C"
is far more accurate.

- Josiah

[Michael Hudson]

Re: Python is faster than C

Paul Rubin <http://phr.cx@NOSPAM.i nvalid> writes:
[color=blue]
> Armin Rigo <arigo@tunes.or g> writes:[color=green]
> > Ideally: If you do x=range(100); x[50]='hi' then the interpreter first
> > builds this optimized range representation and assigns it to x; and when
> > in the next statement you modify this list x it says 'oops! i cannot do
> > that with this representation' , so it reverts to an array-like
> > representation (i.e. it creates all 100 elements) and then changes the
> > 50th. No gain here. If on the other hand you only ever do 'easy'
> > things with your list, like iterate over it or read elements, then it
> > can all be done with the range representation, without falling back to
> > the array representation.[/color]
>
> Maybe there is something to this.[/color]

Armin is usually worth listening too :-)

You can find a step towards many of these ideas in PyPy, which should
surprise no one at all...

Cheers,
mwh

--
Indeed, when I design my killer language, the identifiers "foo" and
"bar" will be reserved words, never used, and not even mentioned in
the reference manual. Any program using one will simply dump core
without comment. Multitudes will rejoice. -- Tim Peters, 29 Apr 1998

[Andrew Dalke]

Re: Python is faster than C

Raymond Hettinger:[color=blue]
> Likewise, I program in a less hostile world than Andrew Dalke who has
> to contend with pandora's box iterators which ruin the lives of mortal
> men who think they can call .next() with impunity ;-)[/color]

I did say "Should be rare though." :)

Andrew
dalke@dalkescie ntific.com

(And now you've got me thinking about the Tomb Raider II movie.
Not a bad thing.)

[Christian Tismer]

Re: Python is faster than C

Michel Claveau/Hamster wrote:
[color=blue]
> Hi !
>
> Yes, but Psyco is writted in C & Python, and it use an C module.
> Said "Psyco is faster than C", it's like said "Psyco is faster than Psyco".[/color]

This is not so much of a contradiction.

First of all, Psyco creates assembly code. Not the fastest,
but it enters an area where Python has no entrance, yet.
So what it does is to produce faster code, although not as fast
as C could, but faster than the existing C implementation
of Python.

Seconde, depending on the algorithm you use, even Python can be
faster than C. For example, a few years ago, I implemented
a fast long integer multiplication in Python. At that time,
CPython still had asymptotic behavior of O(n**2), while
the Karatsuba algorithm I used hat something like O(2**1.53).
The difference showed up with several thousands of digits, but
it was remarkable.

Later on, Karatsuba was built into the core, and it became clear
to me that *I* caused this mess, because I had the chance to
get that algorithm into the core, long time ago. I just missed it.

What I'm trying to say: Finally it is always the algorithm.

ciao - chris

--
Christian Tismer :^) <mailto:tismer@ stackless.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/

[Stephen Horne]

Re: Python is faster than C

On 03 Apr 2004 18:23:11 -0800, Paul Rubin
<http://phr.cx@NOSPAM.i nvalid> wrote:
[color=blue]
>Armin Rigo <arigo@tunes.or g> writes:[color=green]
>> Ideally: If you do x=range(100); x[50]='hi' then the interpreter first
>> builds this optimized range representation and assigns it to x; and when
>> in the next statement you modify this list x it says 'oops! i cannot do
>> that with this representation' , so it reverts to an array-like
>> representation (i.e. it creates all 100 elements) and then changes the
>> 50th. No gain here. If on the other hand you only ever do 'easy'
>> things with your list, like iterate over it or read elements, then it
>> can all be done with the range representation, without falling back to
>> the array representation.[/color]
>
>Maybe there is something to this.[/color]

The problem is, once you start where do you stop.

At the moment, Armin suggests optimising the a list consisting of a
single repeating item. But what about optimising a repeating list with
one or two special cases, so that the "x[50]='hi'" above doesn't incur
a penalty?

Consider integer lists - what about optimising arithetic progressions?
Geometric progressions? Progressions with special cases? Progressions
that are the intersection, or union, or whatever of other
progressions?

If the internal implementation doesn't special-case the implementation
of operations on these, all you have is lazy evaluation. But if the
internal implementation adds special-case implementations of
operations, you either end up with an huge number of special case
implementation methods (other parameters can end up with special-case
implementations , not just 'self') or you have to implement what
amounts to a full algebraic solving engine in the Python interpreter.

Or else you can just choose to special case the really important types
and operations, which I believe Python already does to some degree (an
integer is a special case of a long integer, for instance, and an
iterator is a special case of a list with only a subset of the
operations available to a standard list) and provide the programmer
with the tools to easily implement any further special cases that he
may need.


--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk