Taskflow
2.4-master-branch
|
We study a fundamental clustering problem in unsupervised learning, k-means clustering. We will begin by discussing the problem formulation and then learn how to write a parallel k-means algorithm.
k-means clustering uses centroids, k different randomly-initiated points in the data, and assigns every data point to the nearest centroid. After every point has been assigned, the centroid is moved to the average of all of the points assigned to it. We describe the k-means algorithm in the following steps:
The algorithm is illustrated as follows:
A sequential implementation of k-means is described as follows:
The second step of k-means algorithm, assigning every point to the nearest centroid, is highly parallelizable across individual points. We can create a parallel-for graph to run this step in parallel. Assuming we request P
tasks, each task works on a set of points of size (N + P - 1) / P
.
The third step of moving every centroid to the average of points is also parallelizable across individual centroids. However, since k is typically not large, one task of doing this update is sufficient.
To describe M
iterations, we create a condition task that loops the second step of the algorithm by M
times. The return value of zero goes to the first successor which we will connect to the task of the second step later; otherwise, k-means completes.
The entire code of CPU-parallel k-means is shown below. Here we use an additional storage, best_ks
, to record the nearest centroid of a point at an iteration.
The second step of the algorithm consists of two parts, a clean_up
task and a parallel-for graph. The former cleans up the storage sx
, sy
, and c
that are used to average points for new centroids, and the later parallelizes the searching for nearest centroids across individual points using 12 tasks. If the iteration count is smaller than M
, the condition task returns 0 to let the execution path go back to clean_up
. Otherwise, it returns 1 to stop, since there is no successor indexable by 1.
We observe Step 2 and Step 3 of the algorithm are parallelizable across individual points for use to harness the power of GPU:
At a fine-grained level, we request one GPU thread to work on one point for Step 2 and one GPU thread to work on one centroid for Step 3.
When we recompute the cluster centroids to be the mean of all points assigned to a particular centroid, multiple GPU threads may access the sum arrays, sx
and sy
, and the count array, c
. To avoid data race, we use a simple atomicAdd
method. Based on the two kernels, the entire code of CPU-GPU collaborative tasking is described as follows:
The first dump before executing the taskflow produces the following diagram. The condition tasks introduces a cycle between itself and update_means
. Each time it goes back to update_means
, the cudaFlow is reconstructed with captured parameters in the closure and offloaded to the GPU.
The second dump after executing the taskflow produces the following diagram, with all cudaFlows expanded:
The main cudaFlow task, update_means
, must not run before all required data has settled down. It precedes a condition task that circles back to itself until we reach M
iterations. When iteration completes, the condition task directs the execution path to the cudaFlow, h2d
, to copy the results of clusters to h_mx
and h_my
and then deallocate all GPU memory.
We observe the GPU task graph parameters remain unchanged across all k-means iterations. In this case, we can leverage tf::cudaFlow::repeat or tf::cudaFlow::predicate to create the cudaFlow once and launch it repeatedly as rapidly as possible without participating in conditional tasking.
At the last line of the cudaFlow closure, we call cf.repeat(M)
to ask the executor to repeatedly run the cudaFlow by M
times. Compared with the version using conditional tasking, the cudaFlow here is created only one time and thus the overhead is reduced.
We can see from the above taskflow the condition task is removed. Not all problems can benefit from tf::cudaFlow::repeat. If the graph parameters change at each iteration, you may use conditional tasking or resort to other client-side decision.
We run three versions of k-means, sequential CPU, parallel CPUs, and one GPU, on a machine of 6 Intel i7-8700 CPUs at 3.20GHz and a Nvidia RTX 2080 GPU using various numbers of 2D point counts and iterations.
N | K | M | CPU Sequential | CPU Parallel | GPU (conditional taksing) | GPU (with predicate) |
---|---|---|---|---|---|---|
10 | 5 | 10 | 0.14 ms | 77 ms | 1 ms | 1 ms |
100 | 10 | 100 | 0.56 ms | 86 ms | 7 ms | 1 ms |
1000 | 10 | 1000 | 10 ms | 98 ms | 55 ms | 13 ms |
10000 | 10 | 10000 | 1006 ms | 713 ms | 458 ms | 183 ms |
100000 | 10 | 100000 | 102483 ms | 49966 ms | 7952 ms | 4725 ms |
When the number of points is larger than 10K, both parallel CPU and GPU implementations start to pick up the speed over than the sequential version. We can see using the built-in predicate of cudaFlow is two times faster than conditional tasking.