🚀 go-pugleaf

Day pisze:
> Witam,
> 
> Mym pytaniem jest: W jaki sposób policzyć liczbę cykli wykonywanych na
> daną operację na naszym procesorze oraz jak obliczyć wielkość[rozmiar w
> bajtach] danej operacji?
> 
> Oczywiście wiem, że mogę ze specyfikacji Intela, jak dobrze pamiętam,
> odczytać. Ale biorąc pod uwagę różnicę w AMD i Intel oraz ilość
> informacji jakie miałbym dołączyć, tzn przepisać nie zadawala mnie zbytnio.

 Rozmiar można policzyć bez uruchomienia - albo bezpośrednio z manuali
albo skompilować swój fragment kodu do pliku binarnego i odczytać jego
długość. W czasie działania programu można to zrobić tak:

poczatek:
	[tutaj instrukcje]
	mov	eax, $ - poczatek ; "$ - offset poczatek" w TASM/MASM


 Czas wykonywania zależy od wielu, wielu czynników i najlepiej jest go
mierzyć w czasie uruchamiania, np.

 xor eax, eax
 cpuid
 rdtsc
 mov [czas+4], edx
 mov [czas], eax

 mov ecx, 1000000
petla:
 [tutaj instrukcje niezmieniające ECX]
 loop petla

 xor eax, eax
 cpuid
 rdtsc

 sub eax, [czas]
 sbb edx, [czas+4]

 EDX:EAX/1000000 = wynik. Możesz też zmierzyć sam CPUID i pustej pętli
i odjąć od wyniku. Kod ten wymaga bodajże 586.

-- 
Pozdrawiam - Bogdan                                 (Linux i FreeDOS)
Kurs asemblera x86  (DOS i Linux):  http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
Rozmawiaj bezpiecznie: www.JabberPL.org Surfuj anonimowo: tor.eff.org

Day napisał(a):
> Witam,
> 
> Mym pytaniem jest: W jaki sposób policzyć liczbę cykli wykonywanych na
> daną operację na naszym procesorze oraz jak obliczyć wielkość[rozmiar w
> bajtach] danej operacji?

Liczbę cykli możesz zmierzyc, hint: rdtsc
Ale to i tak nie da miarodajnych wyników dla pojedynczej instrukcji,
ponieważ wspołczesne procesory potrafia przetwarzac kilka instrukcji
w jednym czasie, a w systemach wielozadaniowych istnieje też
prawdopodobienstwo, że system zmieni kontekst.

Rozmiar mozesz obliczyc na etapie kompilacji porownujac adresy

label1:
    mov eax, ebx
label2:
    mov eax, label2 - label1

> Oczywiście wiem, że mogę ze specyfikacji Intela, jak dobrze pamiętam,
> odczytać. Ale biorąc pod uwagę różnicę w AMD i Intel oraz ilość
> informacji jakie miałbym dołączyć, tzn przepisać nie zadawala mnie zbytnio.

A po co w ogole?
Zdecydowana większosc instrukcji (szczególnie te proste) zajmuje
formalnie jeden cykl procesora, natomiast przy dobrej optymalizacji
kodu bedą się one wykonywały po dwie jednocześnie, a wiec 0,5 cykla.
Tylko niektore instrukcje nie nie mogą być wykonywane wraz z innymi,
i nie mieszcza sie w tej normie bądź wykonują sie znacznie dłużej.

-- 
Pozdrawiam
Lopez

W So, 16 VI 2007 o 09:41 GMT, Bogdan (bogdro) napisał(a):
[...]
>  xor eax, eax
>  cpuid
>  rdtsc
>
>  sub eax, [czas]
>  sbb edx, [czas+4]
>
>  EDX:EAX/1000000 = wynik. Możesz też zmierzyć sam CPUID i pustej pętli
> i odjąć od wyniku. Kod ten wymaga bodajże 586.

A po co puste wywołanie cpuid?
Można użyć cpuid do sprawdzenia obecności tsc, ale samo cpuid też wymaga
i586+.


-- 
Jakub Bogusz  |  http://qboosh.pl/

Day wrote:
> Mym pytaniem jest: W jaki sposób policzyć liczbę cykli wykonywanych na 
> daną operację na naszym procesorze oraz jak obliczyć wielkość[rozmiar w 
> bajtach] danej operacji?

