Project Roadmap

[seanlaw]

Below are some opportunities for future development:

• SCRIMP++
• GPU-STUMP
• top-K
• GPU-MSTUMP
• MPdist
• snippets
• FLOSS Semantic Segmentation YouTube
• STOMPI Incremental STOMP (not interactive)

[wuxianliang]

Is using RapidsAI (dask-cupy & dask-cudf) faster than numpy? It can not be achieved by replacing numpy with cupy right now.

[seanlaw]

@wuxianliang I don't have any experience with RapidsAI yet but it would be interesting to see if there is an opportunity to involve @datametrician and the RapidsAI team where appropriate and also @zpzim who already has a scalable GPU implementation. There are definitely some complexities that might make things too complicated or beyond the scope.

I haven't put a ton of thought into this so I reserve the right to take any of these points back but, off the top of my head, my biggest concerns are:

• Adding unnecessary code complexity
• Maintaining GPU code
• Ease of installation (optimally, it should take a minute or less from finding this repo to analyzing your data)
• Ease of usage
• Readability of the code

[datametrician]

@quasiben @mrocklin @kkraus14. @seanlaw let's look into this and get back to you. CuPy may "just work" without too much complexity.

[mrocklin]

With the __array_function__ protocol recently landed in NumPy I suspect that many of the operations in core.py would just work without code change. Some operations though, like rolling_window, probably wouldn't (my guess is that cupy doesn't support stride tricks). For this one could probably use Numba to write a CUDA kernel in a small number of lines, and then use something like functools.singledispatch to switch between implementations. I think that this would satisfy the concerns about maintainability above. There wouldn't be much GPU code, and that code would be both readable-ish and well isolated from the mainline CPU code.

Taking a step back though, @seanlaw are users of stumpy currently compute bound by anything to the point of frustration? If so, what operations do they care about?

From my perspective this codebase is nice in that it's fairly small and well formed around a core set of operations, most of which are "just numpy". It would be an interesting case study to see how light a touch one could have in GPU-ifying a codebase, and in the community concerns that come up during that process (@seanlaw 's list above is great).

[seanlaw]

Thanks @mrocklin. I looked at CuPy two years ago when it first came out so my info on it is outdated and I will need to find some time to brush up on its advancements. core.py implements some basic utility functions to avoid redundancy but the heaviest part of the computation actually lives in:

• stump.py (locally parallel but for a single time series)
• stumped.py (locally parallel and distributed for a single time series)
• mstump.py (locally parallel but for multiple time series - "multidimensional")
• mstumped.py (locally parallel and distributed for multiuple time series).

So, modules that end in "ed" implies that it can use Dask for distributed computing but all of them utilize Numba for parallel computing (not NumPy). According to the original publications (not written by me), these are the four modules that should be pushed onto the GPU as this is the expensive part/bottleneck of the computation. From my experience, there are key for loops that cannot be eliminated and therefore I couldn't immediately figure out how to use CuPy with it.

As it relates to "user frustration", I think the timing calculations found in the README may help to paint a more accurate story. Anecdotally (based on my interactions with folks who run long molecular dynamics (MD) simulations or are dealing with many, many shorter financial time series data), I would split the users up into three groups based on their time series length:

• Short - Less than 10,000 data points in their time series
• Medium - 10,000 - 1,000,000 data points in their time series
• Long - 1,000,000+ data points in their time series OR many, many medium length time series and therefore require the multi-dimensional calculation

Based on the timing calculations (see README), one can do short calculations on a modest 2-core laptop fairly easily and be able to get immediate feedback within seconds to minutes. I would argue that the short calculations are often less interesting as it may not contain enough data for good comparison. However, for medium calculations even on 16 CPUs, it would take over 40 hours to process 100,000 data points and, more importantly, this amount of wait time tends to slow down the productivity of the scientist/data scientist who is looking for quicker/immediate feedback so that they can readjust their analytics focus. Anything in the long range definitely requires setting up a larger Dask cluster or the use of GPUs and having a few million data points in a single time series is fairly commonplace in the MD world where they are already using GPUs to generate their data.

