You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was browsing through the code and I accidentally stumbled upon the function _fast_cross_3d referenced in the URL above.
I don't think that this implementation is faster than numpy's implementation of the cross product - for example, please take a look at the following code:
In [1]: %timeit cross_3d_pysurfer(x, y)
Out[1]: 34.7 ms ± 3.9 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)
In [2]: %timeit cross_3d_numpy(x, y)
Out[2]: 29.4 ms ± 4.63 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)
A potential, but very small speed up could be achieved by using np.stack instead of np.c_ because it has some cool compiled numpy's stuff which np.c_ lacks. For example:
In [3]: %timeit cross_3d_pysurfer_modified(x, y)
Out[3]: 28.4 ms ± 3.95 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)
I didn't want to open a PR because I really don't know if this is even relevant anymore or if the difference in a few ms is that important, but still wanted to let you know :)
The text was updated successfully, but these errors were encountered:
FYI I think the motivation was that numpy's cross did not originally broadcast. Now that it does we could replace it. But we'd want to make sure that it doesn't require a super new NumPy (e.g., 1.23) and works with some older ones (back to 1.19 or 1.20). But from looking at the NumPy doc it seems like it was supported all the way back in 1.13, so yes we could change this!
Relevant code:
PySurfer/surfer/utils.py
Lines 179 to 213 in a5a019e
Hi,
I was browsing through the code and I accidentally stumbled upon the function
_fast_cross_3d
referenced in the URL above.I don't think that this implementation is faster than
numpy
's implementation of the cross product - for example, please take a look at the following code:When I time it, I get the following results:
A potential, but very small speed up could be achieved by using
np.stack
instead ofnp.c_
because it has some cool compilednumpy
's stuff whichnp.c_
lacks. For example:I didn't want to open a PR because I really don't know if this is even relevant anymore or if the difference in a few ms is that important, but still wanted to let you know :)
The text was updated successfully, but these errors were encountered: