Cách cấu hình ứng dụng C++ của tôi trên linux

Question

Tôi muốn cấu hình ứng dụng C++ của mình trên Linux. Tôi muốn tìm hiểu xem ứng dụng của tôi đã dành bao nhiêu thời gian cho xử lý CPU so với thời gian dành cho khối bằng IO/không hoạt động.

Tôi biết có một công cụ hồ sơ gọi valgrind trên linux. Nhưng nó phá vỡ thời gian dành cho mỗi phương pháp, và nó không cho tôi một bức tranh tổng thể về lượng thời gian dành cho xử lý CPU và không hoạt động? Hoặc có cách nào để làm điều đó với valgrind.

Answer 1

Tôi có thể giới thiệu công cụ valgrind 's callgrind kết hợp với KCacheGrind để hiển thị. KCacheGrind làm cho nó khá dễ dàng để xem nơi các điểm nóng được.

Lưu ý: Đã quá lâu kể từ khi tôi sử dụng, vì vậy tôi không chắc liệu bạn có thể nhận được I/O Thời gian chờ đợi không. Có lẽ kết hợp với iostat hoặc pidstat bạn sẽ có thể xem tất cả thời gian đã được chi tiêu ở đâu.

Answer 2

Khám phá oprofile. Ngoài ra, để có thêm chẩn đoán cấp hệ thống, hãy thử systemtap.

Answer 3

Dụng cụ rút gọn và/hoặc công cụ trợ giúp trong valgrind sẽ cho phép bạn thực hiện việc này.

Answer 4

callgrind là một công cụ rất tốt nhưng tôi thấy OProfile cho tôi nhiều hơn 'hoàn thành'. Ngoài ra, nó là phần duy nhất cho phép bạn chỉ định mô-đun và/hoặc nguồn nhân để cho phép cái nhìn sâu sắc hơn vào các nút cổ chai của bạn. Đầu ra được cho là có khả năng giao tiếp với KCacheGrind nhưng tôi đã gặp rắc rối với điều đó vì vậy tôi đã sử dụng Gprof2Dot để thay thế. Bạn có thể xuất khẩu biểu đồ của bạn thành tệp .png.

Edit:

oprofile nhìn vào toàn bộ hệ thống nên quá trình này sẽ chỉ là:

[setup oprofile]

opcontrol --init 
opcontorl --vmlinux=/path/to/vmlinux  (or --no-vmlinux) 
opcontrol --start 

[chạy ứng dụng của bạn ở đây]

opcontrol --stop (or opcontrol --shutdown [man for difference] 

sau đó để bắt đầu xem kết quả xem trang người đàn ông trên opreport

Answer 5

LTTng là một công cụ tốt để sử dụng cho toàn bộ cấu hình hệ thống.

Answer 6

Bạn có thể muốn xem Zoom, được đánh bóng hơn và đầy đủ tính năng hơn oprofile et al. Nó tốn tiền ($ 199), nhưng bạn có thể nhận được giấy phép đánh giá 30 ngày miễn phí.

Answer 7

Nếu ứng dụng của bạn chỉ chạy "phẳng" (nghĩa là sử dụng CPU hoặc chờ I/O) cho đến khi thoát, và không có quá trình cạnh tranh khác, chỉ cần time myapp (hoặc có thể là /usr/bin/time myapp, đầu ra khác nhau cho nội trang hệ vỏ).

Điều này sẽ giúp bạn có được một cái gì đó như:

real 0m1.412s 
user 0m1.288s 
sys  0m0.056s 

Trong trường hợp này, người sử dụng + sys (kernel) tài khoản thời gian cho hầu hết tất cả các thời gian thực và có chỉ 0.068s mất tích ... (có thể là thời gian dành cho bắt đầu tải ứng dụng và các lib hỗ trợ của nó).

Tuy nhiên, nếu bạn đã xem:

real 0m5.732s 
user 0m1.144s 
sys  0m0.078s 

sau đó ứng dụng của bạn dành 4.51s không tốn nhiều CPU và có lẽ bị chặn trên IO. Đó là thông tin tôi nghĩ bạn đang tìm kiếm.

Tuy nhiên, khi kỹ thuật phân tích đơn giản này bị phá vỡ là:

• Apps mà chờ đợi vào một bộ đếm thời gian/đồng hồ hoặc kích thích bên ngoài khác (ví dụ hướng sự kiện GUI ứng dụng). Không thể phân biệt thời gian chờ đợi trên đồng hồ và thời gian chờ trên đĩa/mạng.
• Ứng dụng đa luồng, cần suy nghĩ một chút về cách diễn giải các con số.

Answer 8

See this post.

And this post.

Về cơ bản, giữa thời gian chương trình bắt đầu và khi nó kết thúc, nó có một cuộc gọi stack. Trong I/O, ngăn xếp kết thúc trong một cuộc gọi hệ thống. Trong quá trình tính toán, nó kết thúc bằng một lệnh điển hình.

Dù bằng cách nào, nếu bạn có thể lấy mẫu ngăn xếp ngẫu nhiên vào giờ đồng hồ, bạn có thể thấy chính xác lý do tại sao chi tiêu thời gian đó.

Điểm duy nhất còn lại là - hàng nghìn mẫu có thể mang lại cảm giác tự tin, nhưng chúng sẽ không cho bạn biết nhiều hơn 10 hoặc 20 mẫu.

Answer 9

google-perf-tools - thay thế nhanh hơn nhiều cho callgrind (và nó có thể tạo ra đầu ra với cùng định dạng như callgrind, vì vậy bạn có thể sử dụng KCacheGrind).