ATNEL tech-forum

Re: Prosty benchmark wykonywanego kodu

2014-01-10T21:00:17+01:00

Tak to prawda co napisał @MirkoT, musimy sami zdecydować co dla nas jest najważniejsze przy każdym projekcie z osobna.

Teraz tylko znaleźć kompromis pomiędzy wydajnością a zajętością programu - odwieczny dylemat programisty

Dziękuję za link, z chęcią przeczytam co ma sam Atmel do przekazania nam w tej kwestii

Statystyki: Napisane przez Sheep — 10 sty 2014, o 21:00

Re: Prosty benchmark wykonywanego kodu

2014-01-10T20:52:47+01:00

A kiedyś ktoś tu wrzucił taki link odnośnie optymalizacji
http://www.atmel.com/Images/doc8453.pdf
I tam można poczytać, że zazwyczaj to co jest krótsze wykonuje się dłużej
to co zajmuje więcej pamięci jest szybsze
Coś za coś.

Statystyki: Napisane przez MirkoT — 10 sty 2014, o 20:52

Re: Prosty benchmark wykonywanego kodu

2014-01-09T20:17:09+01:00

A więc napisałem szybki benchmark, wrzucam dla pokoleń

[syntax=c]#include
#include
#includujcie swoją bibliotekę do hd44780 by wyświetlać wynik
#include //potrzebna dla itoa

int przebieg=0;
char bufor[16]="";

ISR(TIMER0_OVF_vect)
{
przebieg++;
}

void timer_start(void)
{
TCCR0=(1<TIMSK=(1<TCNT0=0;
}

void timer_stop(void)
{
TIMSK=0;
TCCR0=0;
}

}
int main(void)
{

lcd_init();
pos(0,0);
lcd("czas: ");

timer_start();
sei();
/*
tutaj wrzucacie swój kod, który poddajecie benchmarkowi ;)
*/

timer_stop();

itoa(przebieg,bufor,10); //konwersja liczby na ascii
lcd(bufor); //wyswietla ilosc przebiegow, jesli timer sie przepelnił
lcd(" ");
itoa(TCNT0,bufor,10); //konwersja liczby na ascii
lcd(bufor); // a tu wartosc rejestru TCNT0

while(1)
{

}

}[/syntax]

Wartość preskalera musicie dobierać ręcznie do swoich potrzeb i do tego, jak Wasz kod wykonuje się szybko, im mniejszy preskaler tym większa dokładność pomiaru, wynik nie jest w żadnych jednostkach typu us czy ms, dla ciekawskich można policzyć uwzględniając prędkość zegara. Ja w swoim 'teście' musiałem preskaler ustawić na 0 ale przy 4 Mhz praktycznie każda jedna instrukcja zwiększała mi wartość TCNT0 o 4

Mój test polegał na sprawdzeniu czasu wykonywania się 8 razy tej samej instrukcji sprawdzającej z przesuwaniem. Sprawdziłem while, for, oraz (uwaga!) 8 ifów wpisanych ręcznie.
while - 159
for - 149
8x if - 93

Jasną sprawą jest fakt, że ostatnia opcja nie jest optymalna jeśli chodzi o zapis oraz pojemność zajętego flasha, lecz jest to mój pierwszy projekt, w którym szybkość wykonywania kodu jest dla mnie ważniejsza, niż utrata 80 bajtów, jak to zwykle jest odwrotnie szukając oszczędności na każdym bajcie.

Aha i nie lekceważcie porad bardziej doświadczonych by stosować zmienne 8 bitowe tam, gdzie jest to wystarczające, bowiem zarezerwowanie pamięci dla zmiennej 16 bitowej zajmuje więcej czasu procesorka

Zachęcam Was do pomiarów różnych fragmentów swoich kodów i ich optymalizacje, jeśli macie efekt pływania np. podczas wyświetlania jakichś skomplikowanych siatek z ledami

Statystyki: Napisane przez Sheep — 9 sty 2014, o 20:17

Re: Prosty benchmark wykonywanego kodu

2014-01-09T11:19:43+01:00

no to wtedy mam po prostu ilość overflowow timera + reszta z niedoliczonego do 255 rejestru TCNT0, czy tak to rozumować?

wstawienie diody jako zabezpieczenie przy overflow oznaczałoby, że muszę po prostu manipulować preskalerem, ale macie rację - tracę wtedy na dokładności pomiaru przy szybko wykonywanych fragmentach kodu

squeez napisał(a):

zależy od przedziałów czasowych i posiadanego sprzętu)

