By: Ray (a.delete@this.b.c), February 20, 2008 3:20 pm
Room: Moderated Discussions
JasonB (no@spam.com) on 2/15/08 wrote:
---------------------------
>David Kanter (dkanter@realworldtech.com) on 2/15/08 wrote:
>---------------------------
>>>Of course "easy" and "efficient" are opposed goals.
>>
>>Of course, but python is a reasonably efficient language and it is easy.
>
>Although Python definitely has its place, and is relatively easy, I think
>it is more of an example in support of Howard's point than a counter-example that you can have both:
>
>http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=python&lang2=gcc
>
>It is definitely efficient enough for a whole bunch of tasks, just like
>a classic Pentium running C code is, but I don't consider
an average of 50 times slower to be "reasonably efficient".
I do performance sensitive work in python, and it is possible to get within shouting distance of C with a little extra work. The numeric and scientific libraries are pretty efficient, so any problem that spends most of its time crunching large arrays is easy to do efficiently in python. For other problems I use psyco or pyrex. Psyco is a JIT specializing recompiler that usually speeds up python code by a factor of two to three. Pyrex lets you interace to C code quickly and easily, or to write a static version of python code that gets compiled to C, but is seen by the rest of your code as a python object.
There is also the "Instant" library that lets you inline C code into your python code.
Usually it is only necessary to optimize a few bottlenecks to speed up the entire program substantially.
For a nice writeup, have a look at:
http://scipy.org/PerformancePython
I have no stake in the current thread, but I think it worth pointing out that the "python is 50x slower than C" argument is somewhat misleading, as it is only true for first-cut solutions to a problem. For not very much effort it is possible to get large speed gains. For me at least, I spend far less time programming in python than I would in C, including the extra time taken to optimize my code.
-Ray
(Who has written more lines of C in his life than in any other language, regrettably)
---------------------------
>David Kanter (dkanter@realworldtech.com) on 2/15/08 wrote:
>---------------------------
>>>Of course "easy" and "efficient" are opposed goals.
>>
>>Of course, but python is a reasonably efficient language and it is easy.
>
>Although Python definitely has its place, and is relatively easy, I think
>it is more of an example in support of Howard's point than a counter-example that you can have both:
>
>http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=python&lang2=gcc
>
>It is definitely efficient enough for a whole bunch of tasks, just like
>a classic Pentium running C code is, but I don't consider
an average of 50 times slower to be "reasonably efficient".
I do performance sensitive work in python, and it is possible to get within shouting distance of C with a little extra work. The numeric and scientific libraries are pretty efficient, so any problem that spends most of its time crunching large arrays is easy to do efficiently in python. For other problems I use psyco or pyrex. Psyco is a JIT specializing recompiler that usually speeds up python code by a factor of two to three. Pyrex lets you interace to C code quickly and easily, or to write a static version of python code that gets compiled to C, but is seen by the rest of your code as a python object.
There is also the "Instant" library that lets you inline C code into your python code.
Usually it is only necessary to optimize a few bottlenecks to speed up the entire program substantially.
For a nice writeup, have a look at:
http://scipy.org/PerformancePython
I have no stake in the current thread, but I think it worth pointing out that the "python is 50x slower than C" argument is somewhat misleading, as it is only true for first-cut solutions to a problem. For not very much effort it is possible to get large speed gains. For me at least, I spend far less time programming in python than I would in C, including the extra time taken to optimize my code.
-Ray
(Who has written more lines of C in his life than in any other language, regrettably)
Topic | Posted By | Date |
---|---|---|
Multicore is unlikely to be the ideal answer. | Anders Jensen | 2008/02/14 04:24 AM |
And the links.. | Anders Jensen | 2008/02/14 04:25 AM |
Disappointing.. | Linus Torvalds | 2008/02/14 10:17 AM |
Disappointing.. | Mark Roulo | 2008/02/14 11:03 AM |
LOL (NT) | Linus Torvalds | 2008/02/14 05:43 PM |
Disappointing.. | David Patterson | 2008/02/15 11:53 AM |
Disappointing.. | Linus Torvalds | 2008/02/15 05:01 PM |
Disappointing.. | anon | 2008/02/15 08:54 PM |
Disappointing.. | JasonB | 2008/02/19 07:45 PM |
Disappointing.. | Ilya Lipovsky | 2008/02/22 06:27 PM |
Disappointing.. | Scott Bolt | 2008/03/16 11:36 AM |
Need for new programming languages | Vincent Diepeveen | 2008/02/19 06:18 AM |
Need for new programming languages | Pete Wilson | 2008/02/24 11:41 AM |
Disappointing.. | Zan | 2008/02/25 10:52 PM |
Disappointing.. | Robert Myers | 2008/02/19 09:47 PM |
Disappointing.. | Fred Bosick | 2008/02/22 06:38 PM |
Disappointing.. | Robert Myers | 2008/03/01 01:17 PM |
The limits of single CPU speed are here. | John Nagle | 2008/03/14 10:55 AM |
The limits of single CPU speed are here. | Howard Chu | 2008/03/15 01:02 AM |
The limits of single CPU speed are here. | slacker | 2008/03/15 08:08 AM |
The limits of single CPU speed are here. | Howard Chu | 2008/03/17 01:47 AM |
The limits of single CPU speed are here. | slacker | 2008/03/17 10:04 AM |
And the links.. | Howard Chu | 2008/02/14 12:58 PM |
I take some of that back | Howard Chu | 2008/02/14 01:55 PM |
And the links.. | Jesper Frimann | 2008/02/14 02:02 PM |
And the links.. | Ilya Lipovsky | 2008/02/15 02:24 PM |
And the links.. | iz | 2008/02/17 10:55 AM |
And the links.. | JasonB | 2008/02/17 07:09 PM |
And the links.. | Ilya Lipovsky | 2008/02/18 01:54 PM |
And the links.. | JasonB | 2008/02/18 10:34 PM |
And the links.. | Thiago Kurovski | 2008/02/19 07:01 PM |
And the links.. | iz | 2008/02/20 10:36 AM |
And the links.. | Ilya Lipovsky | 2008/02/20 03:37 PM |
And the links.. | JasonB | 2008/02/20 06:28 PM |
And the links.. | JasonB | 2008/02/17 06:47 PM |
And the links.. | Ilya Lipovsky | 2008/02/18 02:27 PM |
And the links.. | JasonB | 2008/02/18 10:00 PM |
And the links.. | JasonB | 2008/02/19 03:14 AM |
And the links.. | Ilya Lipovsky | 2008/02/20 04:29 PM |
And the links.. | JasonB | 2008/02/20 06:14 PM |
And the links.. | Ilya Lipovsky | 2008/02/21 11:07 AM |
And the links.. | Howard Chu | 2008/02/14 01:16 PM |
And the links.. | Jukka Larja | 2008/02/15 03:00 AM |
Berkeley View on Parallelism | David Kanter | 2008/02/15 11:41 AM |
Berkeley View on Parallelism | Howard Chu | 2008/02/15 12:49 PM |
Berkeley View on Parallelism | David Kanter | 2008/02/15 03:48 PM |
Berkeley View on Parallelism | Howard Chu | 2008/02/17 05:42 PM |
Berkeley View on Parallelism | nick | 2008/02/17 09:15 PM |
Berkeley View on Parallelism | Howard Chu | 2008/02/18 04:23 PM |
Berkeley View on Parallelism | nick | 2008/02/18 10:03 PM |
Berkeley View on Parallelism | Howard Chu | 2008/02/19 01:39 AM |
Berkeley View on Parallelism | rcf | 2008/02/19 12:44 PM |
Berkeley View on Parallelism | Howard Chu | 2008/02/19 03:25 PM |
Average programmers | anon | 2008/02/18 12:40 PM |
Berkeley View on Parallelism | JasonB | 2008/02/15 08:02 PM |
Berkeley View on Parallelism | JasonB | 2008/02/15 08:02 PM |
Berkeley View on Parallelism | Dean Kent | 2008/02/15 08:07 PM |
Berkeley View on Parallelism | Ray | 2008/02/20 03:20 PM |
Berkeley View on Parallelism | JasonB | 2008/02/20 06:11 PM |
Berkeley View on Parallelism | FritzR | 2008/02/24 03:08 PM |
rubyinline, etc. | nordsieck | 2008/02/22 03:38 PM |
rubyinline, etc. | JasonB | 2008/02/23 05:53 AM |
rubyinline, etc. | nordsieck | 2008/03/02 01:40 AM |
rubyinline, etc. | Michael S | 2008/03/02 02:49 AM |
rubyinline, etc. | Dean Kent | 2008/03/02 07:41 AM |
rubyinline, etc. | Michael S | 2008/03/02 08:19 AM |
rubyinline, etc. | Dean Kent | 2008/03/02 08:30 AM |
rubyinline, etc. | JasonB | 2008/03/02 05:26 PM |
rubyinline, etc. | JasonB | 2008/03/02 06:01 PM |
rubyinline, etc. | Anonymous | 2008/03/03 02:11 AM |
rubyinline, etc. | JasonB | 2008/03/03 09:40 AM |
rubyinline, etc. | Foo_ | 2008/03/09 09:59 AM |
rubyinline, etc. | JasonB | 2008/03/10 01:12 AM |
rubyinline, etc. | Gabriele Svelto | 2008/03/10 02:22 AM |
rubyinline, etc. | JasonB | 2008/03/10 04:35 AM |
C++ for beginners | Michael S | 2008/03/10 05:16 AM |
C++ for beginners | JasonB | 2008/03/10 06:35 AM |
C++ | Michael S | 2008/03/10 04:55 AM |
rubyinline, etc. | Linus Torvalds | 2008/03/03 11:35 AM |
rubyinline, etc. | Dean Kent | 2008/03/03 02:35 PM |
rubyinline, etc. | JasonB | 2008/03/03 03:57 PM |
rubyinline, etc. | Dean Kent | 2008/03/03 08:10 PM |
rubyinline, etc. | Michael S | 2008/03/04 01:53 AM |
rubyinline, etc. | Dean Kent | 2008/03/04 07:51 AM |
rubyinline, etc. | Michael S | 2008/03/04 08:29 AM |
rubyinline, etc. | Dean Kent | 2008/03/04 08:53 AM |
rubyinline, etc. | Michael S | 2008/03/04 11:20 AM |
rubyinline, etc. | Dean Kent | 2008/03/04 02:13 PM |
read it. thanks (NT) | Michael S | 2008/03/04 04:31 PM |
efficient HLL's | Patrik Hägglund | 2008/03/04 03:34 PM |
efficient HLL's | Wes Felter | 2008/03/04 09:33 PM |
efficient HLL's | Patrik Hägglund | 2008/03/05 01:23 AM |
efficient HLL's | Michael S | 2008/03/05 02:45 AM |
efficient HLL's | Wilco | 2008/03/05 05:34 PM |
efficient HLL's | Howard Chu | 2008/03/05 07:11 PM |
efficient HLL's | Wilco | 2008/03/06 02:27 PM |
efficient HLL's | anon | 2008/03/05 08:20 AM |
And the links.. | Groo | 2008/02/17 04:28 PM |
And the links.. | Vincent Diepeveen | 2008/02/18 02:33 AM |