Pomiar skuteczności

Narzędzia do analizy porównawczej

Narzędzia analizy porównawczej LiteRT mierzą i obliczają obecnie statystyki dla następujące ważne dane o skuteczności:

• Czas inicjowania
• Czas wnioskowania dla stanu rozgrzewki
• Czas wnioskowania w stanie stabilnym
• Wykorzystanie pamięci podczas inicjowania
• Ogólne wykorzystanie pamięci

Narzędzia te są dostępne jako aplikacje porównawcze na Androida i iOS oraz natywne pliki binarne wiersza poleceń; wszystkie mają taką samą podstawową wydajność logikę pomiarów. Dostępne opcje i formaty wyjściowe to z powodu różnic w środowisku wykonawczym.

Aplikacja Android Test porównawczy

Narzędzia do analizy porównawczej można używać na Androidzie na 2 sposoby. Jeden to natywny plik binarny testu porównawczego, a drugi to Android. do analizy porównawczej, co pozwoli lepiej ocenić, jak model poradzi sobie w aplikacji. Oba modele wyniki testu porównawczego będą się nieznacznie różnić wnioskowania z modelem w rzeczywistej aplikacji.

Ta aplikacja testowa na Androida nie ma interfejsu użytkownika. Zainstaluj i uruchom ją, używając programu adb i pobierz wyniki za pomocą polecenia adb logcat.

Pobierz lub skompiluj aplikację

Pobierz gotowe aplikacje do testów porównawczych na Androida, korzystając z tych linków:

• android_aarch64
• android_arm

Jeśli chodzi o aplikacje do testów porównawczych na Androida, które obsługują operacje TF, z pomocą przedstawiciela ds. Flex, skorzystaj z poniższych linków:

• android_aarch64
• android_arm

Aplikację możesz też utworzyć na podstawie źródła, wykonując te czynności: instrukcje.

Przygotuj test porównawczy

Przed uruchomieniem aplikacji porównawczej zainstaluj ją i przekaż plik z modelem urządzenia w następujący sposób:

adb install -r -d -g android_aarch64_benchmark_model.apk
adb push your_model.tflite /data/local/tmp

Przeprowadź test porównawczy

adb shell am start -S \
  -n org.tensorflow.lite.benchmark/.BenchmarkModelActivity \
  --es args '"--graph=/data/local/tmp/your_model.tflite \
              --num_threads=4"'

Parametr graph jest wymagany.

• graph: string
  Ścieżka do pliku modelu TFLite.

Możesz podać więcej parametrów opcjonalnych na potrzeby testu porównawczego.

• num_threads: int (domyślnie=1)
  Liczba wątków, które mają być używane do uruchamiania interpretera TFLite.
• use_gpu: bool (wartość domyślna=fałsz)
  Użyj przekazywania do GPU.
• use_xnnpack: bool (wartość domyślna=false)
  Używaj Przedstawiciel XNNPACK.

W zależności od używanego urządzenia niektóre z tych opcji mogą być niedostępne. dostępne lub nie mają żadnego efektu. Więcej informacji: parametry , aby uzyskać więcej parametrów wydajności, które można uruchomić w aplikacji do testów porównawczych.

Wyświetl wyniki za pomocą polecenia logcat:

adb logcat | grep "Inference timings"

Wyniki testu porównawczego są podawane w następujący sposób:

... tflite  : Inference timings in us: Init: 5685, First inference: 18535, Warmup (avg): 14462.3, Inference (avg): 14575.2

Plik binarny testu porównawczego

Narzędzie do analizy porównawczej jest też udostępniane jako natywny plik binarny benchmark_model. Dostępne opcje to narzędzie z wiersza poleceń powłoki na urządzeniach z systemem Linux, Mac, urządzeniach wbudowanych Urządzenia z Androidem.

Pobierz lub skompiluj plik binarny

Aby pobrać na noc gotowe, natywne pliki binarne wiersza poleceń, wykonaj linki poniżej:

• linux_x86-64
• linux_aarch64
• linux_arm
• android_aarch64
• android_arm

Co noc gotowe do obsługi plików binarnych, które obsługują operacje TF. z pomocą przedstawiciela ds. Flex, skorzystaj z poniższych linków:

• linux_x86-64
• linux_aarch64
• linux_arm
• android_aarch64
• android_arm

Możesz też utworzyć natywny plik binarny testu porównawczego źródło na komputerze.

bazel build -c opt //tensorflow/lite/tools/benchmark:benchmark_model

Aby tworzyć kompilacje za pomocą łańcucha narzędzi Android NDK, musisz skonfigurować środowisko kompilacji najpierw obserwując ten guide, lub użyj funkcji zgodnie z opisem w tym artykule .

bazel build -c opt --config=android_arm64 \
  //tensorflow/lite/tools/benchmark:benchmark_model

Przeprowadź test porównawczy

Aby przeprowadzić testy porównawcze na komputerze, uruchom plik binarny z powłoki.

