Update gist displaying timing comparisons

[aphearin]

The README provides a link to the following gist, in which timing comparisons are made to several publicly available codes providing pair-counters: https://gist.github.com/manodeep/cffd9a5d77510e43ccf0.

These timings no longer reflect the version of halotools that is up on pip, v0.4. The halotools function called in this gist is no longer in the repo. Its equivalent is npairs_3d, which can be imported as follows:

from halotools.mock_observables.pair_counters import npairs_3d

The API of npairs_3d and npairs is identical, but the performance has improved qualitatively. For Npts = (8e4, 1e5, 5e5, 1e6), the quoted timings are times = (2.109, 2.821, 51.567, 203.456). However, when I use v0.4, I get times = (0.247, 0.351, 6.62, 26.3), about 8x faster than the quoted timings. Note that the v0.4 halotools timings are only ~20% slower than the quoted numbers for "Corrfunc naive", and range from 35%-2.5x slower than "Corrfunc AVX".

Of course, the exact comparison can only be made properly on the same machine, and probably Corrfunc has sped up since these timings, too. So those timings should be updated before more can be said. However, in the Corrfunc README, it is claimed that Corrfunc is "at least an order of magnitude faster than all existing public codes". In light of the above, that no longer seems like a fair claim to make. Please consider revisiting this claim after updating the timings.

[manodeep]

Thanks for pointing it out. I have updated the README. Good work on halotools.

The margin will probably be even closer, Corrfunc has gotten slower since then. Once I update the gist with the new timings, I will close this issue.

[manodeep]

@aphearin I have updated the gist -- the timings are definitely closer. Looks like Corrfunc has improved slightly as well, but that could be simply from using a newer compiler.

However, re-reading your comment - I want to note for the record that the correlation function routines in halotools are supposed to be exact copies of Corrfunc. You obviously know this but anyone else reading these comments likely does not.

My original point about 10x faster pertains to tree approaches that are widely prevalent and are significantly slower. As shown in the gist, the runtime even with optimized tree based codes like kdcount is still quite large compared to the Corrfunc routines.