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:
- Cykle, w których instrukcje przechodzą na emeryturę (przydatna praca)
- Cykle spędzone na zapleczu (zmarnowane)
- Cykle spędzone w Front-End (zmarnowane).
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