Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

[C/C++]Mierzenie wydajności fragmentu programu

skynet_2 21 Paź 2010 09:26 1996 9
  • #1 21 Paź 2010 09:26
    skynet_2
    Poziom 26  

    Zastanawiam się jak można dokładnie zmierzyć wydajność programu np. jakieś funkcji.

    Mierzenie czasu daje duży rozrzut, czy można w jakiś sposób zmierzyć w ilu cyklach zegarowych wykonuje się owa funkcja?

    0 9
  • Pomocny post
    #2 21 Paź 2010 12:54
    sedr
    Poziom 17  

    skynet_2 napisał:
    Zastanawiam się jak można dokładnie zmierzyć wydajność programu np. jakieś funkcji.

    Mierzenie czasu daje duży rozrzut, czy można w jakiś sposób zmierzyć w ilu cyklach zegarowych wykonuje się owa funkcja?


    Poczytaj o profilerach kodu.

    0
  • Pomocny post
    #3 21 Paź 2010 14:07
    Dżyszla
    Poziom 42  

    Dokładnie tak, jak kolega napisał, to co chcesz zrobić, to fachowo nazywa się profilowaniem. Pojedynczy pomiar oparty o czas faktycznie może być niedokładny, jeśli funkcja wykonuje się krótko. Oczywiście jest możliwość pomiaru taktów procesora. Jednak częściej i lepiej oprzeć się o czas, ale nie jednej, tylko 1000 wywołań funkcji (czas w okolicach kilkudziesięciu sekund jest miarodajny).
    Jednakże nie zapominaj, że w systemie wielozadaniowym pomiary zawsze będą miały duży rozrzut. Na ten wpływają także takie elementy, jak zbuforowanie danych czytanych z dysku lub odpowiednio duża wolna przestrzeń adresowa (przy pojedynczym wywołaniu może okazać się potrzebna reorganizacja pamięci, np przeniesienie innych danych na dysk). No a o współdzieleniu wszystkich zasobów komputera pomiędzy inne zadania nawet nie wspominam ;)

    0
  • Pomocny post
    #4 21 Paź 2010 14:40
    Ciapol
    Poziom 24  

    Obaj koledzy macie rację ale... Należy zwrócić szczególną uwagę na warunki w jakich funkcja jest uruchamiana. Bo jeśli test wykonujemy aby porównać dwa alternatywne rozwiązania programistyczne to uruchamianie tej samej funkcji setki razy daje bardzo dobre efekty porównawcze. W sytuacji jednak gdy funkcję testujemy, bo ma ona spełniać jakieś kryteria założeniowe i test ma być sprawdzeniem czy funkcja podoła wymaganiom to powyższa metoda jest co najmniej niemiarodajna z uwagi na mechanizmy wykorzystywane w systemach wielozadaniowych (co poruszył mój poprzednik). Rozwiązaniem tego problemu może być np wywoływaniem funkcji zgodnie z jej realnym przewidywanym harmonogramem uruchamiania i wykonywanie testów na sprzęcie co najmniej zbliżonym do sprzętu docelowego.

    0
  • #5 21 Paź 2010 16:24
    skynet_2
    Poziom 26  

    @sedr Profilowanie znalazłem[głównie po en], testuje taki programik Zoom (www.rotateright.com) i bardzo szybko znalazłem najwolniejsze części programu, szkoda że jest taki drogi :(

    @Dżyszla Mierzenie czasów jest trochę bez sensu, ponieważ jak np. pojedyncze wykonanie trwa >10 sec to żeby mieć dokładny pomiar trzeba by sporo czasu, a przy <0,010 sec traci się dokładność.

    @Ciapol tutaj akurat nie ma takiej potrzeby, po prostu szukam najmniej wydajnych miejsc w algorytmie zrealizowanym w C++.

    A teraz po co mi to potrzebne, ano piszę program do kompresji danych losowych[FAIL?], na razie program tylko analizuje dany plik a że analiza zajmuje dużo czasu gdyż sprawdzam wszystkie możliwe kombinacje i algorytmy bazowe.

    Potrzebowałem porównać czy alternatywne rozwiązanie danego problemu jest szybsze[a nie chce przepisywać całego programu].

    Okazuje się że algorytm wolniejszy na papierze może być szybsze po skompilowaniu :)

    0
  • #6 21 Paź 2010 18:26
    Dżyszla
    Poziom 42  

    Oczywiście, komputer jest od liczenia, a nie od myslenia ;) Stąd taka ironia. Co do analizy - możliwe, że szybciej będzie po prostu skompresować dane różnymi metodami i porównać wyniki ;) Oczywiście radzę użyć metody kompresji strumieniowej. Choć może być generalnie duży problem, gdyż takie dane nie poddają się żadnej kompresji... Ale jak wymyślisz coś, co będzie w stanie spakować RARa czy ZIPa to daj znać! ;) (to są własnie chyba najlepsze dane testowe dla Twojego algorytmu).

    0
  • Pomocny post
    #7 21 Paź 2010 18:33
    sedr
    Poziom 17  

    Jeśli chodzi o dobre profilery to polecam:

    AMD Code Analyzer (Linux/Win), Intel V-Tune (Linux/Win) oraz Valgrind (Linux).

    Co do szybkości algorytmów to niech kolega pamięta o optymalizacjach w opcjach kompilatora.

    @Dżyszla: to są chyba najgorsze dane dla algorytmu Skyneta. :P

    0
  • #8 21 Paź 2010 18:45
    skynet_2
    Poziom 26  

    @edr dziękuje zaraz biorę się za testowanie.

    Dżyszla napisał:
    Co do analizy - możliwe, że szybciej będzie po prostu skompresować dane różnymi metodami i porównać wyniki ;)
    Ale tutaj powstaje problem że te algorytmy są bardzo złożone, a efektywność jak i prędkość niska.
    Dżyszla napisał:
    Oczywiście radzę użyć metody kompresji strumieniowej. Choć może być generalnie duży problem, gdyż takie dane nie poddają się żadnej kompresji... Ale jak wymyślisz coś, co będzie w stanie spakować RARa czy ZIPa to daj znać! ;) (to są własnie chyba najlepsze dane testowe dla Twojego algorytmu).
    Archiwum rar czy zip to jest hmm średnie źródło danych, jak na ironie powtarzalne dane są trudniejsze do skompresowania niż losowe symetryczne[czyli w 256 bajtach masz 256 różnych bajtów].

    Mój pomysł opiera się na kompresowaniu wielokrotnym, tyle że podczas kompresowania danych przygotowujesz je pod następny taki sam proces kompresji, dlatego potrzebuje taką masę analiz które sprawdzają dane przed i po kompresji niejako określając ich przydatność w następnym przebiegu.

    W jeszcze większym uproszczeniu przerabiasz dane losowe na ciąg który dokładnie wiesz jak skompresować ;)
    Właściwie górna granica takiej kompresji nie istnieje[oczywiście pomijając dane kontrolne, znaczniki itp].

    0
  • #9 21 Paź 2010 19:32
    Dżyszla
    Poziom 42  

    skynet_2 napisał:
    powtarzalne dane są trudniejsze do skompresowania niż losowe
    To chyba masz na myśli jakąś konkretną grupę algorytmów, bo akurat taka sytuacja świetnie nadaje się dla strumieniowego Huffmana (jeśli podobne dane obok siebie) lub dla kompresji słownikowej (jeśli powtarzalne są ciągi w całym obszarze danych).

    0
  • #10 21 Paź 2010 20:51
    skynet_2
    Poziom 26  

    Dżyszla napisał:
    To chyba masz na myśli jakąś konkretną grupę algorytmów, bo akurat taka sytuacja świetnie nadaje się dla strumieniowego Huffmana (jeśli podobne dane obok siebie) lub dla kompresji słownikowej (jeśli powtarzalne są ciągi w całym obszarze danych).
    Dokładnie tak, nie korzystam z żadnego[chyba?] ze znanych algorytmów, wymyśliłem algorytm który wykorzystuje niedoskonałości ciągu losowego[czyt. wejściowego] + przygotowanie go do następnego przebiegu kompresji.

    _edit poprzedniego wyłączony.

    _edit: kcachegrind + valgrind wystarcza.

    0