Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Python is faster than C

Reply
Thread Tools

Python is faster than C

 
 
Raymond Hettinger
Guest
Posts: n/a
 
      04-05-2004
> >>>> enumerate('abcdefgh')
> <enumerate object at 0x401a102c: (0, 'a') (1, 'b') (2, 'c') ...>
> >>>> list(_)

> > [(0, 'a'), (1, 'b'), (2, 'c'), (3, 'd'), (4, 'e'), (5, 'f'), (6, 'g'),
> > (7, 'h'), (8, 'i'), (9, 'j'), (10, 'k'), (11, 'l'), (12, 'm'), (13,
> > 'n')]


[Carl Banks]
> I thought this myself, but what if the iterator is computationally
> intensive?


Since no more than three items are displayed, the interactive prompt
will still handle this much better than something like range(10000000)
which takes a while to compute and display.

Besides, everything you do in Python pays a little performance penalty
just to make sure you can break out of computationally intensive
tasks.

For me, these almost never arise at the interactive prompt.

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


Raymond Hettinger
 
Reply With Quote
 
 
 
 
Jacek Generowicz
Guest
Posts: n/a
 
      04-05-2004
"Michel Claveau/Hamster" <(E-Mail Removed)> writes:

> 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".


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.
 
Reply With Quote
 
 
 
 
Paul Prescod
Guest
Posts: n/a
 
      04-05-2004
Raymond Hettinger wrote:

> ...
>
> 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.


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

Paul Prescod



 
Reply With Quote
 
Michael Hudson
Guest
Posts: n/a
 
      04-05-2004
Paul Rubin <http://(E-Mail Removed)> writes:

> Armin Rigo <(E-Mail Removed)> writes:
> > 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.

>
> Maybe there is something to this.


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
 
Reply With Quote
 
Andrew Dalke
Guest
Posts: n/a
 
      04-05-2004
Raymond Hettinger:
> 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


I did say "Should be rare though."

Andrew
http://www.velocityreviews.com/forums/(E-Mail Removed)

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


 
Reply With Quote
 
Christian Tismer
Guest
Posts: n/a
 
      04-05-2004
Michel Claveau/Hamster wrote:

> 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".


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 :^) <(E-Mail Removed)>
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/


 
Reply With Quote
 
Stephen Horne
Guest
Posts: n/a
 
      04-06-2004
On 03 Apr 2004 18:23:11 -0800, Paul Rubin
<http://(E-Mail Removed)> wrote:

>Armin Rigo <(E-Mail Removed)> writes:
>> 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.

>
>Maybe there is something to this.


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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
RE: Wow, Python much faster than MatLab Doran, Harold Python 10 01-01-2007 06:56 PM
Wow, Python much faster than MatLab Stef Mientki Python 11 01-01-2007 02:05 AM
Lisp development with macros faster than Python development?.. seberino@spawar.navy.mil Python 37 07-11-2005 02:10 PM
Re: Python is faster than C Armin Rigo Python 6 04-05-2004 04:33 PM
RE: Python is faster than C Robert Brewer Python 2 04-05-2004 04:16 AM



Advertisments