So, all users will care most about computing the matrix profile and this is achieved by calling either the stumpy.stump, stumpy.stumped, stumpy.mstump, or stumpy.mstumped functions.

I think a "light touch" would be nice and, since many scientists aren't code savvy beyond copy and pasting, ease of use/installation is very important since they likely won't use it if there is moderate friction.

I know I've said a lot so please let me know if I've misunderstood your question(s) or if I can help clarify anything.

[zpzim]

Just as a benchmark, an optimized cpp implementation can get to ~7 seconds for 2^17 datapoints on 1 thread with a relatively simple scheme. See https://github.com/zpzim/SCAMP/blob/8c27498928e2aaf820a8cb3d2f6e7dda2198a240/src/cpu_kernels.cpp#L18 for a kernel implementation. On a P100 GPU you can do 2^21 in about 12 seconds. On May 15, 2019 3:48 PM, "Sean M. Law" <notifications@github.com> wrote: Thanks @mrocklin<https://github.com/mrocklin>. I looked at CuPy two years ago when it first came out so my info on it is outdated and I will need to find some time to brush up on its advancements. core.py implements some basic utility functions to avoid redundancy but the heaviest part of the computation actually lives in: * stump.py (locally parallel but for a single time series) * stumped.py (locally parallel and distributed for a single time series) * mstump.py (locally parallel but for multiple time series - "multidimensional") * mstumped.py (locally parallel and distributed for multiuple time series). So, modules that end in "ed" implies that it can use Dask for distributed computing but all of them utilize Numba for parallel computing (not NumPy). According to the original publications<https://www.cs.ucr.edu/~eamonn/STOMP_GPU_final_submission_camera_ready.pdf> (not written by me), these are the four modules that should be pushed onto the GPU as this is the expensive part/bottleneck of the computation. From my experience, there are key for loops that cannot be eliminated<https://github.com/TDAmeritrade/stumpy/blob/ab15da3c4951df3ec473bd463330fee48ffbe218/stumpy/stump.py#L250> and therefore I couldn't immediately figure out how to use CuPy with it. As it relates to "user frustration", I think the timing calculations found in the README<https://github.com/TDAmeritrade/stumpy#performance> may help to paint a more accurate story. Anecdotally (based on my interactions with folks who run long molecular dynamics (MD) simulations or are dealing with many, many shorter financial time series data), I would split the users up into three groups based on their time series length: * Short - Less than 10,000 data points in their time series * Medium - 10,000 - 1,000,000 data points in their time series * Long - 1,000,000+ data points in their time series OR many, many medium length time series and therefore require the multi-dimensional calculation Based on the timing calculations (see README), one can do short calculations on a modest 2-core laptop fairly easily and be able to get immediate feedback within seconds to minutes. I would argue that the short calculations are often less interesting as it may not contain enough data for good comparison. However, for medium calculations even on 16 CPUs, it would take over 40 hours to process 100,000 data points and, more importantly, this amount of wait time tends to slow down the productivity of the scientist/data scientist who is looking for quicker/immediate feedback so that they can readjust their analytics focus. Anything in the long range definitely requires setting up a larger Dask cluster or the use of GPUs and having a few million data points in a single time series is fairly commonplace in the MD world where they are already using GPUs to generate their data. So, all users will care most about computing the matrix profile and this is achieved by calling either the stumpy.stump, stumpy.stumped, stumpy.mstump, or stumpy.mstumped functions. I think a "light touch" would be nice and, since many scientists aren't code savvy beyond copy and pasting, ease of use/installation is very important since they likely won't use it if there is moderate friction. I know I've said a lot so please let me know if I've misunderstood your question(s) or if I can help clarify anything. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#1>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABRCWU7NODL5WRSXTP4QDY3PVQICXANCNFSM4HLAM2NQ>.

[seanlaw]

@wuxianliang GPU-STUMP is now available in the latest v1.2.2 release!

[datametrician]

@seanlaw do you have a blog or benchmarks on speedups of GPU to CPU?

[seanlaw]

@datametrician Not yet but I just started issue #79 to track this. Hopefully, I'll be able to put some thoughts down