Algorithms As A Technology
Algorithms As A Technology
Algorithms As A Technology
2 Algorithms as a technology
If computers were infinitely fast and computer memory were free,
would you have any reason to study algorithms? The answer is yes, if for
no other reason than that you would still like to be certain that your
solution method terminates and does so with the correct answer.
If computers were infinitely fast, any correct method for solving a
problem would do. You would probably want your implementation to be
within the bounds of good software engineering practice (for example,
your implementation should be well designed and documented), but you
would most often use whichever method was the easiest to implement.
Of course, computers may be fast, but they are not infinitely fast.
Computing time is therefore a bounded resource, which makes it
precious. Although the saying goes, “Time is money,” time is even more
valuable than money: you can get back money after you spend it, but
once time is spent, you can never get it back. Memory may be
inexpensive, but it is neither infinite nor free. You should choose
algorithms that use the resources of time and space efficiently.
Efficiency
Different algorithms devised to solve the same problem often differ
dramatically in their efficiency. These differences can be much more
significant than differences due to hardware and software.
As an example, Chapter 2 introduces two algorithms for sorting. The
first, known as insertion sort, takes time roughly equal to c1n2 to sort n
items, where c1 is a constant that does not depend on n. That is, it takes
time roughly proportional to n2. The second, merge sort, takes time
roughly equal to c2n lg n, where lg n stands for log2 n and c2 is another
constant that also does not depend on n. Insertion sort typically has a
smaller constant factor than merge sort, so that c1 < c2. We’ll see that
the constant factors can have far less of an impact on the running time
than the dependence on the input size n. Let’s write insertion sort’s
running time as c1n · n and merge sort’s running time as c2n · lg n. Then
we see that where insertion sort has a factor of n in its running time,
merge sort has a factor of lg n, which is much smaller. For example,
when n is 1000, lg n is approximately 10, and when n is 1,000,000, lg n is
approximately only 20. Although insertion sort usually runs faster than
merge sort for small input sizes, once the input size n becomes large
enough, merge sort’s advantage of lg n versus n more than compensates
for the difference in constant factors. No matter how much smaller c1 is
than c2, there is always a crossover point beyond which merge sort is
faster.
For a concrete example, let us pit a faster computer (computer A)
running insertion sort against a slower computer (computer B) running
merge sort. They each must sort an array of 10 million numbers.
(Although 10 million numbers might seem like a lot, if the numbers are
eight-byte integers, then the input occupies about 80 megabytes, which
fits in the memory of even an inexpensive laptop computer many times
over.) Suppose that computer A executes 10 billion instructions per
second (faster than any single sequential computer at the time of this
writing) and computer B executes only 10 million instructions per
second (much slower than most contemporary computers), so that
computer A is 1000 times faster than computer B in raw computing
power. To make the difference even more dramatic, suppose that the
world’s craftiest programmer codes insertion sort in machine language
for computer A, and the resulting code requires 2n2 instructions to sort
n numbers. Suppose further that just an average programmer
implements merge sort, using a high-level language with an inefficient
compiler, with the resulting code taking 50 n lg n instructions. To sort 10
million numbers, computer A takes
By using an algorithm whose running time grows more slowly, even with
a poor compiler, computer B runs more than 17 times faster than
computer A! The advantage of merge sort is even more pronounced
when sorting 100 million numbers: where insertion sort takes more than
23 days, merge sort takes under four hours. Although 100 million might
seem like a large number, there are more than 100 million web searches
every half hour, more than 100 million emails sent every minute, and
some of the smallest galaxies (known as ultra-compact dwarf galaxies)
contain about 100 million stars. In general, as the problem size
increases, so does the relative advantage of merge sort.