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> |
---|