Czy ktoś wie, jakie znaczenie mają stalled-Cycles-frontend i stalled-Cycles-backend w wyniku perf stat? Szukałem w internecie, ale nie znalazłem odpowiedzi. Dzięki
$ 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
Odpowiedzi:
Teoria:
Zacznijmy od tego: dzisiejsze procesory są superskalarne, co oznacza, że mogą wykonywać więcej niż jedną instrukcję na cykl (IPC). Najnowsze architektury Intela mogą obsługiwać do 4 IPC (4 dekodery instrukcji x86). Nie wprowadzajmy do dyskusji fuzji makro / mikro, aby bardziej komplikować sprawę :).
Zazwyczaj obciążenia nie osiągają IPC = 4 ze względu na różne spory zasobów. Oznacza to, że procesor marnuje cykle (liczba instrukcji jest podawana przez oprogramowanie i procesor musi je wykonać w jak najmniejszej liczbie cykli).
Całkowite cykle spędzane przez procesor możemy podzielić na 3 kategorie:
Aby uzyskać IPC równy 4, liczba wycofanych cykli musi być zbliżona do całkowitej liczby cykli. Należy pamiętać, że na tym etapie wszystkie mikrooperacje (uOps) wycofują się z potoku i przekazują wyniki do rejestrów / pamięci podręcznych. Na tym etapie możesz mieć nawet więcej niż 4 uOps wycofania, ponieważ liczba ta wynika z liczby portów wykonawczych. Jeśli tylko 25% cykli przechodzi na 4 uOps, wówczas ogólny IPC wyniesie 1.
Te cykle stalled w back-end to strata, ponieważ CPU musi czekać na zasobach (zwykle pamięci) lub zakończyć długie opóźnienia instrukcje (np transcedentals - sqrt, odwrotności, podziałów, itd.).
Te cykle stalled w front-end to strata, bo to oznacza, że Front-End nie żywią tylnym końcu z mikro-działalności. Może to oznaczać, że brakuje ci w pamięci podręcznej instrukcji lub złożonych instrukcji, które nie zostały jeszcze zdekodowane w pamięci podręcznej mikrooperacji. Kod skompilowany dokładnie na czas zwykle wyraża to zachowanie.
Innym powodem przeciągnięcia jest chybiona prognoza gałęzi. Nazywa się to złymi spekulacjami. W takim przypadku wydawane są uOps, ale są one odrzucane, ponieważ BP przewidziano nieprawidłowo.
Implementacja w profilerach:
Jak interpretujesz zatrzymane cykle BE i FE?
Różne osoby profilujące mają różne podejścia do tych metryk. W vTune kategorie od 1 do 3 sumują się, dając 100% cykli. Wydaje się to rozsądne, ponieważ albo masz zablokowany procesor (żadne uOps nie są wycofywane), albo wykonujesz użyteczną pracę (uOps) wycofując się. Zobacz więcej tutaj: https://software.intel.com/sites/products/documentation/doclib/stdxe/2013SP1/amplifierxe/snb/index.htm
W perfekcyjnym zwykle tak się nie dzieje. To jest problem, ponieważ kiedy widzisz 125% cykli zablokowanych w przedniej części , nie wiesz, jak naprawdę to zinterpretować. Możesz powiązać metrykę> 1 z faktem, że są 4 dekodery, ale jeśli będziesz kontynuować rozumowanie, IPC nie będzie pasować.
Co więcej, nie wiesz, jak duży jest problem. 125% czego? Co w takim razie oznaczają # cykle?
Osobiście wyglądam trochę podejrzanie w przypadku zatrzymanych cykli BE i FE w PERF i mam nadzieję, że zostanie to naprawione.
Prawdopodobnie ostateczną odpowiedź uzyskamy, debugując kod stąd: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/tools/perf/builtin-stat.c
źródło
Aby przekonwertować ogólne zdarzenia wyeksportowane przez perf do surowej dokumentacji procesora, możesz uruchomić:
Pokaże ci coś takiego
Zgodnie z dokumentacją Intela SDM tom 3B (mam rdzeń i5-2520):
UOPS_ISSUED.ANY:
Dla zdarzenia stalled-Cycles-backend tłumaczącego na event = 0xb1, umask = 0x01 w moim systemie ta sama dokumentacja mówi:
UOPS_DISPATCHED.THREAD:
Zazwyczaj cykle zatrzymane to cykle, w których procesor czeka na coś (na przykład pamięć do podania po wykonaniu operacji ładowania) i nie ma żadnych innych rzeczy do zrobienia. Co więcej, frontendowa część procesora jest elementem sprzętu odpowiedzialnym za pobieranie i dekodowanie instrukcji (konwertowanie ich na UOP), gdzie część zaplecza jest odpowiedzialna za efektywne wykonywanie UOP.
źródło
Cykl procesora zostaje „zatrzymany”, gdy potok nie jest w trakcie jego wykonywania.
Potok procesora składa się z wielu etapów: front-end to grupa tych etapów, która odpowiada za fazy pobierania i dekodowania, podczas gdy zaplecze wykonuje instrukcje. Istnieje bufor między front-endem a back-endem, więc gdy pierwszy jest zablokowany, drugi może nadal mieć trochę pracy.
Zaczerpnięte z http://paolobernardi.wordpress.com/2012/08/07/playing-around-with-perf/
źródło
Według autora tych zdarzeń definiują one luźno i są aproksymowane przez dostępne liczniki wydajności procesora. Jak wiem, perf nie obsługuje formuł do obliczania syntetycznego zdarzenia na podstawie kilku zdarzeń sprzętowych, więc nie może używać metody związanej z blokadą front-end / back-end z podręcznika Intel Optimization manual (Implemented in VTune) http: // www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf „B.3.2 Hierarchiczna top-down metodologia charakteryzacji wydajności”
Prawidłowe formuły mogą być używane z niektórymi zewnętrznymi skryptami, tak jak zostało to zrobione w pmu-tools Andi Kleen (
toplev.py
): https://github.com/andikleen/pmu-tools (źródło), http://halobates.de/blog/ p / 262 (opis):Commit, który wprowadził zdarzenia stalled-Cycles-frontend i stalled-Cycles-backend zamiast oryginalnego uniwersalnego
stalled-cycles
:http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?id=8f62242246351b5a4bc0c1f00c0c7003edea128a
źródło
perf stat
FE> 100%, jak i dla toplev.py? Właśnie zacząłem od krótkich prostych pętli i mam cykle 3G dla instrukcji 3G (1G to gałęzie z odsetkiem chybionych 0,00%) ze straganami 2G FE (perf stat
) i 1G BE straganami (IPC = 1,00). Myślę, że problemem jest poprawne zdefiniowanie „przeciągnięcia” dla złożonego rdzenia OOO, a innym jest poprawna interpretacjatoplev.py
wyników.