Liczbę cykli to trochę ciężko, bo współczesne mikroprocesory
mają po kilka jednostek wykonawczych i mogą równocześnie
wykonywać kilka rozkazów.  Poza tym kolejność wykonywania może
być zmieniona.

Ale: najlepiej poczytać o tym, jakie dany mikroprocesor ma MSR-y
i co można mierzyć (rozkazy rdmsr/wrmsr; w Linuksie jest do tego
sterownik - msr).

w.

>  Czas wykonywania zależy od wielu, wielu czynników i najlepiej jest go
> mierzyć w czasie uruchamiania, np.
> 
>  xor eax, eax
>  cpuid
>  rdtsc
>  mov [czas+4], edx
>  mov [czas], eax
> 
>  mov ecx, 1000000
> petla:
>  [tutaj instrukcje niezmieniające ECX]
>  loop petla
> 
>  xor eax, eax
>  cpuid
>  rdtsc
> 
>  sub eax, [czas]
>  sbb edx, [czas+4]
> 
>  EDX:EAX/1000000 = wynik. Możesz też zmierzyć sam CPUID i pustej pętli
> i odjąć od wyniku. Kod ten wymaga bodajże 586.
> 

Mógłbyś jeszcze dać coś o rdtsc... szuakłem w internecie... może 
pobieżnie bo właśnie wychodzę ale nie widziałem nic o tej instrukcji...

Day

Day pisze:
>>  Czas wykonywania zależy od wielu, wielu czynników i najlepiej jest go
>> mierzyć w czasie uruchamiania, np.
>>
>>  xor eax, eax
>>  cpuid
>>  rdtsc
>>  mov [czas+4], edx
>>  mov [czas], eax

> Mógłbyś jeszcze dać coś o rdtsc... szuakłem w internecie... może
> pobieżnie bo właśnie wychodzę ale nie widziałem nic o tej instrukcji...

 ReaD Time Stamp Counter, czy jakoś tak. Jak procesor jest
uruchamiany, zaczyna liczyć wykonane takty, od zera. Ta instrukcja
odczytuje dotychczasową liczbę wykonanych taktów i umieszcza ją w
EDX:EAX (tzn. EDX - starsza część), stąd kod powyżej. Po przejściu
przez badany kod ponownie wykonywana jest RDTSC i od bieżącego wyniu
odejmowany jest poprzedni, uzyskując tym samym liczbę taktów potrzebną
na wykonanie całego kodu pomiędzy wywołaniami RDTSC.

-- 
Pozdrawiam - Bogdan                                 (Linux i FreeDOS)
Kurs asemblera x86  (DOS i Linux):  http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
Rozmawiaj bezpiecznie: www.JabberPL.org Surfuj anonimowo: tor.eff.org

Jakub Bogusz pisze:
> W So, 16 VI 2007 o 09:41 GMT, Bogdan (bogdro) napisał(a):
> [...]
>>  xor eax, eax
>>  cpuid
>>  rdtsc
>>
>>  sub eax, [czas]
>>  sbb edx, [czas+4]
>>
>>  EDX:EAX/1000000 = wynik. Możesz też zmierzyć sam CPUID i pustej pętli
>> i odjąć od wyniku. Kod ten wymaga bodajże 586.
> 
> A po co puste wywołanie cpuid?
> Można użyć cpuid do sprawdzenia obecności tsc, ale samo cpuid też wymaga
> i586+.

 Fakt, choć cpuid już była na niektórych modelach 486, ale rdtsc chyba
nie, nie pamiętam. Już tłumaczę, po co ona mi tutaj. Zjawisko nosi
nazwę "serializing" i polega na tym, że instrukcja CPUID (bodajże jako
jedyna dostępna w procesach niesystemowych) powoduje, że wszystkie
poprzedzające ją instrukcje zostają w pełni i do końca wykonane (bo
jak wiemy, część instrukcji może być wykonywana równolegle). Dzięki
temu RDTSC jest wykonane "na czysto", tj. poprzednie instrukcje nie
wpływają na pomiar czasu.

-- 
Pozdrawiam - Bogdan                                 (Linux i FreeDOS)
Kurs asemblera x86  (DOS i Linux):  http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
Rozmawiaj bezpiecznie: www.JabberPL.org Surfuj anonimowo: tor.eff.org

