Fw: [SciPy-dev] scipy.weave versus simple C++.
prabhu at aero.iitm.ernet.in
Fri Jan 11 21:57:40 CST 2002
>>>>> "eric" == eric <eric at scipy.org> writes:
eric> Here is a near verbatim conversion of your laplace to use
eric> Python/Inline. I didn't spend much time, and there are
eric> errors. The results don't match. You'll get the general
eric> idea from it though.
This is wonderful! Thanks *very* much. I spent the last hour and a
half looking over this code over a text terminal (since my desktop's
keyboard is a pain to use). I fixed the errors. I didnt realize that
it would be so easy to inline the innermost loop. The
Numeric/copy/transpose example got me confused a bit.
Later on today I'll try to create a simple Python version of your and
my code and maybe write up a small document on the different ways to
solve this problem using Python (i.e. slow, numeric, inline and
blitz). I'll remove all the fancy stuff and clean up the Python code
and keep the sample c++ example the way it is. I think it should make
for a decent benchmark and introductory document to anyone interested
in Python and speed. A comparison with c++ would really prove the
point as to why developing with Python is a great idea. :)
eric> I used blitz arrays because they're indexing is kinda like
eric> double** indexing so the conversion was easy. Standard
eric> Numeric arrays don't have the pointer arrays to the rows
eric> that C uses, so your code wouldn't translate easily to it
eric> without macros or calculating offsets -- you could do this
eric> though. I'm not sure that indexing blitz arrays is as fast
eric> as indexing normal arrays -- this example would suggest not:
Yes, at this point in time I'm happy with the simplest solution. The
inline code is pretty much next to trivial -- just a translation to
straight C++. Thats really cool! Great job, Eric!!
eric> 500x500, 100 iterations, PII 850 laptop, W2K, gcc-2.95.2
eric> laplace.py: 3.47 seconds laplace.cxx: 2.34 seconds
Wow! Thats not bad at all! Considering that the example is completely
scriptable and trivially extendible with a zillion other Python tools
(the standard lib, scipy.plt, gracePlot, mayavi whatnot).
eric> The Python calling overhead should be close to nil, so there
eric> is no reason why the python version should be slower, other
eric> than the fact that I used blitz arrays and indexing. But
eric> the current implementation still pays a 50% penalty for
eric> using Python.
Hmm, maybe it has something to do with the way we are looping. I'll
experiment with all this later and mail the list. However, a 50%
penalty isnt so bad at all, I guess most folks can live with it.
I have more generic questions which I'll leave for later. For now I
have enough to do and think about.
Eric, my hearty congratulations to you on weave! Great job!!
More information about the Scipy-dev