🚀 go-pugleaf

W dniu 20.07.2010 17:15, yesma pisze:
> http://www.agner.org/instruction_tables.pdf
> 9 List of instruction timings and μop breakdown for P4E
> 
> Tyle że niema tutaj podane dla ADD, SUB operands r,i
> 
> Instruction       ADD, SUB         INC, DEC
> Operands          r,r              r
> µops              1                2
> Microcode         0                0
> Latency           1                1
> Throughput        0.25             0.5
> Port              0/1              0/1
> Unit              alu0/1           alu0/1
> 
> Czy nielepiej jest stosować zawsze ADD SUB zamiast INC DEC ?

 Zależy, jak zwykle, od procesora docelowego. Na starszych INC/DEC
było szybsze, nie mówiąc już nawet o tych procesorach, które np. nie
miały pamięci podręcznej (INC/DEC są krótsze, a więc krócej się
ładowały z pamięci do procesora). Na nowszych procesorach, według
mnie, lepsze jest ADD/SUB.

-- 
Pozdrawiam/Regards - Bogdan                     (GNU/Linux & FreeDOS)
Kurs asemblera x86 (DOS, GNU/Linux):http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
www.JabberPL.org www.TorProject.org Soft (EN): miniurl.pl/bogdro-soft

Bogdan (bogdro) pisze:
> W dniu 20.07.2010 17:15, yesma pisze:
>> Czy nielepiej jest stosować zawsze ADD SUB zamiast INC DEC ?
> 
>  Zależy, jak zwykle, od procesora docelowego. Na starszych INC/DEC
> było szybsze, nie mówiąc już nawet o tych procesorach, które np. nie
> miały pamięci podręcznej (INC/DEC są krótsze, a więc krócej się
> ładowały z pamięci do procesora). Na nowszych procesorach, według
> mnie, lepsze jest ADD/SUB.
> 

Będę musiał zmienić swoje przyzwyczajenia bo zawsze używałem
INC i DEC a czasami nawet dwa razy pod rząd.
A jeśli chodzi o XOR r,r to nie lepiej MOV r,0 lub SUB r,r
bo jeśli tak to szkoda mi będzie się z tymi trzema instrukcjami rozstać.

-- 
Regards - Grzechu
Linux x86_64

yesma pisze:
> A jeśli chodzi o XOR r,r to nie lepiej MOV r,0 lub SUB r,r
> bo jeśli tak to szkoda mi będzie się z tymi trzema instrukcjami rozstać.
> 
XOR jest oidp szybszy od sub (które w skali mikro to negacja i 
dodawanie) i krótsze od MOV co oszczędza cache (a nie ma prawie nic 
gorszego od kodu pętli, który nie mieści się w L1).

-- 
Pozdrawiam
Michoo

Michoo pisze:
> yesma pisze:
>> A jeśli chodzi o XOR r,r to nie lepiej MOV r,0 lub SUB r,r
>> bo jeśli tak to szkoda mi będzie się z tymi trzema instrukcjami rozstać.
>>
> XOR jest oidp szybszy od sub (które w skali mikro to negacja i 
> dodawanie) i krótsze od MOV co oszczędza cache (a nie ma prawie nic 
> gorszego od kodu pętli, który nie mieści się w L1).
> 

Dzięki, chociaż jedna ulubiona instrukcja uratowana :)

-- 
Regards - Grzechu
Linux x86_64

Michoo <michoo_news@vp.pl> wrote:

> yesma pisze:
> > A jeśli chodzi o XOR r,r to nie lepiej MOV r,0 lub SUB r,r
> > bo jeśli tak to szkoda mi będzie się z tymi trzema instrukcjami rozstać.
> > 
> XOR jest oidp szybszy od sub (które w skali mikro to negacja i 
> dodawanie) i krótsze od MOV co oszczędza cache (a nie ma prawie nic 
> gorszego od kodu pętli, który nie mieści się w L1).

XOR r, r jest specjalnie traktowany przez CPU, to polecana metoda
zerowania rejestrów.

w.

W dniu 20.07.2010 22:18, yesma pisze:
> Michoo pisze:
>> yesma pisze:
>>> A jeśli chodzi o XOR r,r to nie lepiej MOV r,0 lub SUB r,r
>>> bo jeśli tak to szkoda mi będzie się z tymi trzema instrukcjami
>>> rozstać.
>>>
>> XOR jest oidp szybszy od sub (które w skali mikro to negacja i
>> dodawanie) i krótsze od MOV co oszczędza cache (a nie ma prawie nic
>> gorszego od kodu pętli, który nie mieści się w L1).
>>
> 
> Dzięki, chociaż jedna ulubiona instrukcja uratowana :)

 Chyba że chcesz zachować flagi niezmienione :) Wtedy zostaje MOV.

