1. Fast Finds: Making Google & BLAST Faster Dr. Laurence Boxer (w. Stephen Englert, NU CIS/MAT ’05) Dept. of Computer & Information Sciences Presented to Niagara University Research Council September, 2005

2. The problem: Examples using exact matches P: agtacagtac T: actaactagtacagtacagtacaactgtccatccg Given two character strings, a “pattern” and a “text” (with the text typically much larger than the pattern), find all matching copies of the pattern in the text. Output: (notice finds may overlap) Input: T: Welcome! You’ve come from …. P: come Output: T: Welcome! You’ve come from ….

3. Further, we want our solution to run quickly.  Users typically will wait a few seconds. They won’t wait a few hours, days, or months.  Today’s databases may be HUGE, e.g., the entire Web, or multiple genomes. Since, usually, the time of solution grows with the amount of data processed, it’s important to use efficient algorithms.  Thus, the growth rate of a solution’s running time as a function of the amount of data processed is an important consideration for a software developer.

4. Notation: we commonly use  T(n) for the time required to solve a problem of size n, which is typically the number of data items processed.  T(n)=Θ(f(n)) means T(n) is approximately proportional to f(n) (within a strictly defined technical rule).  T(n)=O(f(n)) means T(n) is at most proportional to something that’s Θ(f(n)) (within a strictly defined technical rule).

5. Simpler search problem: Sequential Search for a given value  Start at beginning of list  Examine each item until either you find what you seek (stop when success is reached), or you reach the end of list without finding (stop at failure).  Example: list of schools Niagara, Canisius, UB, RIT, St. Bonaventure Search for Niagara succeeds at 1 st item (best case: Θ(1) time) Search for St. Bonaventure succeeds at 5 th (last) item Search for NCCC fails at last item Worst cases require examining each item, hence T(n)=Θ(n); in general, then, T(n)=O(n). Would you search a phone book for Zielinski this way?

6. Simpler search problem: Binary Search for a given value  Requires list to be ordered  Mimics the way we search a phone book – each item examined eliminating a large portion of the data. Start in middle; decide which half to continue searching; repeat this pattern on portion of data not yet eliminated. Thus, 1 st item examined, if not the sought value, eliminates ½ data; 2 nd item examined, if not the sought value, eliminates ½ of remaining ½, leaving ¼ of original data, etc. k-th item examined, if not the sought value, leaves  Thus, in worst case, stop when of original data, until only 1 item remains.  Since k reflects T(n), worst case:  In general,

7. Examples of binary search Search for Rochester: Start in middle – [4]. Compare: Niagara < Rochester, so range narrows to [5-8] Middle of [5-8] is [6], so success at 2 nd item examined. Search for Ithaca: Start in middle – [4]. Niagara > Ithaca, so range narrows to [1-3]. Middle of [1-3] is [2]. Compare: Canisius < Ithaca, so range narrows to [3-3]. Range [3-3] has one item. Compare: D’Youville < Ithaca, so search fails at 3 rd item examined. Note

8. Measures of running times for sequential and binary searches n 1,02410 2,04811 4,09612 8,19213 16,38414 32,76815 65,53616 131,07217 262,14418 524,28819 1,048,57620  Sequential search – always applicable, but T(n)=O(n).  Binary search – only applicable when data is sorted, but If the constant of proportionality in both cases is 0.01 second (unlikely), then the comparison is more than 2 hours 54 minutes, to 0.2 seconds.

9. Approaches to speedup of string pattern matching algorithms  Use parallel computers – made up of multiple processors acting in parallel. Each processor processes a portion of the data in parallel with all other processors, so solution comes faster than by using just 1 processor. This approach was discussed in L. Boxer and R. Miller, Coarse Grained Gather and Scatter Operations with Applications, Journal of Parallel and Distributed Computing, 64 (2004), 1297-1320, presented at the March, 2005, NU Bioinformatics Seminar.  Devise faster sequential algorithms. This is the approach we discuss now.

10. Previous sequential solutions to exact string pattern matching  It’s known that in worst case, all characters of T must be considered. (Simple example: P has 1 character – any character of T not considered might be an overlooked match, so we must check ‘em all.) Hence, in worst case, a solution must take time that is at least proportional to n.  Algorithms that take O(n) time are known. By previous remark, such algorithms are “optimal” in worst case.  Boyer-Moore algorithm runs, for many examples, much faster than linear time – often, in Θ(n/m) time – but in worst case, runs in very slow Θ(mn) time. Has been modified by several authors to get linear time worst case, but these modifications are complex.  Our goal: a simple such modification.

