how fast is Python?

Discussion in 'Python' started by dan, Aug 20, 2003.

  1. dan

    dan Guest

    It would be an understatement to say I love this language. What used
    to take me all day now takes 3 hours, and I can spend the rest of the
    time on my bike thinking about the problems from a high level instead
    of wrestling with arcane compiler problems, etc.

    Back in the day, when looking at an interpreted language (or even
    compiled ones) the first thing I would ask is, "how fast is it?"
    These days, with 1ghz processor machines selling for < $500, it seldom
    comes up as an issue. And of course in Py's case you can always
    'extend and embed' your core routines for fun & profit.

    However, there are definitely cases where a lot of code would need to
    be optimized, and so I ask the question: How fast is Python, compared
    to say a typical optimizing C/C++ compiler?

    I realize this is a more complex question than one might think. There
    are various types of code constructs that might end up with different
    efficiency issues. I guess what I'm asking is, in a general sense,
    how fast is it now for typical code sequences, and -- importantly --
    what could be done to optimize the interpreter? Are any parts written
    in assembly? Could things like hash tables be optimized with parallel
    units such as MMX? Etc.

    Please advise.
    dan, Aug 20, 2003
    #1
    1. Advertising

  2. Python is fast enough for me, especially 2.3.

    Profile & code slow parts as C extensions.
    Include your own assembly there if so desired.

    Investigate Psyco. There was one example on this
    newsgroup that showed that Python+psyco actually
    outperformed the same program in compiled C.

    --Irmen
    Irmen de Jong, Aug 20, 2003
    #2
    1. Advertising

  3. dan

    Andrew Dalke Guest

    dan:
    > However, there are definitely cases where a lot of code would need to
    > be optimized, and so I ask the question: How fast is Python, compared
    > to say a typical optimizing C/C++ compiler?


    Highly dependent on context. I use factor of 10-20 as a ballpark,
    with factor of 100 for some things like low-level string processing.
    Eg, I've got a pure Python regexp engine which clocks at about x80
    slower than sre.

    > what could be done to optimize the interpreter? Are any parts written
    > in assembly? Could things like hash tables be optimized with parallel
    > units such as MMX? Etc.


    Spend a few tens of millions on developing just-in-time compilers
    and program analysis. That worked for Java.

    Nothing is written in assembly, except that C can be considered
    a portable assembly language. Otherwise ports to different platforms
    would be a lot more difficult.

    I would hope that the C compiler could optimize the C code
    sufficiently well for the hardware, rather than tweaking the
    code by hand. (Though I know of at least one person who sent
    in a patch to gcc to optimize poorly written in-house code.
    Rather circuitous way to fix things, but it worked.)

    Andrew
    Andrew Dalke, Aug 20, 2003
    #3
  4. Alex Martelli wrote:
    > Irmen de Jong wrote:


    >>Investigate Psyco. There was one example on this
    >>newsgroup that showed that Python+psyco actually
    >>outperformed the same program in compiled C.

    >
    >
    > I think (but will gladly stand corrected if I'm wrong!) that
    > this is a misinterpretation of some code I posted -- the
    > C code (crazily) used pow(x,2.0), the Python one (sanely)
    > x*x -- within a complicated calculation of erf, and that
    > one malapropism in the C code was what let psyco make
    > faster code than C did. With C fixed to use x*x -- as any
    > performance-aware programmer will always code -- the
    > two ran neck to neck, no advantage to either side.


    Whoops, I missed that :) Thanks for the clarification.

    Nevertheless, a Psyco-optimized piece of Python code
    that runs as fast as compiled C is still very impressive
    to me. I know that JIT compiler technology theoretically
    could produce better optimized code than a static optimizing
    compiler, but am happy already if it reaches equal level :)

    --Irmen de Jong
    Irmen de Jong, Aug 21, 2003
    #4
  5. Irmen de Jong wrote:
    ...
    > Nevertheless, a Psyco-optimized piece of Python code
    > that runs as fast as compiled C is still very impressive
    > to me. I know that JIT compiler technology theoretically
    > could produce better optimized code than a static optimizing
    > compiler, but am happy already if it reaches equal level :)


    If anybody does have an actual example (idealy toy-sized:)
    where psyco's JIT does make repeatably faster code than a
    C compiler (well-used, e.g. -O3 for gcc, NOT just -O...!-)
    I'd be overjoyed to see it, by the way.


    Alex
    Alex Martelli, Aug 21, 2003
    #5
  6. dan

    David McNab Guest

    On Thu, 21 Aug 2003 06:40:04 +0200, Michael Peuser paused, took a deep
    breath, then came out with:

    > A bottleneck can be Tkinter. Use something different then (Qt, wx)..


    Wow!

    I've found wx to be way slower than Tkinter.

    On a P133 running Win98, a McMillan-compiled prog using wx took twice as
    long to start up as a similar prog implemented in Tkinter.
    David McNab, Aug 21, 2003
    #6
  7. dan

    Mark Carter Guest

    > > However, there are definitely cases where a lot of code would need to
    > > be optimized, and so I ask the question: How fast is Python, compared
    > > to say a typical optimizing C/C++ compiler?


    I did a benchmark some time ago (nothing optimised):

    PURPOSE:
    The purpose of this technical report is to gauge the relative speed of
    the languages: VB, VBA, Python 2.2, C++, and Fortran.


    SUMMARY RESULTS:
    It was discovered that uncompiled VB code in VB 6.0 ran at the same
    speed as VBA code in Excel. It was half the speed of compiled VB code,
    5 times the speed of Python, and 1/20th the speed of C++/Fortran.

    METHOD:

    The following algorithm was implemented in each of the target
    languages:

    X = 0.5
    For I = 1 to 108
    X = 1 – X* X
    Next

    Timings were made for the execution. The following results were
    obtained:

    Language Timing (seconds)
    VB – uncompiled 74
    VB – compiled 37
    VBA – Excel 75
    Python 401
    C++ - debug version 4
    C++ - release version 3
    Fortran 3


    The timings for Fortran are approximate. The execution time had to be
    timed with a stopwatch because timing functions could not be
    discovered.
    Mark Carter, Aug 21, 2003
    #7
  8. dan

    Neil Padgen Guest

    On Wednesday 20 August 2003 21:19, Irmen de Jong wrote:
    > Investigate Psyco.


    On the strength of this thread, I investigated Psyco. Results of a
    very quick investigation with the following program:

    -----------------------------------------
    def calcPi(iterations):
    pi4 = 1.0
    for i in xrange(1, iterations):
    denominator = (4*i)-1
    pi4 = pi4 - 1.0/denominator + 1.0/(denominator+2)
    return pi4 * 4.0

    def timethis(func, funcName):
    import sys
    try:
    i = int(sys.argv[1])
    except:
    i = 1000000
    import time
    start = time.time()
    pi = func(i)
    end = time.time()
    print "%s calculated pi as %s in %s seconds" % (funcName, pi, end
    - start)

    def main():
    timethis(calcPi, 'calcPi')
    timethis(speedyPi, 'speedyPi')

    import psyco
    speedyPi = psyco.proxy(calcPi)

    if __name__ == '__main__':
    main()
    -----------------------------------------

    produced the following results on a 1.7GHz P4 running FreeBSD 4.8:

    > python2.2 pi.py

    calcPi calculated pi as 3.14159315359 in 3.87623202801 seconds
    speedyPi calculated pi as 3.14159315359 in 0.790405035019 seconds

    -- Neil
    Neil Padgen, Aug 21, 2003
    #8
  9. dan

    Peter Hansen Guest

    dan wrote:
    >
    > However, there are definitely cases where a lot of code would need to
    > be optimized, and so I ask the question: How fast is Python, compared
    > to say a typical optimizing C/C++ compiler?


    C is roughly 10 to 100 times faster than Python, though of course it's
    easy to find cases outside of this range, on either side.

    I use 30 as a general overall rule of thumb, in the exceptionally
    few cases where it seems relevant how much faster C would be.

    And in those very few cases, so far, I have consistently concluded
    I'm happy enough with the speed of Python given that the speed of
    *development* in Python is easily 5 to 10 times faster than the
    speed of development in C. (And again, it's easy to find cases
    outside of this range, on either side...)

    -Peter
    Peter Hansen, Aug 21, 2003
    #9
  10. Mark Carter wrote:
    ...
    > The following algorithm was implemented in each of the target
    > languages:
    >
    > X = 0.5
    > For I = 1 to 108
    > X = 1 – X* X
    > Next
    >
    > Timings were made for the execution. The following results were
    > obtained:
    >
    > Language Timing (seconds)
    > VB – uncompiled 74
    > VB – compiled 37
    > VBA – Excel 75
    > Python 401
    > C++ - debug version 4
    > C++ - release version 3
    > Fortran 3


    Interesting. One wonders what and where you measured, e.g:

    [alex@lancelot gmpy]$ cat a.cpp
    int main()
    {
    double X = 0.5;
    for(int i = 0; i < 108; i++)
    X = 1 + X * X;
    return 0;
    }

    [alex@lancelot gmpy]$ g++ -O3 a.cpp
    [alex@lancelot gmpy]$ time ./a.out
    0.01user 0.00system 0:00.00elapsed 333%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (186major+21minor)pagefaults 0swaps

    i.e., it's just too fast to measure. Not much better w/Python...:

    [alex@lancelot gmpy]$ cat a.py

    def main():
    X = 0.5
    for i in xrange(108):
    X = 1 + X*X

    main()
    [alex@lancelot gmpy]$ time python -O a.py
    0.03user 0.01system 0:00.15elapsed 26%CPU (0avgtext+0avgdata 0maxresident)k
    0inputs+0outputs (452major+260minor)pagefaults 0swaps

    i.e., for all we can tell, the ratio COULD be 100:1 -- or just about
    anything else! Perhaps more details are warranted...


    Alex
    Alex Martelli, Aug 21, 2003
    #10
  11. dan

    Guest

    dan wrote:
    >
    > I realize this is a more complex question than one might think. >
    > Please advise.


    Consider the percentage of software projects for which the total
    number of hours of developer time over the life of the project
    exceeds the total number of hours of CPU run time during productive
    use of the software produced. This percentage is abysmally high.
    Python works on improving it on both ends, by both reducing the
    developer time and increasing the number of hours of productive
    use. What more could you want?


    Al
    , Aug 21, 2003
    #11
  12. dan

    Andrew Dalke Guest

    Travis Whitton
    > [the shootout] is probably the best site on the
    > internet for side-by-side language comparisons:


    Though there's also pleac.sf.net which isn't for timings
    but does show how the different languages would be
    used to do the same thing.

    And I see my Python contribution still leads the
    pack in % done.

    Andrew
    Andrew Dalke, Aug 21, 2003
    #12
  13. "David McNab" <postmaster@127.0.0.1> schrieb im Newsbeitrag
    news:pan.2003.08.21.09.07.20.100414@127.0.0.1...
    > On Thu, 21 Aug 2003 06:40:04 +0200, Michael Peuser paused, took a deep
    > breath, then came out with:
    >
    > > A bottleneck can be Tkinter. Use something different then (Qt, wx)..

    >
    > Wow!
    >
    > I've found wx to be way slower than Tkinter.
    >
    > On a P133 running Win98, a McMillan-compiled prog using wx took twice as
    > long to start up as a similar prog implemented in Tkinter.


    Of course! The wx DLL is mor ethan 6 MB whilest Tcl/Tk still keeps around 1.
    I am not talking about start up. When you have ever used a Canvas with a
    600x800 Image oder with a thousend items or a TIX HList with a dozend
    diffently styled columns you might know WHAT I am talking about.

    Even with less filled widgets, most of what you perceive as "lazy" with e.g.
    games is generally not the Python but the Tcl interpreter. Pygame shows that
    you can dio fast visualisation with Python.

    Kindly
    Michael P
    Michael Peuser, Aug 21, 2003
    #13
  14. dan

    Jeff Epler Guest

    I don't know what Mark Carter wanted to measure either, but I'd like to
    mention that when I compile "a.cpp" on my system with the flags Alex
    used, the generated code doesn't even include any floating-point
    arithmetic. The compiler was able to deduce that X was dead after the
    loop, and that its computation had no side-effects. I'm a little
    surprised that the compiler didn't completely remove the loop, but it's
    still there. "i" isn't there either, instead there's a counter that
    begins at 107, decrements and terminates the loop when it reaches -1.
    And if I use the directive to unroll loops, the logic is the same except
    that the counter decreases by 18 each time instead of 1.

    .... and anyway, this modified code (which does actually compute X when
    compiled on my system) aborts with a floating point overflow error.
    As far as I can tell, your program would be computing a value on the
    order of 10^(3x10^31)...

    Ah, the joy of writing the proverbial good benchmark.

    Jeff

    #include <fpu_control.h>
    fpu_control_t __fpu_control = _FPU_IEEE &~ _FPU_MASK_OM;

    double Y;

    int main()
    {
    double X = 0.5;
    for(int i = 0; i < 108; i++)
    X = 1 + X * X;
    Y = X;
    return 0;
    }
    Jeff Epler, Aug 21, 2003
    #14
  15. "Neil Padgen" <> schrieb im Newsbeitrag
    news:bi2ki9$pai$...
    > On Wednesday 20 August 2003 21:19, Irmen de Jong wrote:
    > > Investigate Psyco.

    >


    [...]
    >
    > produced the following results on a 1.7GHz P4 running FreeBSD 4.8:
    >
    > > python2.2 pi.py

    > calcPi calculated pi as 3.14159315359 in 3.87623202801 seconds
    > speedyPi calculated pi as 3.14159315359 in 0.790405035019 seconds
    >
    > -- Neil


    This is certainly correct. My experiance with more general programs running
    for a few minutes shows that you can expect a speed-up of two. This is still
    impressiv when you have your results in 5 instead of 10 minutes..

    Kindly
    Michael P
    Michael Peuser, Aug 21, 2003
    #15
  16. dan

    dan Guest

    Peter Hansen <> wrote in message news:<>...
    ....
    > And in those very few cases, so far, I have consistently concluded
    > I'm happy enough with the speed of Python given that the speed of
    > *development* in Python is easily 5 to 10 times faster than the
    > speed of development in C. (And again, it's easy to find cases
    > outside of this range, on either side...)
    >

    I pretty much agree. The point of my question was not to knock Python
    -- I'm simply curious how fast, _in_principle_, a language like Python
    could be made to run.

    I've looked at Psyco and Pyrex, I think both are interesting projects
    but I doubt anything in the Py world has had nearly the kind of
    man-hours devoted to optimization that Java, C++, and probably C# have
    had.
    dan, Aug 22, 2003
    #16
  17. dan

    Andrew Dalke Guest

    Jeff Epler:
    > As far as I can tell, your program would be computing a value on the
    > order of 10^(3x10^31)...


    > for(int i = 0; i < 108; i++)
    > X = 1 + X * X;


    He had 1-X*X. Since X starts at 0.5, this will never go leave
    the range 0 to 1.

    Andrew
    Andrew Dalke, Aug 22, 2003
    #17
  18. dan

    Peter Hansen Guest

    dan wrote:
    >
    > Peter Hansen <> wrote in message news:<>...
    > ...
    > > And in those very few cases, so far, I have consistently concluded
    > > I'm happy enough with the speed of Python given that the speed of
    > > *development* in Python is easily 5 to 10 times faster than the
    > > speed of development in C. (And again, it's easy to find cases
    > > outside of this range, on either side...)
    > >

    > I pretty much agree. The point of my question was not to knock Python
    > -- I'm simply curious how fast, _in_principle_, a language like Python
    > could be made to run.
    >
    > I've looked at Psyco and Pyrex, I think both are interesting projects
    > but I doubt anything in the Py world has had nearly the kind of
    > man-hours devoted to optimization that Java, C++, and probably C# have
    > had.


    Oh, I completely misinterpreted the question then. I thought you wanted
    practical information.

    _In principle_, (which I'll interpret as "in theory"), Python can be made
    to run even faster than C or C++.

    In practice, nobody has been able to prove or disprove that theory yet...

    ;-)

    -Peter
    Peter Hansen, Aug 22, 2003
    #18
  19. On 20 Aug 2003 13:08:20 -0700, rumours say that
    (dan) might have written:

    >How fast is Python, compared
    >to say a typical optimizing C/C++ compiler?


    The most important time for me is the time *I* invest in a program,
    since when it's run-time, I can always do other stuff while some slave
    computer follows my orders. So, I'll reply only about development time
    and I'll quote the Smiths: "How Soon Is Now?" :)
    --
    TZOTZIOY, I speak England very best,
    Microsoft Security Alert: the Matrix began as open source.
    Christos TZOTZIOY Georgiou, Aug 23, 2003
    #19
  20. Alex Martelli <> wrote in message news:<qJ%0b.116361$>...
    > Irmen de Jong wrote:
    > ...
    > > Nevertheless, a Psyco-optimized piece of Python code
    > > that runs as fast as compiled C is still very impressive
    > > to me. I know that JIT compiler technology theoretically
    > > could produce better optimized code than a static optimizing
    > > compiler, but am happy already if it reaches equal level :)

    >
    > If anybody does have an actual example (idealy toy-sized:)
    > where psyco's JIT does make repeatably faster code than a
    > C compiler (well-used, e.g. -O3 for gcc, NOT just -O...!-)
    > I'd be overjoyed to see it, by the way.
    >
    >
    > Alex


    Actually, as I posted in the C sharp thread of few weeks ago, on my
    machine psyco+psyco was FASTER than C. The numbers quoted are for C
    with
    option -o, but even for -o3 psyco was still faster and, notice, with
    pow(x,2) replacedby x*x in C too. I would be happy if somebody can
    reproduce that. Here is the link:

    http://groups.google.it/groups?hl=i...lang.python.*&meta=group%3Dcomp.lang.python.*

    Michele Simionato, Ph. D.

    http://www.phyast.pitt.edu/~micheles
    --- Currently looking for a job ---
    Michele Simionato, Aug 23, 2003
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    0
    Views:
    636
  2. Mark Carter

    how fast is Python?

    Mark Carter, Aug 21, 2003, in forum: Python
    Replies:
    0
    Views:
    353
    Mark Carter
    Aug 21, 2003
  3. Michele Simionato

    Python is darn fast (was: How fast is Python)

    Michele Simionato, Aug 23, 2003, in forum: Python
    Replies:
    13
    Views:
    544
  4. mir nazim
    Replies:
    7
    Views:
    531
    Brian Kelley
    Nov 24, 2003
  5. Juha Nieminen
    Replies:
    22
    Views:
    981
    Kai-Uwe Bux
    Oct 12, 2007
Loading...

Share This Page