Stacked-cycle-frontend và ngưng trệ-cycle-backend trong kết quả 'perf stat' là gì?


81

Có ai biết ý nghĩa của trì hoãn-chu kỳ-frontendngưng trệ-chu kỳ-phụ trợ trong kết quả thống kê hoàn thiện là gì không? Tôi đã tìm kiếm trên internet nhưng không tìm thấy câu trả lời. Cảm ơn

$ sudo perf stat ls                     

Performance counter stats for 'ls':

      0.602144 task-clock                #    0.762 CPUs utilized          
             0 context-switches          #    0.000 K/sec                  
             0 CPU-migrations            #    0.000 K/sec                  
           236 page-faults               #    0.392 M/sec                  
        768956 cycles                    #    1.277 GHz                    
        962999 stalled-cycles-frontend   #  125.23% frontend cycles idle   
        634360 stalled-cycles-backend    #   82.50% backend  cycles idle
        890060 instructions              #    1.16  insns per cycle        
                                         #    1.08  stalled cycles per insn
        179378 branches                  #  297.899 M/sec                  
          9362 branch-misses             #    5.22% of all branches         [48.33%]

   0.000790562 seconds time elapsed

Tôi không chắc câu hỏi thực sự ở đây là gì. Bạn đang hỏi frontend và backend của CPU là gì? Hãy đọc phần giới thiệu rất cao cấp này . Điều này có trả lời câu hỏi của bạn không?
Ali

Tôi đã tìm kiếm và tìm kiếm một câu trả lời tương tự ... Đây là địa chỉ tuyệt vời nhất mà tôi tìm thấy từ Intel: software.intel.com/en-us/articles/...
Jmoney38

Không, hầu như không ai biết những điều đó thực sự có ý nghĩa gì. Nhưng tham khảo hướng dẫn sử dụng (như trong câu trả lời của Manuel Selva) kết hợp với bài đăng này (mà tôi chưa hiểu rõ), là bài viết gần nhất mà tôi tìm thấy: sites.utexas.edu/jdm4372/2014/06/04/…
jberryman

Câu trả lời:


58

Học thuyết:

Hãy bắt đầu từ điều này: CPU của ngày hôm nay là superscalar, có nghĩa là chúng có thể thực thi nhiều hơn một lệnh mỗi chu kỳ (IPC). Các kiến ​​trúc Intel mới nhất có thể lên đến 4 IPC (4 bộ giải mã lệnh x86). Đừng đem chuyện tổng hợp vĩ mô / vi mô ra thảo luận để làm phức tạp thêm mọi thứ :).

Thông thường, khối lượng công việc không đạt đến IPC = 4 do các nội dung tài nguyên khác nhau. Điều này có nghĩa là CPU đang lãng phí chu kỳ (số lượng lệnh được đưa ra bởi phần mềm và CPU phải thực hiện chúng trong càng ít chu kỳ càng tốt).

Chúng ta có thể chia tổng số chu kỳ được sử dụng bởi CPU thành 3 loại:

  1. Các chu kỳ mà hướng dẫn được gỡ bỏ (công việc hữu ích)
  2. Các chu kỳ được chi tiêu ở Back-End (lãng phí)
  3. Chu kỳ chi tiêu trong Front-End (lãng phí).

Để có IPC là 4, số chu kỳ ngừng hoạt động phải gần bằng tổng số chu kỳ. Hãy nhớ rằng trong giai đoạn này, tất cả các hoạt động vi mô (uOps) rút lui khỏi đường dẫn và cam kết kết quả của chúng vào sổ đăng ký / bộ nhớ đệm. Ở giai đoạn này, bạn thậm chí có thể có nhiều hơn 4 uOps ngừng hoạt động, bởi vì con số này được cho bởi số lượng cổng thực thi. Nếu bạn chỉ có 25% chu kỳ ngừng hoạt động 4 uOps thì bạn sẽ có IPC tổng thể là 1.

Các chu trình bị đình trệ ở back-end là một sự lãng phí vì CPU phải đợi tài nguyên (thường là bộ nhớ) hoặc để hoàn thành các lệnh có độ trễ dài (ví dụ: transcedentals - sqrt, qua lại, phân chia, v.v.).

Các chu kỳ bị đình trệ trong giao diện người dùng là một sự lãng phí vì điều đó có nghĩa là Giao diện người dùng không cung cấp cho Giao diện người dùng các hoạt động vi mô. Điều này có thể có nghĩa là bạn đã bỏ sót trong bộ đệm ẩn Hướng dẫn hoặc các lệnh phức tạp chưa được giải mã trong bộ đệm vi-op. Mã được biên dịch đúng lúc thường thể hiện hành vi này.

Một lý do đình trệ khác là bỏ lỡ dự đoán chi nhánh. Đó được gọi là đầu cơ xấu. Trong trường hợp đó, uOps được phát hành nhưng chúng bị loại bỏ vì BP dự đoán sai.

Việc triển khai trong bộ hồ sơ:

Làm thế nào để bạn giải thích các chu kỳ BE và FE bị đình trệ?

Những người lập hồ sơ khác nhau có các cách tiếp cận khác nhau về các chỉ số này. Trong vTune, danh mục từ 1 đến 3 cộng lại để cung cấp 100% chu kỳ. Điều đó kết hợp hợp lý bởi vì hoặc bạn có CPU của mình bị đình trệ (không có uOps nào ngừng hoạt động) hoặc nó thực hiện công việc hữu ích (uOps) đang ngừng hoạt động. Xem thêm tại đây: https://software.intel.com/sites/products/documentation/doclib/stdxe/2013SP1/amplifierxe/snb/index.htm

Trong perf điều này thường không xảy ra. Đó là một vấn đề vì khi bạn thấy 125% chu kỳ bị đình trệ ở giao diện người dùng , bạn không biết thực sự giải thích điều này như thế nào. Bạn có thể liên kết số liệu> 1 với thực tế là có 4 bộ giải mã nhưng nếu bạn tiếp tục lý luận, thì IPC sẽ không khớp.

Thậm chí tốt hơn, bạn không biết vấn đề lớn như thế nào. 125% của cái gì? Khi đó, #cycles có nghĩa là gì?

Cá nhân tôi hơi nghi ngờ về chu kỳ BE và FE bị đình trệ của perf và hy vọng điều này sẽ được khắc phục.

Có lẽ chúng tôi sẽ nhận được câu trả lời cuối cùng bằng cách gỡ lỗi mã từ đây: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/tools/perf/builtin-stat.c


Những sự kiện nào được sử dụng trong VTune như FE và BE? Manuel đã đăng các sự kiện từ perf trên Sandy Bridge. Đôi khi bộ giải mã không thể giải mã 4 lệnh ( realworldtech.com/sandy-bridge/4 - có 3 bộ giải mã đơn giản không thể giải mã các lệnh phức tạp).
osgx

Đúng là cũng có một bộ giải mã phức tạp nhưng nó cũng có thể giải mã các hướng dẫn đơn giản. Tôi đã cập nhật bài đăng của mình bằng liên kết đến quầy vTune. Nó sử dụng các bộ đếm giống như perf nhưng tôi nghĩ vTune kết hợp khác nhau.
VAndrei

4
Vtune sử dụng software.intel.com/en-us/articles/… "IDQ_UOPS_NOT_DELIVERED.CORE / SLOTS" làm "Giới hạn giao diện người dùng" và "1 - (Giới hạn giao diện người dùng + Nghỉ hưu + Đầu cơ xấu)" làm "Giới hạn phụ trợ" trong đó " Nghỉ việc = UOPS_RETIRED.RETIRE_SLOTS / SLOTS "," Bad Speculation = (UOPS_ISSUED.ANY - UOPS_RETIRED.RETIRE_SLOTS + 4 * INT_MISC.RECOVERY_CYCLES) / SLOTS "và" SLOTS = 4 * CPU_CLK độ rộng bằng "SLOTS = 4 * CPU_CLK ".
osgx