Lopez pisze:
> Day napisał(a):
>> Witam,
>>
>> Mym pytaniem jest: W jaki sposób policzyć liczbę cykli wykonywanych na
>> daną operację na naszym procesorze oraz jak obliczyć wielkość[rozmiar w
>> bajtach] danej operacji?
> 
> Liczbę cykli możesz zmierzyc, hint: rdtsc
> Ale to i tak nie da miarodajnych wyników dla pojedynczej instrukcji,
> ponieważ wspołczesne procesory potrafia przetwarzac kilka instrukcji
> w jednym czasie,

 Tak, patrz: wytłumaczenie instrukcji CPUID w moim poście numer 2.

> a w systemach wielozadaniowych istnieje też
> prawdopodobienstwo, że system zmieni kontekst.

 Prawda. Nieracjonalnie wysokie wyniki należy wtedy odrzucić. I tak
należy wykonać kilka testów, każdy o innej liczbie iteracji. Należy
patrzeć, czy czasy rosną proporcjonalnie do liczby iteracji. Jeśli nie
(tzn. urosło dużo za dużo), to pewnie nastąpiło przełączenie zadań i
wynik należy odrzucić. Z nieodrzuconych wyciągnąć średnią.

[...]

> Zdecydowana większosc instrukcji (szczególnie te proste) zajmuje
> formalnie jeden cykl procesora, natomiast przy dobrej optymalizacji
> kodu bedą się one wykonywały po dwie jednocześnie, a wiec 0,5 cykla.
> Tylko niektore instrukcje nie nie mogą być wykonywane wraz z innymi,
> i nie mieszcza sie w tej normie bądź wykonują sie znacznie dłużej.

 Współcześnie sprawa jest jeszcze trudniejsza. Każda instrukcja ma
czas trwania i przepustowość. Oznaczają one czas wykonania instrukcji
w pełni oraz czas, po którym może być zaczęta podobna instrukcja. NOPy
bodajże idą w tempie 3 sztuk na cykl, MOV i inne proste instrukcje
rzeczywiście w 0,5 taktu, ale to wszystko zależy od złożoności
instrukcji, np. czasem potrzebny jest dodatkowy czas na obliczenie
adresu efektywnego zawartego w instrukcji lub poczekanie na wykonanie
zależności. Niektóre instrukcje FPU trwają setki cykli i tu
optymalizacja niewiele pomoże.

-- 
Pozdrawiam - Bogdan                                 (Linux i FreeDOS)
Kurs asemblera x86  (DOS i Linux):  http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
Rozmawiaj bezpiecznie: www.JabberPL.org Surfuj anonimowo: tor.eff.org

> Niektóre instrukcje FPU trwają setki cykli i tu
> optymalizacja niewiele pomoże.

Tylko instrukcje FPU chyba od samego początku wykonywały się równolegle do 
wszystkich innych (tzn. nie-FPU) i niezależnie od nich.

-- 
Azarien

Wiktor S. pisze:
>> Niektóre instrukcje FPU trwają setki cykli i tu
>> optymalizacja niewiele pomoże.
> 
> Tylko instrukcje FPU chyba od samego początku wykonywały się równolegle
> do wszystkich innych (tzn. nie-FPU) i niezależnie od nich.

 Instrukcje FPU to chyba rzeczywiście osobna grupa (tzn. osobne układy
dekodujące i wykonujące), ale głowy nie dam. Trzeba byłoby sprawdzić,
czy takie instrukcje jak MUL i DIV nie idą przez jednostkę FPU
przypadkiem (tak mi się coś mgliście kojarzy). A instrukcje FPU mogą
być zależne od instrukcji nie-FPU, jak np.

	push dword 0
	fld dword [esp]
	add ebx, 4
	fld dword [ebx]
	fcompp
	fstcw ax

 "Zależność" FPU od MMX to w ogóle osobna historia...
 Ale to, że instrukcje FPU są niezależne od instrukcji nie-FPU nie
znaczy, że nie są zależne od siebie, a często są. Nie wszystkie dadzą
się wykonać równolegle, bo niektóre muszą czekać na wyniki. Uwaga
jednak słuszna i często miesza się kod FPU i nie-FPU/MMX, by podnieść
wydajność.

