is c faster?

Chris Barker chrishbarker at
Tue Jun 12 20:04:38 EDT 2001

Alex Martelli wrote:
> whatnot.  I think this is the kind of benefit one
> might expect from a simpleminded 'compiler':-). 

That's why we need a not so simple minded compiler. I have a friend that
keeps harping on the fact that LISP can be as fast as C and as dynamic
as Python. Why can't Python do that?

> > > it's possible) and as big as 1,000%, i.e., 10 times faster (again,
> > > I haven't seen anything more than that on real code, although in
> >
> > I got an approx 100X speedup in my only substantial extension (still not
> > that big). I was already using NumPy arrays, but there was just no way
> > to "vectorize" the whole thing. I may have been able to get a 10X
> > speed-up or so keeping it in just Python if I put some time into it, but
> > I knew I wasn't going to get what I needed, so I went to C.
> So, the roughly-ten-times ratio (between speediest fine-tuned
> Python and C) might still apply here (maybe)...

Maybe. My 10 X speed up in Python is an optimistic guess, based nno my
extensive MATLAB experience. I'm not sure I see the point of testing it,

Another note: in my example, I was making extensive use of NumPy,
whithought it, it would have been hopeless in Python. NumPy arrays are
homogenous sequences, so if my hypothetical not-so-simple-minded
compiler saw a couple of loops like:

A = array(stuff,Float)

#Py2C A:type=Float,rank=2

for i in range(A.shape[0]):
	for j in range(A.shape[1]):
		A[i,j] = A[i,j] *2

It should be able to know what the types are the inside of that loop,
(if you gave it the hint that A was of rank 2 anyway) and turn this into
as fast as C compiled code. Of course, this is trivial, and could be
done with NumPy as A = A*2, or multiply(A,2,A), but more complex cases
would work as well. If Py2C knew about NumPy arrays, and you had a way
to give it a couple of hints, you could save a lot of C coding!

hmm, maybe I'll actaully try to work on this some day!

It seems that the general case of Python knowing about homogenous
sequences could make for far more optimised Python interpreting as well.
for example:

map(string.split, list_of_strings)

could be highly optimized if Python has kept track of the fact that
list_of_strings was in, fact, a list of strings. "All" you'd have to do
is keep a "homogenous" flag with the list, which would get turned off if
you ever added anything non-homogenous to it, and then when "map" was
called, itwould only have to check the type of the first item.

I know that many, if not most, of my lists are homogenous, I imagine
that's true for a lot of folks.


Christopher Barker,
ChrisHBarker at                 ---           ---           --- ---@@       -----@@       -----@@
                                   ------@@@     ------@@@     ------@@@
Oil Spill Modeling                ------   @    ------   @   ------   @
Water Resources Engineering       -------      ---------     --------    
Coastal and Fluvial Hydrodynamics --------------------------------------

More information about the Python-list mailing list