forked from pyston/pyston_v1
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathPROFILING
37 lines (28 loc) · 2.21 KB
/
PROFILING
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
turning off ASLR:
$ echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
gdb does this automatically, but disabling it outside of gdb can be nice to correlate runs with other runs or debugging.
for better tracebacks, make sure that NoFramePointerElim is set to true in entry.cpp
Profiling Pyston internally has gone through a number of iterations; the current approach is to use the "perf" tool.
This can be used by doing "make perf_test_name", which will automatically run the test under perf, with the
corresponding flags to dump the necessary output, and the collect and process it at the end.
There's a tool called annotate.py in the tools/ directory that can combine the results of perf and data dumped from the
run, to get instruction-level profiles; this is supported directly in perf for non-JIT'd functions, but I couldn't
figure out another way to get it working for JIT'd ones.
Note: this tool will show the *final* assembly code that was output, ie with all the patchpoints filled in with whatever
code they had at the exit of the program.
I tried gperftools; this uses a statistical sampler and might make sense for longer running programs or tests, but
doesn't generate enough data for short-lived behavior such as JIT startup.
I tried oprofile; the current behavior in the Makefile uses the deprecated "opcontrol" which has some issues with losing
some data samples. There's another "operf" rule, but operf doesn't seem to support the OProfile JIT hooks and misses
the JIT'd code.
There's a gprof-based profile, but that doesn't support any JIT'd code. It can be quite handy for profiling the Pyston
codegen + LLVM cost.
We also have a few internal timers that log important sections of code. You can see their totals by passing '-s' to
the executable (ARGS=-s to a Make recipe).
Some common ones are:
- us_compiling: total amount of time (in microseconds) spent in 'codegen', from
the time we decide we want to run some Python code to the point that we can
start executing it
- us_compiling_irgen: total time creating the LLVM IR. includes some analysis time
- us_compiling_jitting: subset of us_compiling which is spent in LLVM
compilation (time from giving LLVM its IR to when we get machine code back)