Slide Set 18. for ENCM 339 Fall Steve Norman, PhD, PEng. Electrical & Computer Engineering Schulich School of Engineering University of Calgary

Transcription

1 Slide Set 18 for ENCM 339 Fall 2016 Steve Norman, PhD, PEng Electrical & Computer Engineering Schulich School of Engineering University of Calgary December 2016

2 ENCM 339 Fall 2016 Slide Set 18 slide 2/26 Contents Attention! Performance of some recursive functions Recursive traversal of part of a file system

3 ENCM 339 Fall 2016 Slide Set 18 slide 3/26 Outline of Slide Set 18 Attention! Performance of some recursive functions Recursive traversal of part of a file system

4 ENCM 339 Fall 2016 Slide Set 18 slide 4/26 Attention! All of the content in this slide set is useful to know. But none of the content will be tested on the Fall 2016 ENCM 339 final examination.

5 ENCM 339 Fall 2016 Slide Set 18 slide 5/26 Outline of Slide Set 18 Attention! Performance of some recursive functions Recursive traversal of part of a file system

6 ENCM 339 Fall 2016 Slide Set 18 slide 6/26 Performance of some recursive functions In Slide Set 16, I had this to say: Mergesort and quicksort, if coded properly, are both astonishingly faster for sorting large arrays than are easier-to-code sorting algorithms, such as bubble sort and insertion sort. Let s look at the above claim in more detail. Then, let s look at a simple recursive function that is astonishingly slow.

7 ENCM 339 Fall 2016 Slide Set 18 slide 7/26 Performance measurement of some sort functions I wrote a C++ program to measure the time it took to sort a vector<double>, with each of five functions: the C++ library sort function, which uses a quicksort-based algorithm the C++ library stable_sort function, which uses mergesort my own implementation of mergesort a good implementation of insertion sort an implementation of bubble sort (The C++ library sort function uses an algorithm called introsort, which, oversimplifying a little, is quicksort with a guard against worst-case performance of quicksort.)

8 ENCM 339 Fall 2016 Slide Set 18 slide 8/26 The text on the next page is copy-pasted from a terminal window on my Mac, and shows three timing runs for vectors of 1,000 elements. Times vary from one run to the next, which is to be expected, for many reasons. Two important reasons are: Each program starts with a different randomly-ordered vector. For some algorithms, sort speed may be faster for some orders of numbers than for other orders. Modern computer memory systems are very complex. The average time needed to read or write an array element may vary from one run of a program to the next.

9 $./a.out 1e3 each vector will have 1000 elements time for library sort was 5.5e-05 seconds time for library stable_sort was 6e-05 seconds time for sn merge sort was 6.5e-05 seconds time for insertion sort was seconds time for bubble sort was seconds $./a.out 1e3 each vector will have 1000 elements time for library sort was 4.8e-05 seconds time for library stable_sort was 5.6e-05 seconds time for sn merge sort was 5.8e-05 seconds time for insertion sort was seconds time for bubble sort was seconds $./a.out 1e3 each vector will have 1000 elements time for library sort was 5.5e-05 seconds time for library stable_sort was 6.1e-05 seconds time for sn merge sort was 6.5e-05 seconds time for insertion sort was seconds time for bubble sort was seconds

10 ENCM 339 Fall 2016 Slide Set 18 slide 10/26 Results for 1,000 to 100,000 elements Times are in microseconds. Numbers are averages from 3 runs for each array size, and are rounded to 2 or 3 significant digits. number of elements algorithm 1,000 10, ,000 sort ,910 stable sort ,310 SN merge sort ,420 insertion sort ,700 1,410,000 bubble sort 1, ,000 13,700,000

11 ENCM 339 Fall 2016 Slide Set 18 slide 11/26 Results for 300,000 to 10 million elements Times are in seconds. Numbers are averages from 3 runs for each array size, and are rounded to 3 significant digits. number of elements algorithm 300,000 1 million 3 million 10 million sort stable sort SN merge sort insertion sort too long too long Reasonable estimates for insertion sort would be 22 minutes for 3 million elements, and 4.1 hours for 10 million elements.

12 ENCM 339 Fall 2016 Slide Set 18 slide 12/26 Why is there such a huge difference in running times? Computer scientists have shown that for N array elements, starting in random order, average-case running times are approximately as follows: K B N 2 for bubble sort and K I N 2 for insertion sort; K Q N log 2 N for quicksort and K M N log 2 N for mergesort. K B, K I, K Q, and K M are numbers that depend on processor speed, memory speed, quality of source code, and efficiency of machine code generated by the compiler. Crucial fact: log 2 N grows very slowly as a function of N. For example, log 2 1,000,

13 ENCM 339 Fall 2016 Slide Set 18 slide 13/26 Key point: With large data sets, it may be really important to choose an algorithm that is not only correct, but also fast! Speed justifies the choice of mergesort (with slightly tricky merge code) or quicksort (with significantly tricky partition code), over simple algorithms like bubble sort and insertion sort. In 2016, fortunately, most good languages have libraries that make fast sort algorithms available to you without your having to code them. C++ is excellent in this respect; C is less excellent because C does not have a feature called templates.

