# Growth Rates

A difficult concept for many students to grasp is the idea of function growth rates, and in particular why we allow ourselves to "ignore constant factors" and "ignore low-order terms". Here's a copy of the table from p. 15 of Steven Skiena's Algorithm Design Manual, which lists the running time of algorithms with various growth rates, measured in nanoseconds (billionths of a second).
nf(n)=lg nf(n)=nf(n)=n lg nf(n)=n2f(n)=2nf(n)=n!
100.003 us0.01 us0.033 us0.1 us1 us3.63 ms
200.004 us0.02 us0.086 us0.4 us1 ms77.1 years
300.005 us0.03 us0.147 us0.9 us1 sec8.4 * 1015 years
400.005 us0.04 us0.213 us1.6 us18.3 minnever mind
500.006 us0.05 us0.282 us2.5 us13 days
1000.007 us0.1 us0.644 us10 us4 * 1013 years
10000.010 us1.0 us9.966 us1 msnever mind
100000.013 us10 us130 us100 ms
1000000.017 us0.10 ms1.67 ms10 sec
10000000.020 us1 ms19.93 ms16.7 min
100000000.023 us0.01 sec0.23 sec1.16 days
1000000000.027 us0.10 sec2.66 sec115.7 days
10000000000.030 us1 sec29.90 sec31.7 years

But let's look at it another way. Suppose we've decided how much time we have to solve the problem, and we want to know how large a problem we can solve in that time. In the following table, the left-hand column represents the available time, and the entries in the body of the table represent the largest n for which we can solve the problem in that time.
time f(n)=lg n f(n)=n f(n)=n lg n f(n)=n2 f(n)=2n f(n)=n!
1 us 1.07 * 10301 1000 140 31 10 6
1 ms c. 10300000 1000000 62746 1000 20 9
1 sec never mind 109 c. 4 * 107 31623 30 13
1 min   6*1010 c. 2*109 244949 36 14

Now let's try that same table again, but we'll divide each function by 100, equivalent to using a 100-times-faster processor.
time f(n)=(lg n)/100 f(n)=n/100 f(n)=(n lg n)/100 f(n)=n2/100 f(n)=2n/100 f(n)=n!/100
1 us c. 1030000 100000 7741 316 16 8
1 ms c. 1030000000 108 4523071 10000 26 11
1 sec never mind 1011 c. 3*109 316227 36 14
1 min   6 * 1012 c. 1.6*1011 2449489 42 15
You should take two lessons from this table.

1. Improving the algorithm makes a lot more difference than improving the processor.
2. If the algorithm is asymptotically inefficient, processor speed won't help you much;
if the algorithm is asymptotically efficient, improving processor speed does help.
{"found_math": false, "script_math_tex": 0, "script_math_asciimath": 0, "math_annotations": 0, "math_alttext": 0, "mathml": 0, "mathjax_tag": 0, "mathjax_inline_tex": 0, "mathjax_display_tex": 0, "mathjax_asciimath": 0, "img_math": 0, "codecogs_latex": 0, "wp_latex": 0, "mimetex.cgi": 0, "/images/math/codecogs": 0, "mathtex.cgi": 0, "katex": 0, "math-container": 0, "wp-katex-eq": 0, "align": 0, "equation": 0, "x-ck12": 0, "texerror": 0, "url": "http://home.adelphi.edu/sbloch/class/archive/344/spring2001/growth.html", "fetch_time": 1508423962000000000, "content_mime_type": "text/html", "warc_filename": "crawl-data/CC-MAIN-2017-43/segments/1508187823309.55/warc/CC-MAIN-20171019141046-20171019161046-00581.warc.gz", "warc_record_offset": 154029851, "warc_record_length": 2186, "token_count": 790, "char_count": 2254, "score": 4.15625, "int_score": 4, "crawl": "CC-MAIN-2017-43", "snapshot_type": "longest", "language": "en", "language_score": 0.715165376663208, "file_path": "/sailhome/yjruan/project/latent-lm/data/processed/finemath-4plus/finemath-4plus/train-00057-of-00064.parquet"}