Hi,
"eric" == eric <eric@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