path/to/downloaded_or_built/benchmark_model \
  --graph=your_model.tflite \
  --num_threads=4

Możesz użyć tego samego zestawu parametry jak wspomnieliśmy powyżej, za pomocą natywnego pliku binarnego wiersza poleceń.

Profilowanie operacji modelu

Plik binarny modelu porównawczego umożliwia też profilowanie działań modelu i pobieranie czas wykonywania każdego z operatorów. Aby to zrobić, prześlij flagę --enable_op_profiling=true na benchmark_model podczas wywoływania. Szczegóły są wyjaśniono tutaj.

Natywny plik binarny testu porównawczego dla wielu opcji wydajności podczas jednego uruchomienia

Dostępny jest też wygodny i prosty plik binarny w C++ testy porównawcze różnych opcji skuteczności za jednym razem. Plik binarny został stworzony na podstawie wspomnianych wcześniej testów porównawczych który umożliwia porównywanie tylko jednej opcji skuteczności. Współdzielą oni ten sam proces kompilacji/instalacji/uruchomienia, ale nazwa miejsca docelowego BUILD tego pliku binarnego to benchmark_model_performance_options i wymaga podania dodatkowych parametrów. Ważny parametr tego pliku binarnego to:

perf_options_list: string (domyślnie='wszystkie')
Rozdzielona przecinkami lista opcji porównawczych dotyczących skuteczności TFLite.

Na noc możesz pobrać gotowe pliki binarne dla tego narzędzia, które znajdziesz poniżej:

• linux_x86-64
• linux_aarch64
• linux_arm
• android_aarch64
• android_arm

Aplikacja do analizy porównawczej iOS

Aby przeprowadzić testy porównawcze na urządzeniu z iOS, musisz stworzyć aplikację na podstawie source. Umieść plik modelu LiteRT w benchmark_data w drzewie źródłowym i zmodyfikuj plik benchmark_params.json. Te wartości gdy pliki są spakowane do aplikacji, aplikacja odczytuje dane z katalogu. Odwiedź Aplikacja do analizy porównawczej iOS .

Testy porównawcze wydajności dobrze znanych modeli

Ta sekcja zawiera testy porównawcze wydajności LiteRT, jeśli działa dobrze na niektórych urządzeniach z Androidem i iOS.

testy porównawcze wydajności Androida,

Te wartości testu porównawczego skuteczności zostały wygenerowane przez natywny plik binarny analizy porównawczej.

W przypadku testów porównawczych Androida koligacja procesora jest ustawiona na użycie dużych rdzeni urządzenia aby zmniejszyć wariancję (zobacz szczegóły).

Zakładamy, że modele zostały pobrane i rozpakowane do Katalog /data/local/tmp/tflite_models. Testowy plik binarny jest oparty na tymi instrukcjami który znajduje się w katalogu /data/local/tmp.

Aby przeprowadzić test porównawczy:

adb shell /data/local/tmp/benchmark_model \
  --num_threads=4 \
  --graph=/data/local/tmp/tflite_models/${GRAPH} \
  --warmup_runs=1 \
  --num_runs=50

Aby działać z przekazywaniem dostępu do GPU, ustaw --use_gpu=true.

Poniższe wartości dotyczące wydajności są mierzone na Androidzie 10.

Testy porównawcze aplikacji na iOS

Te wartości testu porównawczego skuteczności zostały wygenerowane przez Aplikacja testów porównawczych na iOS

Aby przeprowadzić testy porównawcze iOS, aplikacja porównawcza została zmodyfikowana, aby zawierała odpowiedni parametr model i benchmark_params.json zostały zmienione, aby ustawić num_threads na wartość 2. Aby użyć funkcji delegat GPU, opcje "use_gpu" : "1" i "gpu_wait_type" : "aggressive" dodano też do benchmark_params.json.

Wewnętrzne dane śledzenia LiteRT

Śledzenie wewnętrznych danych LiteRT na Androidzie

Zdarzenia wewnętrzne z interpretera LiteRT aplikacji na Androida mogą być przechwycone przez Narzędzia do śledzenia aktywności na Androidzie. To te same zdarzenia co w Androidzie Trace API, więc przechwycone zdarzenia z kodu Java i Kotlin są widoczne razem z LiteRT zdarzeń wewnętrznych.

Oto kilka przykładów zdarzeń:

• Wywołanie operatora
• Modyfikowanie wykresu według delegata
• Przydział Tensor

Wśród różnych opcji rejestrowania śladów w tym przewodniku omawiamy Androida Program profilujący procesora Studio i aplikacja System Tracking. Więcej informacji: Narzędzie wiersza poleceń Perfetto lub Narzędzie wiersza poleceń Systrace , aby poznać inne opcje.

Dodawanie zdarzeń śledzenia w kodzie Java

