Jarle, Neat stuff.
The PDL/IDL split has been known anecdotally for a long time -- the PP engine really does well at generating vector code, and RSI have long touted the efficiency of IDL vector code. Both languages are probably RAM bound and not significantly different in speed when they are inside large(r than cache) vector operations. IDL's interpreter, on the other hand, really blows chunks compared to Perl's. It's not legally possible to know what IDL is doing, but I suspect it merely tokenizes, rather than JIT-compiling, the interpreted code, so the interpreter has to do a lot more work at run- time (work that Perl caches up-front). The python curve is (as Daniel pointed out) surprising - folks in my office keep advocating switching to Python, largely because it is alleged to be screamingly fast. I'm not enough of a python guy to know if there are simple optimizations that are being ignored... Cheers, Craig On May 4, 2010, at 5:01 PM, 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 _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