-- 
Pozdrawiam/Regards - Bogdan                     (GNU/Linux & FreeDOS)
Kurs asemblera x86 (DOS, GNU/Linux):http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
www.JabberPL.org www.TorProject.org Soft (EN): miniurl.pl/bogdro-soft

On 2010-07-20 17:15, yesma wrote:
> http://www.agner.org/instruction_tables.pdf
> 9 List of instruction timings and μop breakdown for P4E
>
> Tyle że niema tutaj podane dla ADD, SUB operands r,i
>
> Instruction ADD, SUB INC, DEC
> Operands r,r r
> µops 1 2
> Microcode 0 0
> Latency 1 1
> Throughput 0.25 0.5
> Port 0/1 0/1
> Unit alu0/1 alu0/1
>
> Czy nielepiej jest stosować zawsze ADD SUB zamiast INC DEC ?

Lepiej, ale dotyczy to tylko procesorów rodziny Pentium 4. Na innych 
INC/DEC będzie na ogół szybsze, z paru powodów. Wolniejsze będzie tylko 
wtedy, gdy po instrukcji zajdzie konieczność "składania" znaczników 
(INC/DEC nie aktualizują wszystkich).

Bogdan (bogdro) pisze:
> W dniu 20.07.2010 22:18, yesma pisze:
>> Michoo pisze:
>>> yesma pisze:
>>>> A jeśli chodzi o XOR r,r to nie lepiej MOV r,0 lub SUB r,r
>>>> bo jeśli tak to szkoda mi będzie się z tymi trzema instrukcjami
>>>> rozstać.
>>>>
>>> XOR jest oidp szybszy od sub (które w skali mikro to negacja i
>>> dodawanie) i krótsze od MOV co oszczędza cache (a nie ma prawie nic
>>> gorszego od kodu pętli, który nie mieści się w L1).
>>>
>> Dzięki, chociaż jedna ulubiona instrukcja uratowana :)
> 
>  Chyba że chcesz zachować flagi niezmienione :) Wtedy zostaje MOV.
> 

Flag nie brałem pod uwagę ale jak będą akurat potrzebne
to sobie przypomnę twoje słowa :)
Dzięki

-- 
Regards - Grzechu
Linux x86_64

Bernard pisze:
> On 2010-07-20 17:15, yesma wrote:
>> http://www.agner.org/instruction_tables.pdf
>> 9 List of instruction timings and μop breakdown for P4E
[...]
>> Czy nielepiej jest stosować zawsze ADD SUB zamiast INC DEC ?
> 
> Lepiej, ale dotyczy to tylko procesorów rodziny Pentium 4. 

Właśnie chodziło mi o Pentium4EM64T bo taki akurat mam.

> Na innych 
> INC/DEC będzie na ogół szybsze, z paru powodów. Wolniejsze będzie tylko 
> wtedy, gdy po instrukcji zajdzie konieczność "składania" znaczników 
> (INC/DEC nie aktualizują wszystkich).

Nie za bardzo rozumiem tego "składania", jestem początkujący.
Czy to znaczy że jeśli nam będzie potrzebna inna flaga której nie 
aktualizuje INC DEC to wtedy na wszystkich procesorach ADD SUB
okaże się lepsze ?

-- 
Regards - Grzechu
Linux x86_64

yesma pisze:
>> Na innych INC/DEC będzie na ogół szybsze, z paru powodów. Wolniejsze 
>> będzie tylko wtedy, gdy po instrukcji zajdzie konieczność "składania" 
>> znaczników (INC/DEC nie aktualizują wszystkich).
> 
> Nie za bardzo rozumiem tego "składania", jestem początkujący.
> Czy to znaczy że jeśli nam będzie potrzebna inna flaga której nie 
> aktualizuje INC DEC to wtedy na wszystkich procesorach ADD SUB
> okaże się lepsze ?
> 
Jeżeli robisz operacje na liczbach złożonych z 2 słów procesora to 
normalnie inkrementację zrobisz tak (eax,ebx - liczba):
add ebx,1
adc eax,0

a przy inc będzie to coś takiego:
inc ebx
jno skip ;jz chyba też zadziała dla unsigned
inc eax
skip: ...

z dec podobnie

-- 
Pozdrawiam
Michoo