11. Our modification of Boyer-Moore 1 In Θ(m) time, scan the characters of P to note which characters of the “alphabet” (character set) are used in P. This will enable us to make Θ(1) time decisions on whether any given character of T is a “bad character.” Now, we seek matches of last character of P with character of T. Boyer-Moore is often fast because it recognizes blocks of characters in T that can be skipped over, as follows.

12. Our modification of Boyer-Moore 2 Boyer-Moore “bad character” rule: if character of T aligned with last character of P isn’t in P, then none of the m characters of T starting with this one can align with last character of P in a substring match. Here, the “g” of T doesn’t match any character of P. It follows that aligning the “t” of P with any of the m characters of T starting with “g” also won’t yield a match, so we can skip the m-1 characters of T following “g” as possible positions for matching last character of P.

13. Our modification of Boyer-Moore 3  Boyer-Moore is slow in worst case because it’s too eager to look for pattern matches. If no bad character is recognized, hence no data eliminated, Boyer-Moore may search for a match “everywhere”, hence compare (almost) every character of P with (almost) every character of T, resulting in Θ(mn) comparisons, hence Θ(mn) time.  Instead, we separate the data-elimination step. First, use the “bad character” (and other Boyer-Moore data elimination) rule(s) to determine what data of T must be considered. This can be done in Worst case: Θ(n) time, leaving all of T (no data eliminated) – thus, a (small) waste of time Often: much faster due to skips, and leaving only a fraction of T left to consider – precisely when Boyer-Moore works quickly  Then …

14. Our modification of Boyer-Moore 4  Apply a linear-time algorithm (thus, other than Boyer- Moore) to the uneliminated data (which, often, is greatly reduced).  Summary:  In worst case, we apply a linear-time algorithm to the original n data after wasting a linear amount of time pre- processing. This gives a still linear-time algorithm, about 12%-16% slower than had we not done this pre- processing.  Often, we apply a linear-time algorithm to a greatly reduced (sublinear) amount of data after spending a sublinear amount of time preprocessing, netting a sublinear time altogether.

15. Experimental results  Stephen Englert (now in grad school at SUNY - Albany) wrote most of the code to time our experiments  Time units in “clocks” of C++ software – real time will vary depending on factors (that may have nothing to do with the quality of the algorithm) such as speed of computer hardware and quality of code generated by compiler

16. A best case experiment - %%... T is a file not containing “%”; n = 2,350,367 Therefore, preprocessing takes Θ(n/m) time, eliminates all of T. PWith Preprocessing Without Preprocessing "%"^48167 "%"^85167 "%"^163166 "%"^322168 "%"^641167

17. Experiment 2  T: Same file as in previous experiment With Preproc. Not Preproc. P = "algorithm"41180 P = "algorithm"^24177 P = "algorithm"^44178 P = "algorithm"^82179 Superlinear speedup likely due to matches vs. no matches

18. Experiment 3 T: as before, n = 2,350,367With Preproc.Not Preproc. P = "parallel"9169 P = "parallel"^24170 P = "parallel"^43170 P = "parallel"^81170 9 vs. 41 for “algorithm” likely due to more “bad” characters, since “parallel” uses fewer distinct letters

19. Experiment 4 – worst case – preprocessing doesn’t reduce data T = “#” ^ n, n = 2 ^ k, P = “#” ^ m Here, preprocessing slows running time (by about 12% - 16%). m = 4m = 8m = 16 kPreproc. Not Preproc.Preproc. Not Preproc.Preproc. Not Preproc. 19 159 138 158 138 159 138 20 319 278 318 277 318 276 21 648 570 644 567 644 567 22 1,303 1,148 1,299 1,153 1,289 1,147 23 2,631 2,321 2,625 2,327 2,613 2,318

20. Notes  A worst case example is often artificial, not of practical interest. In such a case, our pre-processing algorithm seems to waste up to 16% of the running time. However, this is still a linear-time algorithm - O(n); better than Boyer-Moore - O(mn).  In cases of practical interest, our pre-processing algorithm yields dramatically improved performance for the linear- time algorithm it is combined with.  Our algorithm is fast when Boyer-Moore is fast; much faster when Boyer-Moore is slow.  Our modification of Boyer-Moore is simpler than others in the literature and appears to perform at least as well.