1
Và đối với Sandy Bridge, hướng dẫn sử dụng Tối ưu hóa của Intel, intel.com/content/dam/www/public/us/en/documents/manuals/… cũng đưa ra điều tương tự trong "B.3.2 Phương pháp đặc tính hiệu suất từ ​​trên xuống theo thứ bậc" ""% FE_Bound = 100 * (IDQ_UOPS_NOT_DELIVERED.CORE / N);% Bad_Speculation = 100 * ((UOPS_ISSUED.ANY - UOPS_RETIRED.RETIRE_SLOTS + 4 * INT_MISC.RECOVERY_CYCLES) / N);% Nghỉ hưu = 100 * (UOPS_RETIRED) * (1 - (FE_Bound + Nghỉ hưu + Bad_Speculation)); N = 4 * CPU_CLK_UNHALTED.THREAD "
osgx

@osgx Cảm ơn. Bây giờ chúng ta biết ý nghĩa của các chỉ số trong vTune và chúng cộng lại tới 100%. Câu hỏi tiếp theo là tại sao perf lại tính toán chúng khác nhau? Nó là một lỗi hay có một ý nghĩa đằng sau nó?
VAndrei

42

Để chuyển đổi các sự kiện chung được xuất bởi perf thành các sự kiện thô trong tài liệu CPU của bạn, bạn có thể chạy:

more /sys/bus/event_source/devices/cpu/events/stalled-cycles-frontend 

Nó sẽ cho bạn thấy một cái gì đó như

event=0x0e,umask=0x01,inv,cmask=0x01

Theo tài liệu của Intel, ổ đĩa SDM 3B (tôi có core i5-2520):

UOPS_ISSUED.ANY:

  • Tăng mỗi chu kỳ, số lần lặp lại do RAT cấp cho RS.
  • Đặt Cmask = 1, Inv = 1, Any = 1 để đếm các chu kỳ bị đình trệ của lõi này.

Đối với sự kiện bị đình trệ-chu kỳ-phụ trợ dịch sang event = 0xb1, umask = 0x01 trên hệ thống của tôi, tài liệu tương tự cho biết:

UOPS_DISPATCHED.THREAD:

  • Đếm tổng số vòng lặp được gửi đi trên mỗi chuỗi mỗi chu kỳ
  • Đặt Cmask = 1, INV = 1 để đếm chu kỳ gian hàng.

Thông thường, các chu kỳ bị đình trệ là các chu kỳ trong đó bộ xử lý đang đợi một thứ gì đó (ví dụ như bộ nhớ được cấp dữ liệu sau khi thực hiện một thao tác tải) và không có bất kỳ công việc nào khác để làm. Hơn nữa, phần giao diện người dùng của CPU là phần cứng chịu trách nhiệm tìm nạp và giải mã các lệnh (chuyển đổi chúng thành UOP) trong đó phần phụ trợ chịu trách nhiệm thực thi các UOP một cách hiệu quả.


Cảm ơn vì đã trả lời. vậy sự khác nhau giữa bị đình trệ và không hoạt động là gì?
Dafan

2
Bị đình trệ và nhàn rỗi giống nhau. CPU không hoạt động vì nó bị đình trệ khi đường dẫn lệnh không di chuyển.
Milind Dumbare

@Milind, không nên có sự khác biệt, bị đình trệ phải là "chúng tôi không tiến bộ vì giai đoạn tiếp theo không cho phép nó", và nhàn rỗi phải là "không có gì để xử lý"?
Surt

13

Một chu kỳ CPU bị "đình trệ" khi đường ống không tiến lên trong quá trình đó.

Đường ống bộ xử lý bao gồm nhiều giai đoạn: front-end là một nhóm các giai đoạn này chịu trách nhiệm cho các giai đoạn tìm nạp và giải mã, trong khi back-end thực hiện các lệnh. Có một bộ đệm giữa front-end và back-end, vì vậy khi cái trước bị dừng, cái sau vẫn có thể có một số công việc phải làm.

Lấy từ http://paolobernardi.wordpress.com/2012/08/07/playing-around-with-perf/


2
Làm thế nào chúng ta có thể có nhiều quầy hàng hơn chu kỳ?
osgx

11