Michoo pisze:
> yesma pisze:
>>> Na innych INC/DEC będzie na ogół szybsze, z paru powodów. Wolniejsze 
>>> będzie tylko wtedy, gdy po instrukcji zajdzie konieczność "składania" 
>>> znaczników (INC/DEC nie aktualizują wszystkich).
>>
>> Nie za bardzo rozumiem tego "składania", jestem początkujący.
>> Czy to znaczy że jeśli nam będzie potrzebna inna flaga której nie 
>> aktualizuje INC DEC to wtedy na wszystkich procesorach ADD SUB
>> okaże się lepsze ?
>>
> Jeżeli robisz operacje na liczbach złożonych z 2 słów procesora to 
> normalnie inkrementację zrobisz tak (eax,ebx - liczba):
> add ebx,1
> adc eax,0
> 

Chyba zaczynam coś rozumieć pierwsze add może ustawić CF a INC akurat
tej flagi nie ustawia, adc ją dodaje

> a przy inc będzie to coś takiego:
> inc ebx
> jno skip ;jz chyba też zadziała dla unsigned
> inc eax
> skip: ...
> 
> z dec podobnie
> 

ale tutaj chyba nie rozumiem , jno skip czy jo skip?
szczerze to jeszcze nie używałem ani adc ani overflow flag
i nie obliczałem jeszcze na liczbach ujemnych
ale napewno kiedyś mi się to rozjaśni dzięki temu przykładowi
Dzięki

-- 
Pozdrawiam - Grzechu
Linux x86_64

yesma pisze:
> Michoo pisze:
>> Jeżeli robisz operacje na liczbach złożonych z 2 słów procesora to 
>> normalnie inkrementację zrobisz tak (eax,ebx - liczba):
>> add ebx,1
>> adc eax,0
>>
> 
> Chyba zaczynam coś rozumieć pierwsze add może ustawić CF a INC akurat
> tej flagi nie ustawia, adc ją dodaje
> 
Dokładnie.

>> a przy inc będzie to coś takiego:
>> inc ebx
>> jno skip ;jz chyba też zadziała dla unsigned
>> inc eax
>> skip: ...
>>
>> z dec podobnie
>>
> 
> ale tutaj chyba nie rozumiem , jno skip czy jo skip?
Zwiększ jeżeli był overflow, czyli Jeżeli Nie wystąpił Overflow to nie 
zwiększaj.

To jest ogólna metoda tworzenia warunków w assemblerze - mamy w C:
[...]
--i;
if(i==0)//JEŻELI WARUNEK SPEŁNIONY - wykonaj kod
	foo();
foo_bar();
[...]

i kompilujemy to:
	dec edx
	jnz skip ;JEŻELI WARUNEK NIESPEŁNIONY - omiń kod
	call foo
skip:
	call foo_bar

zaoszczędzamy w ten sposób jeden skok w przypadku gdy warunek jest 
spełniony - po zrealizowaniu bloku if przechodzimy od razu do następnej 
instrukcji.

W przypadku if ... else ... na końcu bloku if i tak musimy wykonać skok 
bezwarunkowy, więc stosuje się inne optymalizacje:
if(a) foo(); else bar(); jest tożsame z if(!a) bar(); else foo();
więc możemy zamienić kolejność bloków gdy jeden warunek liczy się 
prościej niż drugi.
jako pierwszy dajemy ten blok który się częściej wykona - na starych x86 
(i na risc) często skok to 2 cykle, brak skoku - 1)
jeżeli są równie prawdopodobne to jako pierwszy dajemy blok, który jest 
krótszy - żeby cel skoku przy ominięciu był w L1


-- 
Pozdrawiam
Michoo

Michoo pisze:
> yesma pisze:
>> Michoo pisze:
>>> Jeżeli robisz operacje na liczbach złożonych z 2 słów procesora to 
>>> normalnie inkrementację zrobisz tak (eax,ebx - liczba):
>>> add ebx,1
>>> adc eax,0
>>>
>>
>> Chyba zaczynam coś rozumieć pierwsze add może ustawić CF a INC akurat
>> tej flagi nie ustawia, adc ją dodaje
>>
> Dokładnie.
> 
>>> a przy inc będzie to coś takiego:
>>> inc ebx
>>> jno skip ;jz chyba też zadziała dla unsigned
>>> inc eax
>>> skip: ...
>>>
>>> z dec podobnie
>>>
>>
>> ale tutaj chyba nie rozumiem , jno skip czy jo skip?
> Zwiększ jeżeli był overflow, czyli Jeżeli Nie wystąpił Overflow to nie 
> zwiększaj.

To z overflow ciężko mi zrozumieć bo niewiem kiedy
ta flaga jest ustawiana, jakoś słabo udokumentowana,
pewnie kiedyś gdzieś przeczytałem ale wyleciało mi
z pamięci bo nie używałem tej flagi.