14 ENCM 339 Fall 2016 Slide Set 18 slide 14/26 A terribly slow recursive function Recursion happens to be very helpful in implementing quicksort and mergesort, but do not make the inference that use of recursion automatically results in speed! We ll now look at a recursive function to compute F n, where 0 if n = 0 F n = 1 if n = 1 F n 1 + F n 2 if n 2 This formula generates a sequence famous in mathematics, called the Fibonacci numbers: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34,...

15 ENCM 339 Fall 2016 Slide Set 18 slide 15/26 Consider the following function prototype: unsigned int fibo(unsigned int n); // PROMISES: // Return value is the nth Fibonacci number. Let s write out a recursive function definition in C++ using the formula for F n given on the previous slide.

16 ENCM 339 Fall 2016 Slide Set 18 slide 16/26 Time to repeatedly compute F million times on my Mac, using a simple loop: 3.0 seconds. Average time to compute F 50 once: 30 nanoseconds. Time to compute F 50 once on my Mac, using the obvious recursive function: 68.5 seconds. The recursive function is slower by a factor of about 2.3 billion. What is going on with the recursive function?! To get some understanding, let s determine the number of calls that result when n == 5 in the original call to the recursive version of fibo.

17 ENCM 339 Fall 2016 Slide Set 18 slide 17/26 The problem with the recursive definition is that it does a huge amount of redundant work. This table shows how quickly things go bad as n increases... original value of n # of calls to fibo , ,692, ,160, ,730,022,147

18 ENCM 339 Fall 2016 Slide Set 18 slide 18/26 Review: Fundamental rules of recursion 1. Base cases: There must be at least one version of a problem that is so simple that it can be solved without a recursive call. 2. Always make progress: A recursive call must in some sense move in the direction of a base case. 3. Design rule: When designing a recursive function, believe that the recursive calls will work. 4. Performance rule: Performance may be very poor if a recursive function solves exactly the same problem many times.

19 ENCM 339 Fall 2016 Slide Set 18 slide 19/26 Fast recursive solutions for computing F n There are some fast recursive ways to compute F n, based on this formula: F n = [ 0 1 ] [ ] n [ ] What does it mean to raise a matrix to a power? Here s an example: [ ] 3 = [ ] [ ] [ That leads back to the first example of recursion in Slide Set 19, efficient computation of a power function, but we won t go into details... ]

20 ENCM 339 Fall 2016 Slide Set 18 slide 20/26 Outline of Slide Set 18 Attention! Performance of some recursive functions Recursive traversal of part of a file system

21 ENCM 339 Fall 2016 Slide Set 18 slide 21/26 Recursive traversal of part of a file system Reminder: In discussion of computer file systems, directory is a synonym for folder. Most computer users understand that a directory can contain a mix of directories and regular files. A simple example of that is shown on the next slide...

22 ENCM 339 Fall 2016 Slide Set 18 slide 22/26 Here are 5 directories and 9 regular files... projects Ccode Cplusplus hello prog2 a.out hello.c notes.txt a.out hello.cpp a.out MyClass.cpp MyClass.h prog2.cpp

23 ENCM 339 Fall 2016 Slide Set 18 slide 23/26 Suppose that we would like to start at a directory such as projects, and report on the sizes of all the regular files that can be found in that directory, in directories within that directory, and so on... projects Ccode a.out hello.c Cplusplus hello a.out hello.cpp notes.txt prog2 a.out MyClass.cpp MyClass.h prog2.cpp 9591 bytes 80 bytes bytes 93 bytes 78 bytes bytes 104 bytes 163 bytes 213 bytes (The above text is actual output from a program I wrote.)

24 ENCM 339 Fall 2016 Slide Set 18 slide 24/26 Unfortunately, it s impossible to write code that will do the right thing on every possible platform that has a standard implementation of C or C++. That s because the standard C and C++ libraries don t have functions for things like please open a directory or please give me information about this item in a directory. Such functions definitely exist, but they re not standardized across all platforms that support C or C++. The next slide shows a mix of C code and pseudocode that solves the problem on Linux. Let s make some notes about how the function on the next slide works.

25 void filetree(const char *dirname, int indent) { DIR *dirp = opendir(dirname); bail out if opendir was unsuccessful ; chdir(dirname); while (1) { struct dirent *direntp = readdir(dirp); if (direntp == NULL) break; print indent spaces, then print direntp->d_name ; if (direntp->d_type says regular file ) print size of file in bytes, then \n ; else if (direntp->d_type says directory ) { print \n ; chdir(direntp->d_name); filetree(".", indent + 2); // recursive call! chdir(".."); } } closedir(dirp); }

26 ENCM 339 Fall 2016 Slide Set 18 slide 26/26 The sketch of filetree is clear about the fact that opendir could fail. However, to save space on the previous slide, these checks were omitted... a check for abnormal failure of readdir (as opposed to normal failure, which is getting to the end of the list of items in a directory); checks for failure of chdir and closedir. Some other important details were omitted as well! I ll post complete C source code on the Web with comments that explain those details.