C ++ 프로파일 링 기술 조사
이 답변에서는 여러 도구를 사용하여 몇 가지 매우 간단한 테스트 프로그램을 분석하여 해당 도구의 작동 방식을 구체적으로 비교합니다.
다음 테스트 프로그램은 매우 간단하며 다음을 수행합니다.
main통화 fast및 maybe_slow3 회, maybe_slow통화 중 하나 가 느림
의 느린 호출 maybe_slow은 10 배 더 길며 자식 함수 호출을 고려하면 런타임을 지배합니다 common. 이상적으로 프로파일 링 도구는 특정 느린 호출을 가리킬 수 있습니다.
모두 fast와 maybe_slow전화 common프로그램 실행의 대부분을 차지하고,
프로그램 인터페이스는 다음과 같습니다
./main.out [n [seed]]
프로그램은 O(n^2)총 루프를 수행합니다. seed런타임에 영향을 미치지 않고 다른 출력을 얻는 것입니다.
main.c
#include <inttypes.h>
#include <stdio.h>
#include <stdlib.h>
uint64_t __attribute__ ((noinline)) common(uint64_t n, uint64_t seed) {
for (uint64_t i = 0; i < n; ++i) {
seed = (seed * seed) - (3 * seed) + 1;
}
return seed;
}
uint64_t __attribute__ ((noinline)) fast(uint64_t n, uint64_t seed) {
uint64_t max = (n / 10) + 1;
for (uint64_t i = 0; i < max; ++i) {
seed = common(n, (seed * seed) - (3 * seed) + 1);
}
return seed;
}
uint64_t __attribute__ ((noinline)) maybe_slow(uint64_t n, uint64_t seed, int is_slow) {
uint64_t max = n;
if (is_slow) {
max *= 10;
}
for (uint64_t i = 0; i < max; ++i) {
seed = common(n, (seed * seed) - (3 * seed) + 1);
}
return seed;
}
int main(int argc, char **argv) {
uint64_t n, seed;
if (argc > 1) {
n = strtoll(argv[1], NULL, 0);
} else {
n = 1;
}
if (argc > 2) {
seed = strtoll(argv[2], NULL, 0);
} else {
seed = 0;
}
seed += maybe_slow(n, seed, 0);
seed += fast(n, seed);
seed += maybe_slow(n, seed, 1);
seed += fast(n, seed);
seed += maybe_slow(n, seed, 0);
seed += fast(n, seed);
printf("%" PRIX64 "\n", seed);
return EXIT_SUCCESS;
}
gprof
gprof는 계측으로 소프트웨어를 다시 컴파일해야하며, 계측과 함께 샘플링 방식도 사용합니다. 따라서 정확도 (샘플링이 항상 정확하지는 않으며 기능을 건너 뛸 수 있음)와 실행 속도 저하 (계측 및 샘플링은 실행 속도를 크게 저하시키지 않는 비교적 빠른 기술) 사이의 균형을 유지합니다.
gprof는 GCC / binutils에 내장되어 있으므로 -pggprof를 활성화 하는 옵션으로 컴파일 하면됩니다. 그런 다음 몇 초 ( 10000) 의 적당한 기간 동안 실행되는 size CLI 매개 변수를 사용하여 프로그램을 정상적으로 실행합니다 .
gcc -pg -ggdb3 -O3 -std=c99 -Wall -Wextra -pedantic -o main.out main.c
time ./main.out 10000
교육상의 이유로 최적화를 사용하지 않고 실행도 수행합니다. 일반적으로 최적화 된 프로그램의 성능 최적화에만 관심이 있기 때문에 실제로는 쓸모가 없습니다.
gcc -pg -ggdb3 -O0 -std=c99 -Wall -Wextra -pedantic -o main.out main.c
./main.out 10000
첫째, time유무에 관계없이 실행 시간 -pg이 동일 하다는 것을 알 수 있습니다 . 그러나이 티켓에 나와있는 것처럼 복잡한 소프트웨어에서 2x-3x 속도 저하가 발생했습니다 .
로 컴파일 했으므로 -pg프로그램을 실행 gmon.out하면 프로파일 링 데이터가 포함 된 파일 파일이 생성 됩니다.
우리는 그래픽으로 해당 파일을 관찰 할 수 gprof2dot에서 질문과 같이 이 gprof은 결과의 그래픽 표현을 얻을 수 있습니까?
sudo apt install graphviz
python3 -m pip install --user gprof2dot
gprof main.out > main.gprof
gprof2dot < main.gprof | dot -Tsvg -o output.svg
여기서, gprof공구가 판독 gmon.out추적 정보와의 판독 가능한 보고서 생성 main.gprof, gprof2dot다음 그래프를 생성하기 위해 판독한다.
gprof2dot의 출처는 https://github.com/jrfonseca/gprof2dot입니다.
-O0실행에 대해 다음을 관찰합니다 .
그리고 -O3실행을 위해 :
-O0출력은 거의 자명하다. 예를 들어, 3 개의 maybe_slow호출과 해당 자식 호출이 총 런타임의 97.56 %를 차지하지만 maybe_slow자식없이 자체 실행 하는 것이 총 실행 시간의 0.00 %를 차지합니다. 즉, 해당 함수에 소비 된 거의 모든 시간이 어린이 전화.
TODO : 왜 GDB에서 출력을 볼 수 있는데 출력 main에서 누락 되었습니까? GProf 출력에서 누락 된 기능 나는 gprof가 컴파일 된 계측 외에도 샘플링을 기반으로하고 있기 때문에 너무 빠르며 샘플 이 없기 때문이라고 생각합니다 .-O3bt-O3 main
SVG는 Ctrl + F로 검색 가능하고 파일 크기는 약 10 배 작을 수 있기 때문에 PNG 대신 SVG 출력을 선택합니다. 또한 생성 된 이미지의 너비와 높이는 복잡한 소프트웨어의 경우 수만 개의 픽셀로 eog가득 차 있으며 PNG의 경우 그놈 3.28.1 버그가 발생하지만 SVG는 브라우저에서 자동으로 열립니다. 김프 2.8도 잘 작동했습니다.
그러나 그때까지도 이미지를 많이 드래그하여 원하는 것을 찾을 수 있습니다. 예를 들어이 티켓 에서 가져온 "실제"소프트웨어 예의 이미지를 참조하십시오 .
모든 분류되지 않은 작은 스파게티 라인이 서로 연결되어 가장 중요한 통화 스택을 쉽게 찾을 수 있습니까? 더 나은 dot옵션 이있을 수 있지만 지금은 가고 싶지 않습니다. 우리에게 정말로 필요한 것은 그것을위한 적절한 전용 뷰어이지만 아직 찾지 못했습니다.
그러나 색상 맵을 사용하여 이러한 문제를 약간 완화 할 수 있습니다. 예를 들어, 이전의 거대한 이미지에서 나는 녹색이 빨간색을 쫓은 화려한 공제를했을 때 마침내 왼쪽에서 중요한 경로를 찾았습니다.
또는 gprof이전에 저장 한 내장 binutils 도구 의 텍스트 출력을 관찰 할 수도 있습니다 .
cat main.gprof
기본적으로 출력 데이터의 의미를 설명하는 매우 자세한 출력을 생성합니다. 그보다 더 잘 설명 할 수 없기 때문에 직접 읽어 보도록하겠습니다.
데이터 출력 형식을 이해 한 후에는 -b옵션 없이 튜토리얼없이 데이터 만 표시하도록 상세도를 줄일 수 있습니다 .
gprof -b main.out
이 예에서 출력은 다음과 -O0같습니다.
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls s/call s/call name
100.35 3.67 3.67 123003 0.00 0.00 common
0.00 3.67 0.00 3 0.00 0.03 fast
0.00 3.67 0.00 3 0.00 1.19 maybe_slow
Call graph
granularity: each sample hit covers 2 byte(s) for 0.27% of 3.67 seconds
index % time self children called name
0.09 0.00 3003/123003 fast [4]
3.58 0.00 120000/123003 maybe_slow [3]
[1] 100.0 3.67 0.00 123003 common [1]
-----------------------------------------------
<spontaneous>
[2] 100.0 0.00 3.67 main [2]
0.00 3.58 3/3 maybe_slow [3]
0.00 0.09 3/3 fast [4]
-----------------------------------------------
0.00 3.58 3/3 main [2]
[3] 97.6 0.00 3.58 3 maybe_slow [3]
3.58 0.00 120000/123003 common [1]
-----------------------------------------------
0.00 0.09 3/3 main [2]
[4] 2.4 0.00 0.09 3 fast [4]
0.09 0.00 3003/123003 common [1]
-----------------------------------------------
Index by function name
[1] common [4] fast [3] maybe_slow
그리고 -O3:
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls us/call us/call name
100.52 1.84 1.84 123003 14.96 14.96 common
Call graph
granularity: each sample hit covers 2 byte(s) for 0.54% of 1.84 seconds
index % time self children called name
0.04 0.00 3003/123003 fast [3]
1.79 0.00 120000/123003 maybe_slow [2]
[1] 100.0 1.84 0.00 123003 common [1]
-----------------------------------------------
<spontaneous>
[2] 97.6 0.00 1.79 maybe_slow [2]
1.79 0.00 120000/123003 common [1]
-----------------------------------------------
<spontaneous>
[3] 2.4 0.00 0.04 fast [3]
0.04 0.00 3003/123003 common [1]
-----------------------------------------------
Index by function name
[1] common
각 섹션에 대한 매우 빠른 요약 예 :
0.00 3.58 3/3 main [2]
[3] 97.6 0.00 3.58 3 maybe_slow [3]
3.58 0.00 120000/123003 common [1]
들여 쓰기 된 기능을 중심으로합니다 ( maybe_flow). [3]해당 함수의 ID입니다. 함수 위에는 호출자가 있고 그 아래에는 호출자가 있습니다.
에 대해서는 -O3그래픽 출력에서 maybe_slow와 fast같이 알려진 부모가없는 문서를 참조하십시오 <spontaneous>.
gprof로 라인 별 프로파일 링을 수행하는 좋은 방법이 있는지 확실하지 않습니다. 특정 코드 라인에서 보낸 ' gprof '시간
valgrind callgrind
valgrind는 valgrind 가상 머신을 통해 프로그램을 실행합니다. 이렇게하면 프로파일 링이 매우 정확 해지지 만 프로그램 속도가 크게 느려집니다. 나는 또한 kcachegrind에 대해 언급했다 : 코드의 그림 함수 호출 그래프를 얻는 도구
callgrind는 코드를 프로파일 링하는 valgrind의 도구이고 kcachegrind는 cachegrind 출력을 시각화 할 수있는 KDE 프로그램입니다.
먼저 -pg일반 컴파일로 돌아가려면 플래그 를 제거해야합니다 . 그렇지 않으면 실행이 실제로 실패 Profiling timer expired하고 그렇습니다. 그렇습니다.
따라서 다음과 같이 컴파일하고 실행합니다.
sudo apt install kcachegrind valgrind
gcc -ggdb3 -O3 -std=c99 -Wall -Wextra -pedantic -o main.out main.c
time valgrind --tool=callgrind valgrind --dump-instr=yes \
--collect-jumps=yes ./main.out 10000
--dump-instr=yes --collect-jumps=yes이것은 또한 추가 된 오버 헤드 비용으로 어셈블리 라인 당 성능 저하를 볼 수있는 정보를 덤프하기 때문에 가능 합니다.
박쥐 time가 프로그램을 실행하는 데 29.5 초가 걸렸다 고 알려주므로이 예제에서는 약 15 배의 속도가 느려졌습니다. 분명히이 둔화는 더 큰 워크로드에 심각한 제한이 될 것입니다. 여기 에 언급 된 "실제 소프트웨어 예" 에서 80 배의 속도 저하를 관찰했습니다.
런라는 이름의 프로파일 데이터 파일 생성 callgrind.out.<pid>예를 들어 callgrind.out.8554내 경우를. 우리는 그 파일을 다음과 같이 봅니다 :
kcachegrind callgrind.out.8554
텍스트 gprof 출력과 유사한 데이터를 포함하는 GUI를 보여줍니다.
또한 오른쪽 하단의 "콜 그래프"탭으로 이동하면 마우스 오른쪽 버튼을 클릭하여 내보낼 수있는 콜 그래프를 볼 수 있습니다.
fastkcachegrind가 호출에 너무 적은 시간이 걸리기 때문에 시각화를 단순화해야했기 때문에 해당 그래프에 표시되지 않는다고 생각 합니다. 실제 프로그램에서 원하는 동작 일 것입니다. 마우스 오른쪽 버튼 메뉴에는 이러한 노드를 컬링하는시기를 제어하는 몇 가지 설정이 있지만 빠른 시도 후 짧은 호출을 표시하지 못했습니다. fast왼쪽 창을 클릭 하면와 함께 호출 그래프가 표시되어 fast실제로 스택이 캡처되었습니다. 아직 완전한 그래프 호출 그래프를 표시하는 방법을 찾지 못했습니다 : callgrind가 kcachegrind 호출 그래프에서 모든 함수 호출을 표시하도록하십시오.
복잡한 C ++ 소프트웨어의 TODO에서 유형의 일부 항목을 볼 수 있습니다 <cycle N>. 예를 들어 <cycle 11>함수 이름이 필요한 위치는 무엇입니까? "Cycle Detection (사이클 감지)"버튼을 사용하여이 기능을 켜고 끌 수 있지만 그 의미는 무엇입니까?
perf ...에서 linux-tools
perf독점적으로 Linux 커널 샘플링 메커니즘을 사용하는 것 같습니다. 따라서 설정이 매우 간단하지만 완전히 정확하지는 않습니다.
sudo apt install linux-tools
time perf record -g ./main.out 10000
이것은 실행에 0.2 초를 추가 했으므로 시간이 좋지만 common키보드 오른쪽 화살표로 노드를 확장 한 후에도 여전히 관심이 없습니다 .
Samples: 7K of event 'cycles:uppp', Event count (approx.): 6228527608
Children Self Command Shared Object Symbol
- 99.98% 99.88% main.out main.out [.] common
common
0.11% 0.11% main.out [kernel] [k] 0xffffffff8a6009e7
0.01% 0.01% main.out [kernel] [k] 0xffffffff8a600158
0.01% 0.00% main.out [unknown] [k] 0x0000000000000040
0.01% 0.00% main.out ld-2.27.so [.] _dl_sysdep_start
0.01% 0.00% main.out ld-2.27.so [.] dl_main
0.01% 0.00% main.out ld-2.27.so [.] mprotect
0.01% 0.00% main.out ld-2.27.so [.] _dl_map_object
0.01% 0.00% main.out ld-2.27.so [.] _xstat
0.00% 0.00% main.out ld-2.27.so [.] __GI___tunables_init
0.00% 0.00% main.out [unknown] [.] 0x2f3d4f4944555453
0.00% 0.00% main.out [unknown] [.] 0x00007fff3cfc57ac
0.00% 0.00% main.out ld-2.27.so [.] _start
그런 다음 -O0프로그램 을 벤치마킹하여 그것이 무엇인가를 나타내는 지 확인 하려고합니다 . 마지막으로 콜 그래프가 표시됩니까?
Samples: 15K of event 'cycles:uppp', Event count (approx.): 12438962281
Children Self Command Shared Object Symbol
+ 99.99% 0.00% main.out [unknown] [.] 0x04be258d4c544155
+ 99.99% 0.00% main.out libc-2.27.so [.] __libc_start_main
- 99.99% 0.00% main.out main.out [.] main
- main
- 97.54% maybe_slow
common
- 2.45% fast
common
+ 99.96% 99.85% main.out main.out [.] common
+ 97.54% 0.03% main.out main.out [.] maybe_slow
+ 2.45% 0.00% main.out main.out [.] fast
0.11% 0.11% main.out [kernel] [k] 0xffffffff8a6009e7
0.00% 0.00% main.out [unknown] [k] 0x0000000000000040
0.00% 0.00% main.out ld-2.27.so [.] _dl_sysdep_start
0.00% 0.00% main.out ld-2.27.so [.] dl_main
0.00% 0.00% main.out ld-2.27.so [.] _dl_lookup_symbol_x
0.00% 0.00% main.out [kernel] [k] 0xffffffff8a600158
0.00% 0.00% main.out ld-2.27.so [.] mmap64
0.00% 0.00% main.out ld-2.27.so [.] _dl_map_object
0.00% 0.00% main.out ld-2.27.so [.] __GI___tunables_init
0.00% 0.00% main.out [unknown] [.] 0x552e53555f6e653d
0.00% 0.00% main.out [unknown] [.] 0x00007ffe1cf20fdb
0.00% 0.00% main.out ld-2.27.so [.] _start
TODO : -O3처형은 어떻게 되었습니까? 그것은 단순히인가 maybe_slow하고 fast너무 빨리했다 및 샘플을하지 않았다? 실행 -O3하는 데 시간이 오래 걸리는 더 큰 프로그램에서 잘 작동합니까 ? CLI 옵션이 누락 되었습니까? 나는에 대해 알게 -F헤르츠의 샘플 주파수를 제어하는,하지만 난의 기본적으로 허용 최대로 켜져 -F 39500(증가 될 수있다 sudo)와 나는 아직도 선명한 통화가 표시되지 않습니다.
멋진 점 중 하나 perf는 Brendan Gregg의 FlameGraph 도구입니다.이 도구는 통화 스택 타이밍을 매우 깔끔하게 표시하여 큰 통화를 빠르게 볼 수 있도록합니다. 이 도구는에서 확인할 수 있습니다 https://github.com/brendangregg/FlameGraph 또한 그의 반환 한 튜토리얼에 언급 : http://www.brendangregg.com/perf.html#FlameGraphs 내가 달릴 때 perf없이 sudo내가 가진 ERROR: No stack counts found너무에 대한 이제 나는 그것을 할 것이다 sudo:
git clone https://github.com/brendangregg/FlameGraph
sudo perf record -F 99 -g -o perf_with_stack.data ./main.out 10000
sudo perf script -i perf_with_stack.data | FlameGraph/stackcollapse-perf.pl | FlameGraph/flamegraph.pl > flamegraph.svg
그러나 그러한 간단한 프로그램에서는 출력을 이해하기가 쉽지 maybe_slow않습니다 fast. 그래프에서 그래프 도 볼 수 없기 때문입니다.
보다 복잡한 예에서는 그래프의 의미가 분명해집니다.
TODO이 [unknown]예제 에는 함수 로그가 있는데 왜 그럴까요?
다른 perf GUI 인터페이스에는 다음이 포함됩니다.
gperftools
이전에 "Google 성능 도구"라고하는 출처 : https://github.com/gperftools/gperftools 샘플 기반.
먼저 다음을 사용하여 gperftools를 설치하십시오.
sudo apt install google-perftools
그런 다음 gperftools CPU 프로파일 러를 런타임 또는 빌드 타임의 두 가지 방법으로 활성화 할 수 있습니다.
런타임시, 우리는 설정 통과해야 LD_PRELOAD가리 키도록 libprofiler.so당신이 찾을 수있는 locate libprofiler.so, 예를 들어 내 시스템 :
gcc -ggdb3 -O3 -std=c99 -Wall -Wextra -pedantic -o main.out main.c
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libprofiler.so \
CPUPROFILE=prof.out ./main.out 10000
또는 링크 타임에 라이브러리를 빌드하여 LD_PRELOAD런타임에 전달 하지 않아도됩니다.
gcc -Wl,--no-as-needed,-lprofiler,--as-needed -ggdb3 -O3 -std=c99 -Wall -Wextra -pedantic -o main.out main.c
CPUPROFILE=prof.out ./main.out 10000
참조 : gperftools -하지 덤프 프로필 파일
내가 지금까지 찾은이 데이터를 보는 가장 좋은 방법은 pprof 출력을 kcachegrind가 입력 (예 : Valgrind-project-viewer-tool)과 동일한 형식으로 만들고 kcachegrind를 사용하여 다음을 확인하는 것입니다.
google-pprof --callgrind main.out prof.out > callgrind.out
kcachegrind callgrind.out
이러한 방법 중 하나를 사용하여 실행 한 후 prof.out프로파일 데이터 파일을 출력으로 얻습니다 . 다음을 사용하여 해당 파일을 그래픽으로 SVG로 볼 수 있습니다.
google-pprof --web main.out prof.out
다른 도구와 마찬가지로 친숙한 콜 그래프를 제공하지만 초 단위가 아닌 수 많은 샘플 단위로 구성됩니다.
또는 다음과 같은 텍스트 데이터를 얻을 수도 있습니다.
google-pprof --text main.out prof.out
이것은 다음을 제공합니다.
Using local file main.out.
Using local file prof.out.
Total: 187 samples
187 100.0% 100.0% 187 100.0% common
0 0.0% 100.0% 187 100.0% __libc_start_main
0 0.0% 100.0% 187 100.0% _start
0 0.0% 100.0% 4 2.1% fast
0 0.0% 100.0% 187 100.0% main
0 0.0% 100.0% 183 97.9% maybe_slow
도 참조 : 어떻게 도구를 규칙적 구글 사용
우분투 18.04, gprof2dot 2019.11.30, valgrind 3.13.0, perf 4.15.18, Linux 커널 4.15.0, FLameGraph 1a0dc6985aad06e76857cf2a354bd5ba0c9ce96b, gperftools 2.5-2에서 테스트되었습니다.