To jest fragment kodu z Klasyfikacja obrazów przykładową aplikację. Tłumacz LiteRT działa recognizeImage/runInference. Ten krok jest opcjonalny, ale jest przydatny do pomagają zidentyfikować miejsce wywołania wnioskowania.

  Trace.beginSection("recognizeImage");
  ...
  // Runs the inference call.
  Trace.beginSection("runInference");
  tflite.run(inputImageBuffer.getBuffer(), outputProbabilityBuffer.getBuffer().rewind());
  Trace.endSection();
  ...
  Trace.endSection();

Włącz śledzenie przez LiteRT

Aby włączyć śledzenie LiteRT, ustaw właściwość systemu Android debug.tflite.trace na 1 przed uruchomieniem aplikacji na Androida.

adb shell setprop debug.tflite.trace 1

Jeśli ta właściwość została ustawiona przy inicjowaniu tłumaczenia rozmowy LiteRT, będą śledzone kluczowe zdarzenia (np. wywołanie operatora) z interpretatora.

Po zarejestrowaniu wszystkich logów czasu wyłącz śledzenie, ustawiając wartość właściwości do 0.

adb shell setprop debug.tflite.trace 0

Program profilujący procesora Android Studio

Rejestruj ślady za pomocą Program profilujący procesora Android Studio wykonując te czynności:

1. Wybierz Uruchom > Utwórz profil „aplikacja” w górnych menu.

2. Kliknij dowolne miejsce na osi czasu procesora, gdy pojawi się okno programu profilującego.

3. Wybierz „Śledź wywołania systemowe” w trybach profilowania procesora.

   

4. Naciśnij przycisk „Nagraj”. Przycisk

5. Naciśnij „Zatrzymaj”. Przycisk

6. Zbadaj wynik logu czasu.

   

Ten przykład pokazuje hierarchię zdarzeń w wątku oraz statystyki. dla każdego operatora, a także przepływ danych w całej aplikacji .

Aplikacja do śledzenia systemu

Przechwytuj logi czasu bez Android Studio, wykonując czynności opisane w artykule: Aplikacja do śledzenia systemu.

W tym przykładzie te same zdarzenia TFLite zostały zarejestrowane i zapisane w Perfetto lub formatu Systrace w zależności od wersji urządzenia z Androidem. Przechwycony pliki śledzenia można otwierać w interfejsie Perfetto.

Śledzenie wewnętrznych danych LiteRT w iOS

Zdarzenia wewnętrzne z interpretera LiteRT aplikacji na iOS mogą być przechwycone przez Instrumenty dostępne w Xcode. Oto iOS signpost zdarzenia, więc zarejestrowane zdarzenia z kodu Swift/Objective-C są widoczne razem ze zdarzeniami wewnętrznymi LiteRT.

Oto kilka przykładów zdarzeń:

• Wywołanie operatora
• Modyfikowanie wykresu według delegata
• Przydział Tensor

Włącz śledzenie przez LiteRT

Ustaw zmienną środowiskową debug.tflite.trace, wykonując te czynności:

1. Wybierz Produkt > Schemat > Edytuj schemat... w górnych menu Xcode.

2. Kliknij „Profil”. w panelu po lewej stronie.

3. Odznacz „Użyj argumentów i zmiennych środowiskowych działania Uruchom” .

4. Dodaj debug.tflite.trace w sekcji „Zmienne środowiskowe” .

   

Jeśli chcesz wykluczyć zdarzenia LiteRT podczas profilowania aplikacji na iOS, wyłączyć śledzenie, usuwając zmienną środowiskową.

Instrumenty XCode

Aby przechwycić ślady, wykonaj te czynności:

1. Wybierz Produkt > Profil w górnych menu Xcode.

2. Po uruchomieniu narzędzia Instruments kliknij Logging (Logowanie) wśród szablonów profilowania.

3. Naciśnij „Start”. Przycisk

4. Naciśnij „Zatrzymaj”. Przycisk

5. Kliknij „os_signpost”. aby rozwinąć elementy podsystemu OS Logging.

6. Kliknij „org.tensorflow.lite”. Podsystem OS Logging.

7. Zbadaj wynik logu czasu.

   

W tym przykładzie widać hierarchię zdarzeń i statystyki w każdym z nich przez operatora.

Korzystanie z danych śledzenia

Dane śledzenia pozwalają zidentyfikować wąskie gardła wydajności.

Oto kilka przykładów statystyk, które można uzyskać za pomocą narzędzia do profilowania potencjalnych rozwiązań poprawiających wydajność:

• Jeśli liczba dostępnych rdzeni procesora jest mniejsza niż liczba wnioskowania wątków, obciążenie związane z planowaniem procesora może obniżyć wydajność. Możesz przełożyć inne zadania w aplikacji obciążające procesor, aby uniknąć nakładają się na wnioskowanie z modelu lub modyfikują liczbę interpretatorów; .
• Jeśli operatory nie są w pełni delegowane, niektóre części wykresu modelu są wykonywane na CPU, a nie na oczekiwanym akceleratorze sprzętowym. Ty nieobsługiwane operatory mogą być zastępowane podobnymi obsługiwanymi operatorami.