przede wszystkim od posiadanego sprzętu, ani oscyllo ani analizatora, ale trzeba sobie radzić

Statystyki: Napisane przez Sheep — 9 sty 2014, o 11:19

Re: Prosty benchmark wykonywanego kodu

2014-01-09T09:45:04+01:00

Sheep napisał(a):

nie bardzo rozumiem?

No pomyśl - jeśli np jak sam stwierdziłeś timer 8-bitowy zliczy do 255 to się przepełni i będzie = 0 ... ty wtedy zapalasz diodę żeby wydłużyć czas jego tykania ale tracisz np na rozdzielczości czasowej ... a tymczasem zamiast zapalić diodę LED inkrementujesz zmienną np

starszy_bajt++;

i na koniec pomiaru możesz złożyć sobie pomiar z tego 8-bitowego timera tak jakbyś działał z timerem 16 bitowym

starszy_bajt PLUS TCNT0

... i masz 16 bitową wartość ile było tyknięć

Statystyki: Napisane przez mirekk36 — 9 sty 2014, o 09:45

Re: Prosty benchmark wykonywanego kodu

2015-11-06T14:11:23+01:00

Statystyki: Napisane przez xor — 9 sty 2014, o 09:42

Re: Prosty benchmark wykonywanego kodu

2014-01-09T09:26:12+01:00

błyskawiczna odpowiedź, dziękuje bardzo!
nie wiedziałem, że tak się robi, po prostu taki sposób pomiaru wpadł mi do głowy i chciałem spytać czy jest dobry
faktycznie można zwiększyć częstotliwość timera, ustawić zmienną inkrementowaną i jej wartość oglądać - też opcja

mirekk36 napisał(a):

która da ci kolejny starszy bajt pomiaru takiego czasu

nie bardzo rozumiem?

Statystyki: Napisane przez Sheep — 9 sty 2014, o 09:26

Re: Prosty benchmark wykonywanego kodu

2014-01-09T09:22:44+01:00

no ale tak się robi a diody LED wcale nie trzeba zapalać tylko można w przerwaniu inkrementować jakąś zmienną, która da ci kolejny starszy bajt pomiaru takiego czasu

Statystyki: Napisane przez mirekk36 — 9 sty 2014, o 09:22

Prosty benchmark wykonywanego kodu

2014-01-09T09:20:38+01:00

Witam wszystkich,

Czy ktoś bawił się pomiarem czasu jaki potrzebuje procesor na wykonanie danego fragmentu kodu? Nie chodzi tutaj o dokładny czas a raczej zmierzenie szybkości wykonania się kodu przed i po optymalizacji i porównanie.
W programach na PC łatwo wykorzystuje się pomiar czasu przed i po wykonaniu kodu a wynikiem jest po prostu różnica czasowa. Jedyne na co wpadłem to:

1) uruchomienie timera 8 lub 16 bitowego
2) wykonywanie danego fragmentu kodu
3) zatrzymanie timera
4) wyświetlenie wartości TCNT0 lub OCRA na wyświetlaczu np. za pomocą itoa()
5) zabezpieczenie przed wyzerowaniem się timera - zapalenie diody w przerwaniu od przepełnienia co oznacza, że musimy 'zwolnić' z timerkiem

Czy ktoś ma jakiś pomysł? Czy moja koncepcja przedstawiona wyżej jest w miare skuteczna?
Jest jeszcze możliwość z funkcją while wraz z zapaleniem diody, ale program przed i po optymalizacji wykonuje się tak szybko, że zauważenie zapalenia się diody jest prawie niewykonalne za jasności i tym samym zauważenie różnicy nie jest możliwe. Kod pomimo, że wykonuje się szybko używam w programie bardzo często dlatego zależy mi na optymalizacji.

Jakiekolwiek sugestie będą mile widziane

Pozdrawiam

Mikołaj

Statystyki: Napisane przez Sheep — 9 sty 2014, o 09:20