Theo tác giả của những sự kiện này, chúng được định nghĩa lỏng lẻo và được ước tính gần đúng bằng các bộ đếm hiệu suất CPU có sẵn. Như tôi biết, perf không hỗ trợ các công thức để tính toán một số sự kiện tổng hợp dựa trên một số sự kiện phần cứng, vì vậy nó không thể sử dụng phương pháp giới hạn gian hàng front-end / back-end từ hướng dẫn Tối ưu hóa của Intel (Triển khai trong VTune) http: // www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf "B.3.2 Phương pháp mô tả đặc tính hiệu suất từ ​​trên xuống theo thứ bậc"

%FE_Bound = 100 * (IDQ_UOPS_NOT_DELIVERED.CORE / N ); 
%Bad_Speculation = 100 * ( (UOPS_ISSUED.ANY – UOPS_RETIRED.RETIRE_SLOTS + 4 * INT_MISC.RECOVERY_CYCLES ) / N) ; 
%Retiring = 100 * ( UOPS_RETIRED.RETIRE_SLOTS/ N) ; 
%BE_Bound = 100 * (1 – (FE_Bound + Retiring + Bad_Speculation) ) ; 
N = 4*CPU_CLK_UNHALTED.THREAD" (for SandyBridge)

Công thức phù hợp có thể được sử dụng với một số tập lệnh bên ngoài, giống như nó đã được thực hiện trong công cụ pmu của Andi Kleen ( toplev.py): https://github.com/andikleen/pmu-tools (nguồn), http://halobates.de/blog/ p / 262 (mô tả):

% toplev.py -d -l2 numademo  100M stream
...
perf stat --log-fd 4 -x, -e
{r3079,r19c,r10401c3,r100030d,rc5,r10e,cycles,r400019c,r2c2,instructions}
{r15e,r60006a3,r30001b1,r40004a3,r8a2,r10001b1,cycles}
numademo 100M stream
...
BE      Backend Bound:                      72.03%
    This category reflects slots where no uops are being delivered due to a lack
    of required resources for accepting more uops in the    Backend of the pipeline.
 .....
FE      Frontend Bound:                     54.07%
This category reflects slots where the Frontend of the processor undersupplies
its Backend.

Cam kết đã giới thiệu các sự kiện bị đình trệ-chu kỳ-giao diện trước và bị đình trệ-chu kỳ-phụ trợ thay vì phổ quát ban đầu stalled-cycles:

http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=8f62242246351b5a4bc0c1f00c0c7003edea128a

author  Ingo Molnar <mingo@el...>   2011-04-29 11:19:47 (GMT)
committer   Ingo Molnar <mingo@el...>   2011-04-29 12:23:58 (GMT)
commit  8f62242246351b5a4bc0c1f00c0c7003edea128a (patch)
tree    9021c99956e0f9dc64655aaa4309c0f0fdb055c9
parent  ede70290046043b2638204cab55e26ea1d0c6cd9 (diff)

sự kiện hoàn hảo: Thêm định nghĩa sự kiện chu trình bị ngưng trệ chung phía trước và mặt sau Thêm hai sự kiện phần cứng chung: chu trình bị đình trệ giao diện người dùng và mặt sau.

Các sự kiện này đo lường các điều kiện khi CPU đang thực thi mã nhưng khả năng của nó không được sử dụng đầy đủ. Hiểu các tình huống như vậy và phân tích chúng là một nhiệm vụ phụ quan trọng của quy trình công việc tối ưu hóa mã.

Cả hai sự kiện đều giới hạn hiệu suất: hầu hết các gian hàng giao diện người dùng có xu hướng do lỗi nhánh hoặc bộ nhớ cache tìm nạp lệnh gây ra, các gian hàng phụ trợ có thể do thiếu tài nguyên khác nhau hoặc lập lịch hướng dẫn không hiệu quả.

Các quầy hàng front-end là những thứ quan trọng hơn: mã không thể chạy nhanh nếu luồng hướng dẫn không được theo kịp.

Một back-end được sử dụng quá mức có thể gây ra các gian hàng ở front-end và do đó cũng phải được để mắt đến.

Thành phần chính xác rất phụ thuộc vào logic chương trình và hỗn hợp lệnh.