-- 
Pozdrawiam - Bogdan                                 (Linux i FreeDOS)
Kurs asemblera x86  (DOS i Linux):  http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
Rozmawiaj bezpiecznie: www.JabberPL.org Surfuj anonimowo: tor.eff.org

W Pn, 18 VI 2007 o 14:27 GMT, Bogdan (bogdro) napisał(a):
> Wiktor S. pisze:
>>> Niektóre instrukcje FPU trwają setki cykli i tu
>>> optymalizacja niewiele pomoże.
>> 
>> Tylko instrukcje FPU chyba od samego początku wykonywały się równolegle
>> do wszystkich innych (tzn. nie-FPU) i niezależnie od nich.
>
>  Instrukcje FPU to chyba rzeczywiście osobna grupa (tzn. osobne układy
> dekodujące i wykonujące), ale głowy nie dam. Trzeba byłoby sprawdzić,
> czy takie instrukcje jak MUL i DIV nie idą przez jednostkę FPU
> przypadkiem (tak mi się coś mgliście kojarzy).

Tradycyjnie - nie. Nie te rejestry. Przesłania między jednostkami
ograniczały się do obliczonego efektywnego adresu w jedną stronę i słowa
stanu FPU w drugą stronę (i to tylko do AX, od 287 bodajże). Chyba nic
więcej. Poza tym MUL i DIV działały też bez FPU (w czasach <486DX).
Teraz podział jednostek jest bardziej umowny - skoro i tak wszystko
w jednym kawałku siedzi, to już sprawa producenta, który um^2 krzemu za
co odpowiada.


-- 
Jakub Bogusz  |  http://qboosh.pl/

Jakub Bogusz pisze:
> W Pn, 18 VI 2007 o 14:27 GMT, Bogdan (bogdro) napisał(a):
>> Wiktor S. pisze:
>>>> Niektóre instrukcje FPU trwają setki cykli i tu
>>>> optymalizacja niewiele pomoże.
>>> Tylko instrukcje FPU chyba od samego początku wykonywały się równolegle
>>> do wszystkich innych (tzn. nie-FPU) i niezależnie od nich.
>>  Instrukcje FPU to chyba rzeczywiście osobna grupa (tzn. osobne układy
>> dekodujące i wykonujące), ale głowy nie dam. Trzeba byłoby sprawdzić,
>> czy takie instrukcje jak MUL i DIV nie idą przez jednostkę FPU
>> przypadkiem (tak mi się coś mgliście kojarzy).
> 
> Tradycyjnie - nie. Nie te rejestry. Przesłania między jednostkami
> ograniczały się do obliczonego efektywnego adresu w jedną stronę i słowa
> stanu FPU w drugą stronę (i to tylko do AX, od 287 bodajże). Chyba nic
> więcej. Poza tym MUL i DIV działały też bez FPU (w czasach <486DX).

 Działały bez FPU, to prawda. Ale teraz IMUL imm32/r32 przechodzi
przez jednostkę FP_MUL - tako rzecze 'IA-32 Intel Architecture
Optimization Reference Manual', strona C-15. Reszta (MUL, IDIV i DIV)
- nie wiadomo, bo wstydzili się pokazać szczegóły :) Podręcznik
optymalizacji AMD jest bardziej szczegółowy, ale z kolei nie podaje,
gdzie dana instrukcja się wykonuje (a swoją drogą potwierdza, że NOPy
idą po 3 na cykl, czas trwania - prawie 0, nie zajmują zasobów).

> Teraz podział jednostek jest bardziej umowny - skoro i tak wszystko
> w jednym kawałku siedzi, to już sprawa producenta, który um^2 krzemu za
> co odpowiada.

 To prawda.

-- 
Pozdrawiam - Bogdan                                 (Linux i FreeDOS)
Kurs asemblera x86  (DOS i Linux):  http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
Rozmawiaj bezpiecznie: www.JabberPL.org Surfuj anonimowo: tor.eff.org

>  xor eax, eax
>  cpuid
>  rdtsc
>  mov [czas+4], edx
>  mov [czas], eax
> 
>  mov ecx, 1000000
> petla:
>  [tutaj instrukcje niezmieniające ECX]
>  loop petla
> 
>  xor eax, eax
>  cpuid
>  rdtsc
> 
>  sub eax, [czas]
>  sbb edx, [czas+4]

