1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
|
The GDB Performance Testsuite
=============================
This README contains notes on hacking on GDB's performance testsuite.
For notes on GDB's regular testsuite or how to run the performance testsuite,
see ../README.
Generated tests
***************
The testcase generator lets us easily test GDB on large programs.
The "monster" tests are mocks of real programs where GDB's
performance has been a problem. Often it is difficult to build
these monster programs, but when measuring performance one doesn't
need the "real" program, all one needs is something that looks like
the real program along the axis one is measuring; for example, the
number of CUs (compilation units).
Structure of generated tests
****************************
Generated tests consist of a binary and potentially any number of
shared libraries. One of these shared libraries, called "tail", is
special. It is used to provide mocks of system provided code, and
contains no generated code. Typically system-provided libraries
are searched last which can have significant performance consequences,
so we provide a means to exercise that.
The binary and the generated shared libraries can have a mix of
manually written and generated code. Manually written code is
specified with the {binary,gen_shlib}_extra_sources config parameters,
which are lists of source files in testsuite/gdb.perf. Generated
files are controlled with various configuration knobs.
Once a large test program is built, it makes sense to use it as much
as possible (i.e., with multiple tests). Therefore perf data collection
for generated tests is split into two passes: the first pass builds
all the generated tests, and the second pass runs all the performance
tests. The first pass is called "build-perf" and the second pass is
called "check-perf". See ../README for instructions on running the tests.
Generated test directory layout
*******************************
All output lives under testsuite/gdb.perf in the build directory.
Because some of the tests can get really large (and take potentially
minutes to compile), parallelism is built into their compilation.
Note however that we don't run the tests in parallel as it can skew
the results.
To keep things simple and stay consistent, we use the same
mechanism used by "make check-parallel". There is one catch: we need
one .exp for each "worker" but the .exp file must come from the source
tree. To avoid generating .exp files for each worker we invoke
lib/build-piece.exp for each worker with different arguments.
The file build.piece.exp lives in "lib" to prevent dejagnu from finding
it when it goes to look for .exp scripts to run.
Another catch is that each parallel build worker needs its own directory
so that their gdb.{log,sum} files don't collide. On the other hand
its easier if their output (all the object files and shared libraries)
are in the same directory.
The above considerations yield the resulting layout:
$objdir/testsuite/gdb.perf/
gdb.log, gdb.sum: result of doing final link and running tests
workers/
gdb.log, gdb.sum: result of gen-workers step
$program_name/
${program_name}-0.worker
...
${program_name}-N.worker: input to build-pieces step
outputs/
${program_name}/
${program_name}-0/
...
${program_name}-N/
gdb.log, gdb.sum: for each build-piece worker
pieces/
generated sources, object files, shlibs
${run_name_1}: binary for test config #1
...
${run_name_N}: binary for test config #N
Generated test configuration knobs
**********************************
The monster program generator provides various knobs for building various
kinds of monster programs. For a list of the knobs see function
GenPerfTest::init_testcase in testsuite/lib/perftest.exp.
Most knobs are self-explanatory.
Here is a description of the less obvious ones.
binary_extra_sources
This is the list of non-machine generated sources that go
into the test binary. There must be at least one: the one
with main.
class_specs
List of pairs of keys and values.
Supported keys are:
count: number of classes
Default: 1
name: list of namespaces and class name prefix
E.g., { ns0 ns1 foo } -> ns0::ns1::foo_<cu#>_{0,1,...}
There is no default, this value must be specified.
nr_members: number of members
Default: 0
nr_static_members: number of static members
Default: 0
nr_methods: number of methods
Default: 0
nr_inline_methods: number of inline methods
Default: 0
nr_static_methods: number of static methods
Default: 0
nr_static_inline_methods: number of static inline methods
Default: 0
E.g.,
class foo {};
namespace ns1 { class bar {}; }
would be represented as:
{
{ count 1 name { foo } }
{ count 1 name { ns1 bar } }
}
The naming of each class is "class_<cu_nr>_<class_nr>",
where <cu_nr> is the number of the compilation unit the
class is defined in.
There's currently no support for nesting classes in classes,
or for specifying baseclasses or templates.
Misc. configuration knobs
*************************
These knobs control building or running of the test and are specified
like any global Tcl variable.
CAT_PROGRAM
Default is /bin/cat, you shouldn't need to change this.
SHA1SUM_PROGRAM
Default is /usr/bin/sha1sum.
PERF_TEST_COMPILE_PARALLELISM
An integer, specifies the amount of parallelism in the builds.
Akin to make's -j flag. The default is 10.
Writing a generated test program
********************************
The best way to write a generated test program is to take an existing
one as boilerplate. Two good examples are gmonster1.exp and gmonster2.exp.
gmonster1.exp builds a big binary with various custom manually written
code, and gmonster2 is (essentially) the equivalent binary split up over
several shared libraries.
Writing a performance test that uses a generated program
********************************************************
The best way to write a test is to take an existing one as boilerplate.
Good examples are gmonster1-*.exp and gmonster2-*.exp.
The naming used thus far is that "foo.exp" builds the test program
and there is one "foo-bar.exp" file for each performance test
that uses test program "foo".
In addition to writing the test driver .exp script, one must also
write a python script that is used to run the test.
This contents of this script is defined by the performance testsuite
harness. It defines a class, which is a subclass of one of the
classes in gdb.perf/lib/perftest/perftest.py.
See gmonster-null-lookup.py for an example.
Note: Since gmonster1 and gmonster2 are treated as being variations of
the same program, each test shares the same python script.
E.g., gmonster1-null-lookup.exp and gmonster2-null-lookup.exp
both use gmonster-null-lookup.py.
Running performance tests for generated programs
************************************************
There are two steps: build and run.
Example:
bash$ make -j10 build-perf RUNTESTFLAGS="gmonster1.exp"
bash$ make -j10 check-perf RUNTESTFLAGS="gmonster1-null-lookup.exp" \
GDB_PERFTEST_MODE=run
|
