After removing comments and blank lines, the NumPy code is 164 lines and the PDL code is 105 lines. So the NumPy code is 56% longer.
That's interesting because Python is supposed to be compact because it doesn't have curly brackets. If I removed the close curly bracket from the Perl code, the line count would become 91. So NumPy has 80% more lines of "real" code. Cheers, Daniel. On Wed, 5 May 2010 01:01:35 +0200 Jarle Brinchmann <[email protected]> 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. > > _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
