Odkryłem, że zwykły clock (), wszyscy tutaj polecają, z jakiegoś powodu bardzo różni się od uruchomienia do uruchomienia, nawet w przypadku kodu statycznego bez żadnych skutków ubocznych, takich jak rysowanie na ekranie lub czytanie plików. Może tak być, ponieważ procesor zmienia tryby zużycia energii, system operacyjny daje różne priorytety itp.
Tak więc jedynym sposobem, aby niezawodnie uzyskać ten sam wynik za każdym razem przy użyciu clock (), jest uruchomienie mierzonego kodu w pętli wiele razy (przez kilka minut), przy zachowaniu środków ostrożności, aby uniemożliwić kompilatorowi jego optymalizację: nowoczesne kompilatory mogą wstępnie obliczyć kod bez efektów ubocznych działających w pętli i wyjmij ją z pętli, np. używając losowego wejścia dla każdej iteracji.
Po zebraniu wystarczającej liczby próbek do tablicy, sortuje się tę tablicę i przyjmuje środkowy element, zwany medianą. Mediana jest lepsza niż średnia, ponieważ odrzuca ekstremalne odchylenia, jak na przykład antywirus zajmujący cały procesor lub system operacyjny przeprowadzający jakąś aktualizację.
Oto proste narzędzie do pomiaru wydajności wykonania kodu C / C ++, uśredniające wartości zbliżone do mediany: https://github.com/saniv/gauge
Nadal szukam bardziej niezawodnego i szybszego sposobu pomiaru kodu. Prawdopodobnie można by spróbować uruchomić kod w kontrolowanych warunkach na czystym metalu bez żadnego systemu operacyjnego, ale to da nierealistyczny wynik, ponieważ w rzeczywistości system operacyjny się angażuje.
x86 ma te liczniki wydajności sprzętu, w tym rzeczywistą liczbę wykonanych instrukcji, ale dostęp do nich jest trudny bez pomocy systemu operacyjnego, trudny do interpretacji i ma swoje własne problemy ( http://archive.gamedev.net/archive/reference/articles /article213.html ). Mimo to mogą być pomocne w badaniu charakteru szyjki butelki (dostęp do danych lub faktyczne obliczenia tych danych).