# Zero Code Change Acceleration: Getting Started with cuml.accel

The cuml.accel accelerator mode allows you to bring GPU-accelerated computing to existing machine learning workflows with zero code changes required. By simply loading the cuml.accel extension, your existing scikit-learn, UMAP, and HDBSCAN code can automatically leverage GPU acceleration for supported algorithms.

This notebook demonstrates how to use cuml.accel with practical examples across different machine learning tasks.

With classical machine learning, there is a wide range of interesting problems we can explore. In this brief introduction we demonstrate a typical classification workflow.

## Classification Example

We will randomly generate a dataset for this example. Alternatively, if you prefer a real-world dataset, you can use the Covertype dataset, which contains features such as elevation, aspect, slope, and soil type to predict forest cover type.

More information on the Covertype dataset can be found at [https://archive.ics.uci.edu/dataset/31/covertype](https://archive.ics.uci.edu/dataset/31/covertype).

```none
[1]:
```

```none
[2]:
```

Next, we’ll split our dataset into training and test data using the scikit-learn `train_test_split` function.

```none
[3]:
```

Now that we have our dataset split, we’re ready to run a model. To start, we will just run the model using scikit-learn with a starting max depth of 5 and all of the features. Note that we can set n_jobs=-1 to utilize all available CPU cores for fitting the trees – this will ensure we get the best performance possible on our system’s CPU.

```none
[4]:
```

```none
[4]:
```

In about 2 minutes, we were able to fit our tree model using scikit-learn. This is not bad! Let’s use the model we just trained to predict coverage types in our test dataset and take a look at the accuracy of our model.

```none
[5]:
```

```none
[5]:
```

We can also print out a full classification report to better understand how we predicted different Coverage_Type categories.

```none
[6]:
```

With scikit-learn, we built a model that was able to be trained in just a couple minutes. From the accuracy report, we can see that we predicted the correct class around 70% of the time, which is not bad but could certainly be improved.

Often we want to run several different random forest models in order to optimize our hyperparameters. For example, we may want to increase the number of estimators, or modify the maximum depth of our tree. When running dozens or hundreds of different hyperparameter combinations, things start to become quite slow and iteration takes a lot longer.

We provide some sample code utilizing GridSearchCV below to show what this process might look like. All of these combinations would take a LONG time to run if we spend 2 minutes fitting each model.

```none
[7]:
```

```none
[7]:
```

Now let’s load cuml.accel and try running the same code again to see what kind of acceleration we can get.

```none
[8]:
```

After loading the IPython magic, we need to import the scikit-learn estimators we wish to use again.

```none
[9]:
```

```none
[10]:
```

```none
[10]:
```

That was much faster! Using cuML we’re able to train this random forest model in just seconds instead of minutes. One thing to note is that cuML’s implementation of RandomForestClassifier doesn’t utilize the `n_jobs` parameter like scikit-learn, but we still accept it which makes it easier to use this accelerator with zero code changes.

Let’s take a look at the same accuracy score and classification report to compare the model’s performance.

```none
[11]:
```

Out of the box, the model performed about the same as the scikit-learn implementation. Because this model ran so much faster, we can quickly iterate on the hyperparameter configuration and find a model that performs better with excellent speedups.

```none
[12]:
```

```none
[12]:
```

```none
[13]:
```

With a model that runs in just seconds, we can perform hyperparameter optimization using a method like the grid search shown above, and have results in just minutes instead of hours.

## CPU Fallback

There are some algorithms and functionality from scikit-learn, UMAP, and HDBSCAN that are *not* implemented in cuML. For cases where the underlying functionality is not supported on GPU, the cuML accelerator will gracefully fall back and execute on the CPU instead.

For example, cuML’s RandomForest estimator does not support sparse inputs.

```none
[14]:
```

```none
[14]:
```

We can see that the model took longer to fit because it had to fall back to the CPU, but the code executed without errors.

```none
[15]:
```