일반적으로 다음을 보고하는 애플리케이션이 있습니다( time
명령 보고서).
real 1.59
user 1.42
sys 4.73
그러나 공유 라이브러리를 로드하고 실행하면 시간이 상당히 길어집니다( time
명령 보고서).
real 28.51
user 106.22
sys 5.23
내 공유 라이브러리 작업으로 인해 약간의 속도 향상이 예상되었지만(CentOS 및 Ubuntu에서는 2~4배가 보고될 것으로 예상됨), Fedora 24에서 위에 보고된 시간은 너무 깁니다.
보고서를 사용하려고 합니다 perf
.
255352.948615 task-clock:u (msec) # 3.895 CPUs utilized
0 context-switches:u # 0.000 K/sec
0 cpu-migrations:u # 0.000 K/sec
18,127 page-faults:u # 0.071 K/sec
664,852,184,198 cycles:u # 2.604 GHz (50.03%)
19,323,811,463 stalled-cycles-frontend:u # 2.91% frontend cycles idle (50.02%)
578,178,881,331 stalled-cycles-backend:u # 86.96% backend cycles idle (50.02%)
110,595,196,687 instructions:u # 0.17 insn per cycle
# 5.23 stalled cycles per insn (50.00%)
28,361,633,658 branches:u # 111.068 M/sec (50.01%)
777,249,031 branch-misses:u # 2.74% of all branches (50.01%)
65.564158710 seconds time elapsed
이는 CPU가 많은 시간 동안 유휴 상태임을 나타내는 것 같습니다. 하지만 코드에서 이런 일이 발생하는 위치를 찾으려고 노력 중입니다(내 애플리케이션의 전체 소스 코드와 관련 공유 라이브러리에 액세스할 수 있습니다). 또한 perf report
함수/시스템 호출에 소요된 시간의 백분율을 보고하는 것도 보았습니다 . 하지만 나는 그 이유를 이해할 수 있도록 더 미세한 수준, 즉 이러한 함수에서 어떤 줄이 있는지에 관심이 있습니다.
내 애플리케이션/공유 라이브러리에 대해 많은 정보를 제공하지 않았기 때문에 구체적인 조언을 제공하는 것이 쉽지 않다는 것이 다행입니다. 나는 코드에서 CPU가 대부분의 시간을 보내는 곳(또는 유휴 상태)을 파악하기 위해 제안/도구/아이디어를 찾고 있습니다.
glibc 2.23이 설치된 Fedora 24 Linux/x86_64입니다(제 응용 프로그램과 공유 라이브러리는 gcc 6.1.1 및 glibc 2.23으로 컴파일되었습니다).
답변1
이는 CPU가 많은 시간 동안 유휴 상태임을 나타내는 것 같습니다.
예. 87%의 시간입니다. 그러나 이것이 프로세서가 다른 작업과 프로세스를 처리하지 않는다는 의미는 아닙니다.
664,852,184,198 cycles:u # 2.604 GHz (50.03%)
19,323,811,463 stalled-cycles-frontend:u # 2.91% frontend cycles idle (50.02%)
578,178,881,331 stalled-cycles-backend:u # 86.96% backend cycles idle (50.02%)
110,595,196,687 instructions:u # 0.17 insn per cycle
CPU와 메모리 액세스를 더 잘 활용하도록 프로그램을 최적화하는 것은 복잡한 작업이며 코드가 없으면 더 자세히 답변하는 것이 불가능합니다.