[176] | 1 | <?xml version="1.0" encoding="UTF-8"?> |
---|
| 2 | <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN" "http://forrest.apache.org/dtd/document-v20.dtd"> |
---|
| 3 | <document> |
---|
| 4 | |
---|
| 5 | <header> |
---|
| 6 | <title>Screenshots</title> |
---|
| 7 | </header> |
---|
| 8 | |
---|
| 9 | <body> |
---|
| 10 | |
---|
| 11 | <p> |
---|
| 12 | Because Hoard is a transparent plug-in replacement, ordinary |
---|
| 13 | screenshots don't make much sense, since the applications look and |
---|
| 14 | work the same! However, it's easy to visualize Hoard's impact on |
---|
| 15 | application performance. Here are a few example speedup |
---|
| 16 | graphs. Ideally, the speedup as the number of processors increases |
---|
| 17 | is a straight diagonal line going from the lower left of each graph |
---|
| 18 | to the upper right. These benchmarks compare Hoard to Ptmalloc (the |
---|
| 19 | Linux allocator), mtmalloc version 8, and the Solaris default |
---|
| 20 | allocator, and are run on a 14-processor Sun. |
---|
| 21 | </p> |
---|
| 22 | |
---|
| 23 | <table> |
---|
| 24 | <tr> |
---|
| 25 | <td> |
---|
| 26 | <!-- <center> --> |
---|
| 27 | <img alt="Threadtest graph" src="images/plot-threadtest-speedup.gif"/> |
---|
| 28 | <!-- </center> --> |
---|
| 29 | </td> |
---|
| 30 | </tr> |
---|
| 31 | <tr> |
---|
| 32 | <td> |
---|
| 33 | <!-- <center> --> |
---|
| 34 | <p> |
---|
| 35 | This benchmark has multiple threads, each allocating and freeing |
---|
| 36 | objects. It stresses raw scalability of allocation in individual |
---|
| 37 | threads. In this case, Hoard achieves a linear speedup. Ptmalloc |
---|
| 38 | scales to four processors but then runs out of steam. |
---|
| 39 | </p> |
---|
| 40 | <!-- </center> --> |
---|
| 41 | </td> |
---|
| 42 | </tr> |
---|
| 43 | <tr> |
---|
| 44 | <td> |
---|
| 45 | <!-- <center> --> |
---|
| 46 | <img alt="Larson graph" src="images/plot-larson-speedup.gif"/> |
---|
| 47 | <!-- </center> --> |
---|
| 48 | </td> |
---|
| 49 | </tr> |
---|
| 50 | <tr> |
---|
| 51 | <td> |
---|
| 52 | <!-- <center> --> |
---|
| 53 | <p> |
---|
| 54 | In this benchmark, multiple threads allocate objects and pass some |
---|
| 55 | objects to other threads that free them. This stresses the ability |
---|
| 56 | of the memory manager to handle object sharing. Only Hoard scales |
---|
| 57 | for this case. |
---|
| 58 | </p> |
---|
| 59 | <!-- </center> --> |
---|
| 60 | </td> |
---|
| 61 | </tr> |
---|
| 62 | <tr> |
---|
| 63 | <td> |
---|
| 64 | <!-- <center> --> |
---|
| 65 | <img alt="Cache-scratch graph" src="images/plot-cache-scratch-speedup.gif"/> |
---|
| 66 | <!-- </center> --> |
---|
| 67 | </td> |
---|
| 68 | </tr> |
---|
| 69 | <tr> |
---|
| 70 | <td> |
---|
| 71 | <!-- <center> --> |
---|
| 72 | <p> |
---|
| 73 | A test of whether a memory manager avoids causing false sharing of |
---|
| 74 | cache lines (an insidious effect that destroys scalability). The |
---|
| 75 | linear speedup shows that Hoard avoids false sharing completely. |
---|
| 76 | </p> |
---|
| 77 | <!-- </center> --> |
---|
| 78 | </td> |
---|
| 79 | </tr> |
---|
| 80 | </table> |
---|
| 81 | |
---|
| 82 | </body> |
---|
| 83 | </document> |
---|