A GPU Exercise
It’s been several months since the last time I put my hands on something related to GPUs. Sadly, I get very rarely the chance to get this kind of jobs. So, to keep myself trained (just in case I will get one), during the last two weeks I worked on an “exercise project”.
For this exercise project I choosed to port to GPU an algorithm that I studied during my University years. Here you can find some informations:
I’ll try to explain in few words and with a little example what is the Levenshtein distance. Given two strings, the Levenstein distance is the minimum number of character insertion, deletion or substitution, to change a string into the other, ie:
The Levenshtein distance between RISOTTO and PRESTO is 4:
- Insert P
- Substitute I with E
- Delete O
- Delete T
Finding the shortest list of operations to change a string into another is a problem that can be solved by using the Dynamic Programming technique. The main trouble is that, in many cases, this technique requires an huge amount of memory to store intermediate results and avoid recomputing.
In fact, this algorithm requires a amount of memory proportional to the product of the lengths of the 2 strings: if len(string1) is m, and len(string2) is n, then the memory and operations requirement is O(m*n).
The required memory amount can be reduced in several ways… expecially exploiting some of the upper bounds of the optimal solution (see the wikipedia link at the top of this article).
However, if we compute just the number of operations (without actually knowing which operations are performed), the memory requirement can be reduced up to O(max(m, n)), even though the number of operations remains unchanged at O(m*n).
Let’s try to understand how the algorithm works, and hence, why computing the optimal cost, in terms of number of changes, is cheaper (in terms of memory) than computing the entire operations list.
Given two string and such that and , we can use a matrix to represent the solutions of each subproblem.
Where cell will contain the cost of the optimal solution for the subproblem of changing string into with and . The character represents the empty string. Note that the first row and column of this matrix, are quite easy to fill:
The first column contains the costs of changing any of the substrings into the empty string. So, substring (formed by the empty string plus the character) will require 1 deletion to change into substring (the empty string)… will require 2 deletion, is 3, and so on… The first row contains the cost of changing the empty string into the substring . So, the cost of changing the empty string into , will be 1 insertion, is 2, and so on… Obviusly, the cell containing the cost of changing in , that is 0.
Now that we have defined the base cases, we can look at how it’s possible to fill the remaining cells, and thus finding the costs of the optimal solutions. Let’s take as example the cell corresponding to subproblem of changing into .
The easiest case is when . In this case we don’t need to perform any operation over the previous subproblem of changing into , hence the costs are the same.
If differs from , then we can choose the cheapest among the three following options:
Substitute with . The cost will be 1 plus the cost of changing into .
Insert the character to . The cost will be 1 plus the cost of changing into
Delete the character from the string . the cost will be 1 plus the cost of changing into In the same way it’s possible to compute the values for all the other cells, by looking at the cells associated to the immediately preceding subproblems. In the end we will get the value of subproblem , that is the problem from which we started from.
Let’s make some observations:
The value of cell depends only from the comparison between and and value in cells , , .
The operation that was performed to produce the value in cell can be deduced only by looking at and and value inside cells , , .
This makes easy computing the value of a cell since we have to remember just the values of the immediatly preceeding subproblems. On the other hand, to retrive all the operations associated to the optimal solution, it’s necessary to store (or recompute) the values of all the preceeding cells, since it’s not possible to know which cells you will need, until you know the “subproblems path” to the optimal solution.
I hope you enjoied this simple introduction to the algorithm. In the next post I’m going straight into the implementation and the problems (and the solutions) of make run this algorithm on a GPU… attaching a lot of code of course :)
And naturally, if you spot errors, I would be really happy to receive reports ;)