On 5 May 2010, at 08:58, Daniel Carrera wrote: > > I am very pleased that PDL did so well. I'm surprised that NumPy did > so > poorly. Do you have any idea why?
I think Tim Pickering's answer is the right one - it really is insanely slow and it must be due to the loops - and perhaps the OO overhead. > Suggestion: Change the "Python" label to "NumPy". Otherwise it looks > like you are comparing plain Python, so it gives totally the wrong > impression. Well, I chose Python because I was not convinced it really used NumPy very much. And I guess Tim's argument is that it doesn't. > Is there any chance that you might also add results for MATLAB and > Octave? It would be really interesting to see those as well. And > Scilab too. I would love to see those results. It would really give > you > an idea of how the different numerical tools perform on this problem. It would be interesting indeed but not on my todo list - haven't got Matlab et al installed and haven't coded in them for a decade so it would require more time than I can spare right now to code an efficient version. Hopefully someone will add it - it is an open project. > >> 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. > > Are they going to publish your speed results on the website? No. We have been discussing how to do this - probably they would use C+ + as the reference version and then run all codes on the same machine and record relative timings relative to C++. > Are they planning to also include other scientific problems such as > numerical integration? No. This is a teaching aide and a benchmarking test - it is the simplest, useful N-body code you could write and as such a useful little benchmark while being useful for students to learn how to write it up. >> Feel free to improve on the efforts there! > > Actually, I'm not sure that this is a good idea. It is not fair to > compare a highly optimized PDL against an unoptimized NumPy. This is indeed true - but it will be compared against fairly optimised C++ :) > In fact... I think it's more useful to compare the kind of code that a > typical user would actually write. For example, I don't care if PDL is > faster if I have to become a PDL guru and spend a week optimizing the > code in order to get the extra performance. This is true, but for a comparison like this there are several aspects to consider (from a didactic point of view): - How easy is it to write a fast code in an interpretative language - is it faster to write than in C/Fortran etc.? - How readable are the codes in different languages. - Which language lends itself more naturally to parallellisation - For a big simulation that would take 100 days to run it is worth the effort to spend a day optimising it if it runs a factor of 2 faster. - How would the code fit into a larger network of codes? and having different implementations is quite useful, not sure how they would handle that but I'd quite happily see several alternative implementations of the same code in the same language to expose students to different approaches. > What I am more interested in is this: Given a "natural" implementation > of the algorithm, without any deep hacks or geeky optimizations, which > tool has the best performance. After all, if I didn't care about time > spent writing the code, I'd just write everything in C and blow PDL > out > of the water. The reason any of us uses PDL, MATLAB, IDL or NumPy is > precisely because these are easy to use and give acceptable > performance. That is indeed true. So for reference the codes took about the same time to write (20m-1 hr including debugging). This particular problem, bar I/O, is actually very quick to code up in C/C++ or Fortran as well so it is not a good example. However if you want to add a graphics layer, OpenGL interaction etc - then the development speed from scratch for PDL is vastly shorter than C for instance. > > >> 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. > > Yes, that was very interesting. I take it you are not familiar enough > with NumPy to judge if the code is typical or not. Nope, not at all. J. _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
