a few comments: - if you do 'from numpy import *', you shouldn't also 'import math'. those math operators are also provided by numpy for use with numpy objects.
- you might get better performance using the sort and interpolate routines that numpy provides. - you're looping through numpy objects using python loops (e.g. Cluster.get_acc()). that's like looping through pdl objects with perl loops. sloooowwww! - it would be interesting to see how a direct translation of the perldl implementation into numpy would do. basically, take out the OO overhead and just write it as a script like perldl and some of the others. in my experience numpy and pdl are pretty similar in speed and quite fast when used properly. but in either case if you slip and use interpreted loops instead of the vector ops, you'll get hammered. tim On May 5, 2010, at 1:01 AM, Jarle Brinchmann wrote: > Hi folks, > > I saw some mention at some point about comparisons to other interpreted > languages etc, so I thought this might be a fun little tidbit to share: > > Simon Portegies-Zwart and his group at our department (Leiden) has started an > effort to gather N-body codes in various languages to compare. Their web-site > is at http://nbabel.org and you can find source-codes and some background > information there. One day during Easter I decided to code up the algorithm > in a few interpreted languages so I wrote an IDL, PDL and R version of the > N-body code. They are all on the web site and none of them are really > optimised neither wrt. speed nor length (I did not, intentionally, use PP or > link to C routines in IDL or R) - they are really quick hacks. > > Feel free to improve on the efforts there! However what I thought was > interesting is the attached plot - I ran the codes with varying numbers of > particles on my trusty Mac laptop and compared execution time (a bit iffy > since the overheads are quite different, I used wall-clock timing more or > less) for the interpreted codes. > > What is interesting is that PDL came out as the fastest, closely followed by > IDL - I also wrote a version in IDL using loops which is shown as well but I > did not post the code on the web-page. I didn't try with pure Perl - would be > interesting. What is also intriguing is that the numpy implementation on the > web page is quite a lot slower than any of the others. I didn't write that > code but it does use vectorisation, so if this is typical for numpy (I think > not) it would be bad. > > Anyway, feel free to improve on this/implement a PDL::PP version for instance > - or interface to OpenGL to wow with an evolving stellar cluster with > simultaneous 3D graphics. They also seem to have a soft spot for short codes > so if you feel particularly keen: see how short you can make the PDL > implementation (it can be dramatically shortened from what I put on). > > Cheers, > Jarle. > > > <relative_execution_time.pdf> > _______________________________________________ > Perldl mailing list > [email protected] > http://mailman.jach.hawaii.edu/mailman/listinfo/perldl -- +-------------------------------------------------------------------+ | T. E. Pickering, Ph.D. | Southern African Large Telescope | | SALT Astronomer | SAAO | | [email protected] (520) 305-9823 | Observatory Road | | [email protected] +27(0)214606284 | 7925 Observatory, South Africa | +-------------------------------------------------------------------+ overflow error in /dev/null _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