Chúng tôi sử dụng các thuật ngữ 'gian hàng', 'giao diện người dùng' và 'đầu cuối' một cách lỏng lẻo và cố gắng sử dụng các sự kiện tốt nhất có sẵn từ các CPU cụ thể gần đúng với các khái niệm này.

Cc: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: Frederic Weisbecker Liên kết: http://lkml.kernel.org/n/tip-7y40wib8n000io7hjpn1dsrm@git.kernel.org Đã ký tên bởi: Ingo Molnar

    /* Install the stalled-cycles event: UOPS_EXECUTED.CORE_ACTIVE_CYCLES,c=1,i=1 */
-       intel_perfmon_event_map[PERF_COUNT_HW_STALLED_CYCLES] = 0x1803fb1;
+       intel_perfmon_event_map[PERF_COUNT_HW_STALLED_CYCLES_BACKEND] = 0x1803fb1;

-   PERF_COUNT_HW_STALLED_CYCLES        = 7,
+   PERF_COUNT_HW_STALLED_CYCLES_FRONTEND   = 7,
+   PERF_COUNT_HW_STALLED_CYCLES_BACKEND    = 8,

Vậy cuối cùng có phải lỗi ở perf không? Vì FE + BE +? không thêm vào một giá trị lý thuyết đã biết, thật khó để đánh giá vấn đề mã của bạn lớn đến mức nào. Khi bạn thấy 75% FE bị khựng lại cần so sánh với thứ gì đó. Nói 75% trong số 100% mã bị đình trệ trong FE hoặc BE có một ý nghĩa và giá trị hoàn toàn khác. Từ những gì tôi thấy, ngay cả toplev.py cũng có vấn đề tương tự. Nếu đây không phải là vấn đề, thì chúng tôi giải thích các chỉ số như thế nào? Điều gì làm cho các chỉ số cao hay thấp?
VAndrei

VAndrei, bạn có ví dụ ngắn gọn và có thể tái tạo cho SandyBridge (thế hệ + -1) không; cả perf statvới FE> 100% và toplev.py? Tôi chỉ bắt đầu từ các vòng lặp đơn giản ngắn và có các chu kỳ 3G cho các lệnh 3G (1G là các nhánh có tỷ lệ bỏ lỡ 0,00%) với các gian hàng 2G FE ( perf stat) và gian hàng 1G BE (IPC = 1,00). Tôi nghĩ vấn đề là xác định chính xác "gian hàng" cho lõi OOO phức tạp và một vấn đề khác là giải thích chính xác toplev.pykết quả.
osgx

Mã tôi đã đăng ở đây: stackoverflow.com/questions/28961405/… nên được giới hạn giao diện người dùng. Có rất nhiều chi nhánh bị bỏ lỡ trong đó sẽ tạo ra các gian hàng FE. Về BE ràng buộc, bạn cần một khối lượng công việc chờ từ dữ liệu RAM. Phân bổ 1/2 kích thước bộ nhớ vật lý của bạn trong bộ đệm và sử dụng LCG (như trong mã của tôi) để thực hiện thao tác đọc / sửa đổi / ghi tại một vị trí ngẫu nhiên trong bộ đệm. Điều đó tạo ra một số lượng nhỏ các lệnh bên cạnh giao dịch RMW và lõi sẽ bị đình trệ trong chờ BE từ dữ liệu RAM.
VAndrei

Tạo khối lượng công việc ràng buộc FE là một thách thức khá lớn. Vui lòng thử xem microbenchmark phân nhánh hoạt động nhưng nếu không, bạn cần thứ gì đó phức tạp hơn. Lỗi FE sẽ được tạo ra bởi các lỗi bộ nhớ đệm lệnh số cao. Để làm được điều đó, bạn cần một mã lớn với các bước nhảy xa để dẫn đến nhiều lần bỏ lỡ I $. Tại thời điểm này, tôi không có ý tưởng về cách tạo khối lượng công việc giới hạn FE trong một dấu vi mô.
VAndrei

Tôi nghĩ rằng bạn sẽ quan tâm đến liên kết này: stackoverflow.com/questions/1756825/… Bạn có thể sử dụng một số kỹ thuật đã thảo luận đó để xả I $ và do đó tạo ra các gian hàng FE.
VAndrei
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.