> 
> To jest ogólna metoda tworzenia warunków w assemblerze - mamy w C:
> [...]
> --i;
> if(i==0)//JEŻELI WARUNEK SPEŁNIONY - wykonaj kod
>     foo();
> foo_bar();
> [...]
> 
> i kompilujemy to:
>     dec edx
>     jnz skip ;JEŻELI WARUNEK NIESPEŁNIONY - omiń kod
>     call foo
> skip:
>     call foo_bar
> 
> zaoszczędzamy w ten sposób jeden skok w przypadku gdy warunek jest 
> spełniony - po zrealizowaniu bloku if przechodzimy od razu do następnej 
> instrukcji.

a to rozumiem i też tak robię ale na P4 sub,1 jest szybsze
niż dec i też ustawi ZF, ale jeżeli chodzi o kod niekoniacznie
najszybki to będę nadal używał dec inc :)

> 
> W przypadku if ... else ... na końcu bloku if i tak musimy wykonać skok 
> bezwarunkowy, więc stosuje się inne optymalizacje:
> if(a) foo(); else bar(); jest tożsame z if(!a) bar(); else foo();
> więc możemy zamienić kolejność bloków gdy jeden warunek liczy się 
> prościej niż drugi.
> jako pierwszy dajemy ten blok który się częściej wykona - na starych x86 
> (i na risc) często skok to 2 cykle, brak skoku - 1)

też przeważnie to biorę pod uwagę (możliwość która jest bardziej
prawdopodobna pierwsza :)

> jeżeli są równie prawdopodobne to jako pierwszy dajemy blok, który jest 
> krótszy - żeby cel skoku przy ominięciu był w L1
> 

a o tym to jeszcze nie myślałem.
Tylko jak wyliczyć czy się zmieści w L1 czy nie ?, kod przed też chyba
może się znajdować w L1 ?. krótszy napewno
prędzej się tam zmieści więc trzeba się tego trzymać :)
Dzięki

-- 
Pozdrawiam - Grzechu
Linux x86_64

Użytkownik "yesma" <yesma@false.pl> napisał w wiadomości 
news:i24eks$ec7$1@inews.gazeta.pl...
> Czy nielepiej jest stosować zawsze ADD SUB zamiast INC DEC ?

W trybie 64-bitowym instrukcje INC i DEC zostały zastąpione innymi 

On 2010-08-25 14:35, prorok wrote:
> Użytkownik "yesma" <yesma@false.pl> napisał w wiadomości
> news:i24eks$ec7$1@inews.gazeta.pl...
>> Czy nielepiej jest stosować zawsze ADD SUB zamiast INC DEC ?
>
> W trybie 64-bitowym instrukcje INC i DEC zostały zastąpione innymi


Nie, usunięto tylko krótkie kody operacyjne dla INC i DEC na rejestrach.

yesma pisze:
> http://www.agner.org/instruction_tables.pdf
> 9 List of instruction timings and μop breakdown for P4E
> 
> Tyle że niema tutaj podane dla ADD, SUB operands r,i
> 
> Instruction       ADD, SUB         INC, DEC
> Operands          r,r              r
> µops              1                2
> Microcode         0                0
> Latency           1                1
> Throughput        0.25             0.5
> Port              0/1              0/1
> Unit              alu0/1           alu0/1
> 
> Czy nielepiej jest stosować zawsze ADD SUB zamiast INC DEC ?

INC/DEC nie ruszają flagi C.

Zbrakło w tym wątku wyjaśnienia, dlaczego w nowych procesorach ADD/SUB
jest szybsze od INC/DEC.
Chodzi o to, że INC/DEC nie zmieniają CF. Znaczniki "arytmetyczne"
OF,SF,ZF,CF są traktowane jako "jeden rejestr".
W związku z tym normalne operacje arytmetyczne, jak ADD i SUB, tylko
"zapisują rejestr znaczników arytmetycznych".
Natomiast INC/DEC muszą pozostawić CF niezmienione, co jest
implementowane przez "odczyt rejestru znaczników arytmetycznych",
zmianę znaczników oprócz CF i "zapis rejestru znaczników
arytmetycznych".
Dlatego INC i DEC muszą "znać wartość CF", więc gorzej sprawują się w
przypadku zrównoleglania i wykonywania instrukcji poza kolejnością.

W dniu 2010-07-20 17:15, yesma pisze:
> http://www.agner.org/instruction_tables.pdf
> 9 List of instruction timings and μop breakdown for P4E
>
> Tyle że niema tutaj podane dla ADD, SUB operands r,i
>
> Instruction ADD, SUB INC, DEC
> Operands r,r r
> µops 1 2
> Microcode 0 0
> Latency 1 1
> Throughput 0.25 0.5
> Port 0/1 0/1
> Unit alu0/1 alu0/1
>
> Czy nielepiej jest stosować zawsze ADD SUB zamiast INC DEC ?
INC/DEC nie ruszają flagi CF, co czasem jest wygodne.