Fw: [SciPy-dev] scipy.weave versus simple C++.

[Prabhu Ramachandran]

Hi,

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

prabhu