Napisałem coś takiego lecz gdy próbuję odjąć od wyniku jakąś liczbę to 
nie za bardzo wychodzi to i nie mam pojęcia czemu?

	LOCAL czas:dword

cpuid
rdtsc
mov [czas], edx
mov [czas+4], eax

mov ecx,10
petla:

loop petla

cpuid
rdtsc

sub eax,[czas+4]
sbb edx,[czas]

sub eax,11

mov ecx,10
div ecx


invoke wsprintf,offset ou, offset format,eax
	ret

NA koniec pod ou mam 11 a chyba powinno być 0 skoro gdy nie dam
sub eax,11 wynikiem jest 11.

Długo nie pisałem tego posta bo sam próbowałem zrozumieć czemu tak jest, 
lecz nie doszedłem do tego.

Day pisze:
>>  xor eax, eax
>>  cpuid
>>  rdtsc
>>  mov [czas+4], edx
>>  mov [czas], eax
>>
>>  mov ecx, 1000000
>> petla:
>>  [tutaj instrukcje niezmieniające ECX]
>>  loop petla
>>
>>  xor eax, eax
>>  cpuid
>>  rdtsc
>>
>>  sub eax, [czas]
>>  sbb edx, [czas+4]
> 
> Napisałem coś takiego lecz gdy próbuję odjąć od wyniku jakąś liczbę to
> nie za bardzo wychodzi to i nie mam pojęcia czemu?
> 
>     LOCAL czas:dword
> 

	xor	eax, eax

Jest to dość ważne, bo gwarantuje stały czas wykonania cpuid. Zauważ,
że drugie cpuid uruchamiasz z argumentm (EAX) pochodzącym jeszcze z
RDTSC. Wiedziałem, co robię, pisząc te XORy u siebie.

> cpuid
> rdtsc
> mov [czas], edx
> mov [czas+4], eax

 Tradycyjnie pisze się na odwrót, bo EDX to starsza część (a więc
powinien wylądować w [czas+4]). Ale na początek może być.

> mov ecx,10

 Spróbuj większe liczby.

> petla:
> 
> loop petla
> 

	xor	eax, eax

> cpuid
> rdtsc
> 
> sub eax,[czas+4]
> sbb edx,[czas]
> 
> sub eax,11

 Skąd to 11? Liczba cykli na rdtsc i cpuid? Pomiń na razie to
dzielenie. Jak wszystko będzie działać, to przywróci się.

> mov ecx,10
> div ecx
> 
> 
> invoke wsprintf,offset ou, offset format,eax

 Co to za "format"? Może lepiej "%d:%d" i "edx, eax"?

>     ret
> 
> NA koniec pod ou mam 11 a chyba powinno być 0 skoro gdy nie dam
> sub eax,11 wynikiem jest 11.

 Teraz masz 11 w wyniku? Jak po odjęciu 11 masz 11, to EAX zawierał 22.

-- 
Pozdrawiam - Bogdan                                 (Linux i FreeDOS)
Kurs asemblera x86  (DOS i Linux):  http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
Rozmawiaj bezpiecznie: www.JabberPL.org Surfuj anonimowo: tor.eff.org

>  Tradycyjnie pisze się na odwrót, bo EDX to starsza część (a więc
> powinien wylądować w [czas+4]). Ale na początek może być.

Wiem, że można na odwrót ale akurat się mi tak napisało :p

> 
>> mov ecx,10
> 
>  Spróbuj większe liczby.

Dałem 10 by w olym nie czekać bo nie chciał wyjść z pętli.

>> sub eax,11
> 
>  Skąd to 11? Liczba cykli na rdtsc i cpuid? Pomiń na razie to
> dzielenie. Jak wszystko będzie działać, to przywróci się.

Taki wynik dostałem bez odjęcia 11. Tak łatwiej mi sprawdzać gdy dzieli.

> 
>> mov ecx,10
>> div ecx
>>
>>
>> invoke wsprintf,offset ou, offset format,eax
>  Co to za "format"? Może lepiej "%d:%d" i "edx, eax"?
może ale początkowo dałem tak. format właśnie te dane zawiera, tzn dla 
jednej zmiennej.

>  Teraz masz 11 w wyniku? Jak po odjęciu 11 masz 11, to EAX zawierał 22.
> 

Nie zawierał bo jak odejmę te 22 to jest 9? Dlatego nie mam pojęcia o co 
biega.