Cuml: [QST] Is it faster to just run cuML rotuines on numpy arrays resident on CPUs?!

[vinayprabhu]

So, do we really need to convert numpy arrays to cudf before running cuML routines on them?

[JohnZed]

Hi, @vinayprabhu - sorry for the unnecessary warning spew! The code is actually working fine here, but it's just printing a reminder that the umap code is using an outdated parameter name. We'll convert this to an issue and make sure the warning gets removed in the future.

[JohnZed]

More generally, numpy arrays, cudf data frames, and gpu arrays (from numba, cupy, etc.) are all acceptable inputs. GPU arrays will be fastest. Here, the warning spew is probably slowing you down. You could also check to ensure that both are using fp32, which will be significantly faster.

[dantegd]

@vinaydes that warning is very explicit on what is happening, that parameter will be dropped in this upcoming version. It has nothing to do with speed, just that the parameter should_downcast is deprecated and has been substituted by convert_dtype. Very soon that warning will not appear with default parameters. What @JohnZed is right, the fastest input types are cuda_array_interface compliant device array inputs (numba, pytorch and cupy are good examples). After that cuDF should be the fastest (but will consume more memory than the others), but it has allocation overheads that the other methods don't have since it is a full dataframe library (like Pandas), so that overhead might make it slower than numpy for some smaller inputs or depending on GPU/CPU bandwidth. Finally, numpy has the same execution path as the device array inputs with the transfer to device overhear, so it is strictly slower.

[vinaydes]

@dantegd I think you have tagged wrong Vinay. Issue is filed by @vinayprabhu and not me (@vinaydes)

[dantegd]

Sorry @vinaydes!!! I'll blame it on github UI :P

[vinayprabhu]

@dantegd and @JohnZed
Sorry for the confusion. The main point I was making was the anomaly. The numpy tensor is X and it is turning out to be the faster option compared to X_cudf option generated as:
`
X_df = pd.DataFrame(X)
X_df.columns = ['feature_' + str(i) for i in range(X_df.shape[1])]
X_cudf = cudf.DataFrame.from_pandas(X_df)

`
from this tutorial notebook here

[dantegd]

@vinayprabhu (correct Vinay this time!) just took a look at the notebook (had forgotten the dataset it used). The dataset is quite small (X: (1797, 64) float32 y: (1797,) float32), so the most likely thing is that the processing of a dataframe (to extract the numeric values into a device array) and then the copying of the results to host are dominating the execution time, and since the dataset is small, the time it takes to copy the numpy array to device is smaller.

[dantegd]

after a little bit of more thought, I think we (I?) will end up creating a notebook that shows the behavior of different size and shapes of datasets, will ping you back when it is ready

[vinayprabhu]

@dantegd Aha! Gotcha!
That was my hunch. Thank you so much for the clarification :)