wyprodukowalem taka funkcje do normalizacji
wektora 3 floatow

_asm_normalize10:; Function begin
push ebp ; 002E _ 55
mov ebp, esp ; 002F _ 89. E5
mov eax, dword [ebp+8H] ; 0031 _ 8B. 45, 08
fld dword [eax] ; 0034 _ D9. 00
fmul st0, st(0) ; 0036 _ DC. C8
fld dword [eax+4H] ; 0038 _ D9. 40, 04
fmul st0, st(0) ; 003B _ DC. C8
fld dword [eax+8H] ; 003D _ D9. 40, 08
fmul st0, st(0) ; 0040 _ DC. C8
faddp st1, st(0) ; 0042 _ DE. C1
faddp st1, st(0) ; 0044 _ DE. C1
fsqrt ; 0046 _ D9. FA
fld1 ; 0048 _ D9. E8
fdivrp st1, st(0) ; 004A _ DE. F1
fld dword [eax] ; 004C _ D9. 00
fmul st(0), st1 ; 004E _ D8. C9
fstp dword [eax] ; 0050 _ D9. 18
fld dword [eax+4H] ; 0052 _ D9. 40, 04
fmul st(0), st1 ; 0055 _ D8. C9
fstp dword [eax+4H] ; 0057 _ D9. 58, 04
fld dword [eax+8H] ; 005A _ D9. 40, 08
fmulp st1, st(0) ; 005D _ DE. C9
fstp dword [eax+8H] ; 005F _ D9. 58, 08
pop ebp ; 0062 _ 5D
ret ; 0063 _ C3
; _asm_normalize10 End of function

90 cykli - i tak szybciej niz to co wyprodukowal moj
kompiletor (150) [dokladnie nie wiem nawet czemu
moze przez to ze ta funkcja jest okrojona tj nie
sprawdza czy nie ma dzielenia przez 0 ;-)

chcialbym to poprawic, czy ktos zna jakies zasady
'polepszania' takich funkcji ? i moglby zaproponowac
poprawki?




--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On Sunday, August 12, 2012 10:48:31 AM UTC+1, kenobi wrote:
> wyprodukowalem taka funkcje do normalizacji
>
> wektora 3 floatow
>
>
>
> _asm_normalize10:; Function begin
>
> push ebp ; 002E _ 55
>
> mov ebp, esp ; 002F _ 89. E5
>
> mov eax, dword [ebp+8H] ; 0031 _ 8B. 45, 08
>
> fld dword [eax] ; 0034 _ D9. 00
>
> fmul st0, st(0) ; 0036 _ DC. C8
>
> fld dword [eax+4H] ; 0038 _ D9. 40, 04
>
> fmul st0, st(0) ; 003B _ DC. C8
>
> fld dword [eax+8H] ; 003D _ D9. 40, 08
>
> fmul st0, st(0) ; 0040 _ DC. C8
>
> faddp st1, st(0) ; 0042 _ DE. C1
>
> faddp st1, st(0) ; 0044 _ DE. C1
>
> fsqrt ; 0046 _ D9. FA
>
> fld1 ; 0048 _ D9. E8
>
> fdivrp st1, st(0) ; 004A _ DE. F1
>
> fld dword [eax] ; 004C _ D9. 00
>
> fmul st(0), st1 ; 004E _ D8. C9
>
> fstp dword [eax] ; 0050 _ D9. 18
>
> fld dword [eax+4H] ; 0052 _ D9. 40, 04
>
> fmul st(0), st1 ; 0055 _ D8. C9
>
> fstp dword [eax+4H] ; 0057 _ D9. 58, 04
>
> fld dword [eax+8H] ; 005A _ D9. 40, 08
>
> fmulp st1, st(0) ; 005D _ DE. C9
>
> fstp dword [eax+8H] ; 005F _ D9. 58, 08
>
> pop ebp ; 0062 _ 5D
>
> ret ; 0063 _ C3
>
> ; _asm_normalize10 End of function
>
>
>
> 90 cykli - i tak szybciej niz to co wyprodukowal moj
>
> kompiletor (150) [dokladnie nie wiem nawet czemu
>
> moze przez to ze ta funkcja jest okrojona tj nie
>
> sprawdza czy nie ma dzielenia przez 0 ;-)
>
>
>
> chcialbym to poprawic, czy ktos zna jakies zasady
>
> 'polepszania' takich funkcji ? i moglby zaproponowac
>
> poprawki?

A pod jakim katem chcesz poprawiac? Szybkosci czy dokladnosci?

RW

do góry

Roman W <b...@g...pl> napisał(a):

> On Sunday, August 12, 2012 10:48:31 AM UTC+1, kenobi wrote:
> > wyprodukowalem taka funkcje do normalizacji
> >
> > wektora 3 floatow
> >
> >
> >
> > _asm_normalize10:; Function begin
> >
> > push ebp ; 002E _ 55
> >
> > mov ebp, esp ; 002F _ 89. E5
> >
> > mov eax, dword [ebp+8H] ; 0031 _ 8B. 45,
08
> >
> > fld dword [eax] ; 0034 _ D9. 00
> >
> > fmul st0, st(0) ; 0036 _ DC. C8
> >
> > fld dword [eax+4H] ; 0038 _ D9. 40,
04
> >
> > fmul st0, st(0) ; 003B _ DC. C8
> >
> > fld dword [eax+8H] ; 003D _ D9. 40,
08
> >
> > fmul st0, st(0) ; 0040 _ DC. C8
> >
> > faddp st1, st(0) ; 0042 _ DE. C1
> >
> > faddp st1, st(0) ; 0044 _ DE. C1
> >
> > fsqrt ; 0046 _ D9. FA
> >
> > fld1 ; 0048 _ D9. E8
> >
> > fdivrp st1, st(0) ; 004A _ DE. F1
> >
> > fld dword [eax] ; 004C _ D9. 00
> >
> > fmul st(0), st1 ; 004E _ D8. C9
> >
> > fstp dword [eax] ; 0050 _ D9. 18
> >
> > fld dword [eax+4H] ; 0052 _ D9. 40,
04
> >
> > fmul st(0), st1 ; 0055 _ D8. C9
> >
> > fstp dword [eax+4H] ; 0057 _ D9. 58,
04
> >
> > fld dword [eax+8H] ; 005A _ D9. 40,
08
> >
> > fmulp st1, st(0) ; 005D _ DE. C9
> >
> > fstp dword [eax+8H] ; 005F _ D9. 58,
08
> >
> > pop ebp ; 0062 _ 5D
> >
> > ret ; 0063 _ C3
> >
> > ; _asm_normalize10 End of function
> >
> >
> >
> > 90 cykli - i tak szybciej niz to co wyprodukowal moj
> >
> > kompiletor (150) [dokladnie nie wiem nawet czemu
> >
> > moze przez to ze ta funkcja jest okrojona tj nie
> >
> > sprawdza czy nie ma dzielenia przez 0 ;-)
> >
> >
> >
> > chcialbym to poprawic, czy ktos zna jakies zasady
> >
> > 'polepszania' takich funkcji ? i moglby zaproponowac
> >
> > poprawki?
>
> A pod jakim katem chcesz poprawiac? Szybkosci czy dokladnosci?
>
> RW

pod wzgledem szybkosi i prostoty, - chce sie tez po prostu
podszkolic w asmie

--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On 12 Sie, 11:48, " kenobi" <f...@g...pl> wrote:

> 90 cykli - i tak szybciej niz to co wyprodukowal moj
> kompiletor (150)  [dokladnie nie wiem nawet czemu
> moze przez to ze ta funkcja jest okrojona tj nie
> sprawdza czy nie ma dzielenia przez 0 ;-)

Sprzed której wojny to kompilator?
******
void norm(double &a, double &b, double &c)
{
double dl = sqrt(a*a+b*b+c*c);
a/=dl;
b/=dl;
c/=dl;
}
******
g++ bla.cpp -O2 -S --verbose-asm -g
as -alhnd bla.s > bla.lst
*****
10:bla.cpp **** double dl = sqrt(a*a+b*b+c*c);
61 .loc 1 10 0
62 0004 F20F101F movsd (%rdi), %xmm3 # *a_1(D),
*a_1(D)
63 0008 F20F1016 movsd (%rsi), %xmm2 # *b_5(D),
tmp96
64 000c 660F28C3 movapd %xmm3, %xmm0 # *a_1(D),
tmp82
65 0010 F20F100A movsd (%rdx), %xmm1 # *c_10(D),
tmp94
66 0014 F20F59D2 mulsd %xmm2, %xmm2 # tmp96, tmp96
67 0018 F20F59C3 mulsd %xmm3, %xmm0 # *a_1(D),
tmp82
68 001c F20F59C9 mulsd %xmm1, %xmm1 # tmp94, tmp94
69 0020 F20F58C2 addsd %xmm2, %xmm0 # tmp96, tmp82
70 0024 F20F58C1 addsd %xmm1, %xmm0 # tmp94, tmp82
71 0028 F20F51C8 sqrtsd %xmm0, %xmm1 # tmp82, tmp77
72 002c 660F2EC9 ucomisd %xmm1, %xmm1 # tmp77, tmp77
73 0030 7A25 jp .L6 #,
74 .LVL1:
75 .L2:
11:bla.cpp **** a/=dl;
76 .loc 1 11 0
77 0032 F20F5ED9 divsd %xmm1, %xmm3 # tmp77, tmp88
78 0036 F20F111F movsd %xmm3, (%rdi) # tmp88,
*a_1(D)
12:bla.cpp **** b/=dl;
79 .loc 1 12 0
80 003a F20F1006 movsd (%rsi), %xmm0 # *b_5(D),
tmp90
81 003e F20F5EC1 divsd %xmm1, %xmm0 # tmp77, tmp90
82 0042 F20F1106 movsd %xmm0, (%rsi) # tmp90,
*b_5(D)
13:bla.cpp **** c/=dl;
83 .loc 1 13 0
84 0046 F20F1002 movsd (%rdx), %xmm0 # *c_10(D),
tmp92
85 004a F20F5EC1 divsd %xmm1, %xmm0 # tmp77, tmp92
86 004e F20F1102 movsd %xmm0, (%rdx) # tmp92,
*c_10(D)
87 .LBE2:
14:bla.cpp ****
15:bla.cpp **** }


Na oko wręcz szybciej:)


>  chcialbym to poprawic, czy ktos zna jakies zasady
> 'polepszania' takich funkcji ? i moglby zaproponowac
> poprawki?

1. gcc/visual studio.
2. Jakaś wyspecjalizowana biblioteka, jeśli tych obliczeń więcej.

3. Jeśli nie musisz mieć dokładności, to spróbuj to,
http://en.wikipedia.org/wiki/Fast_inverse_square_roo
t#Overview_of_the_code
100 lat temu zastosowanie kilku iteracji Newtona było szybsze niż
sqrt z koprocesora, ale dziś nie musi to być prawdą.

pzdr
bartekltg

do góry

bartekltg <b...@g...com> napisał(a):

> On 12 Sie, 11:48, " kenobi" <f...@g...pl> wrote:
>
> > 90 cykli - i tak szybciej niz to co wyprodukowal moj
> > kompiletor (150) =A0[dokladnie nie wiem nawet czemu
> > moze przez to ze ta funkcja jest okrojona tj nie
> > sprawdza czy nie ma dzielenia przez 0 ;-)
>
> Sprzed kt=F3rej wojny to kompilator?
> ******
> void norm(double &a, double &b, double &c)
> {
> double dl =3D sqrt(a*a+b*b+c*c);
> a/=3Ddl;
> b/=3Ddl;
> c/=3Ddl;
> }
> ******
> g++ bla.cpp -O2 -S --verbose-asm -g
> as -alhnd bla.s > bla.lst
> *****
> 10:bla.cpp **** double dl =3D sqrt(a*a+b*b+c*c);
> 61 .loc 1 10 0
> 62 0004 F20F101F movsd (%rdi), %xmm3 # *a_1(D),
> *a_1(D)
> 63 0008 F20F1016 movsd (%rsi), %xmm2 # *b_5(D),
> tmp96
> 64 000c 660F28C3 movapd %xmm3, %xmm0 # *a_1(D),
> tmp82
> 65 0010 F20F100A movsd (%rdx), %xmm1 # *c_10(D),
> tmp94
> 66 0014 F20F59D2 mulsd %xmm2, %xmm2 # tmp96, tmp96
> 67 0018 F20F59C3 mulsd %xmm3, %xmm0 # *a_1(D),
> tmp82
> 68 001c F20F59C9 mulsd %xmm1, %xmm1 # tmp94, tmp94
> 69 0020 F20F58C2 addsd %xmm2, %xmm0 # tmp96, tmp82
> 70 0024 F20F58C1 addsd %xmm1, %xmm0 # tmp94, tmp82
> 71 0028 F20F51C8 sqrtsd %xmm0, %xmm1 # tmp82, tmp77
> 72 002c 660F2EC9 ucomisd %xmm1, %xmm1 # tmp77, tmp77
> 73 0030 7A25 jp .L6 #,
> 74 .LVL1:
> 75 .L2:
> 11:bla.cpp **** a/=3Ddl;
> 76 .loc 1 11 0
> 77 0032 F20F5ED9 divsd %xmm1, %xmm3 # tmp77, tmp88
> 78 0036 F20F111F movsd %xmm3, (%rdi) # tmp88,
> *a_1(D)
> 12:bla.cpp **** b/=3Ddl;
> 79 .loc 1 12 0
> 80 003a F20F1006 movsd (%rsi), %xmm0 # *b_5(D),
> tmp90
> 81 003e F20F5EC1 divsd %xmm1, %xmm0 # tmp77, tmp90
> 82 0042 F20F1106 movsd %xmm0, (%rsi) # tmp90,
> *b_5(D)
> 13:bla.cpp **** c/=3Ddl;
> 83 .loc 1 13 0
> 84 0046 F20F1002 movsd (%rdx), %xmm0 # *c_10(D),
> tmp92
> 85 004a F20F5EC1 divsd %xmm1, %xmm0 # tmp77, tmp92
> 86 004e F20F1102 movsd %xmm0, (%rdx) # tmp92,
> *c_10(D)
> 87 .LBE2:
> 14:bla.cpp ****
> 15:bla.cpp **** }
>
>
> Na oko wr=EAcz szybciej:)
>
>
> > =A0chcialbym to poprawic, czy ktos zna jakies zasady
> > 'polepszania' takich funkcji ? i moglby zaproponowac
> > poprawki?
>
> 1. gcc/visual studio.
> 2. Jaka=B6 wyspecjalizowana biblioteka, je=B6li tych oblicze=F1 wi=EAcej.
>
> 3. Je=B6li nie musisz mie=E6 dok=B3adno=B6ci, to spr=F3buj to,
> http://en.wikipedia.org/wiki/Fast_inverse_square_roo
t#Overview_of_the_code
> 100 lat temu zastosowanie kilku iteracji Newtona by=B3o szybsze ni=BF
> sqrt z koprocesora, ale dzi=B6 nie musi to by=E6 prawd=B1.
>


w danym momencie zalezy mi na treningu asma a nie wynikach
kompilacji, do sse jeszcze nie dojechalem
- bardzo zle napisana procedura, nie ma sprawdzenia czy nie
ma dzielenie przez 0 (co prawda takie podejscie jest
wydajniejsze bo np w moim raytracerku zerowe wektory sie
akurat nie trafiały) i nie pisz4e sie trzech dzielen tylko
cos w stylu

double inv_d = 1.0/sqrt(a*a+b*b+c*c);
a*=inv_d;
b*=inv_d;
c*=inv_d;

nie wiem jak na najnowszysch prockach ale na
moim jedno dzielenie to kilka/kilkanascie mnozeni
i dodawan, czyli to jest blisko 3 razy szybszew,
gcc jak widac tego zreszta nie zoptymalizowal i wstawil
te trzy dzielenia, w sumie fajnie popatrzec na
wynik jego produkcji - popatrze jeszcze na to - imo
jakos specjalnie to sie chyba nie spisal, normalny
kod spod sztancy tak jak i w bcc32










--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On 13 Sie, 18:08, " kenobi" <f...@W...gazeta.pl> wrote:
> bartekltg <b...@g...com> napisał(a):
>
>
>
>
>
>
>
>
>
> > On 12 Sie, 11:48, " kenobi" <f...@g...pl> wrote:
>
> > > 90 cykli - i tak szybciej niz to co wyprodukowal moj
> > > kompiletor (150) =A0[dokladnie nie wiem nawet czemu
> > > moze przez to ze ta funkcja jest okrojona tj nie
> > > sprawdza czy nie ma dzielenia przez 0 ;-)
>
> > Sprzed kt=F3rej wojny to kompilator?
> > ******
> > void norm(double &a, double &b, double &c)
> > {
> > double dl =3D sqrt(a*a+b*b+c*c);
> > a/=3Ddl;
> > b/=3Ddl;
> > c/=3Ddl;
> > }
> > ******
> > g++ bla.cpp -O2 -S --verbose-asm -g
> > as -alhnd bla.s > bla.lst
> > *****
> >   10:bla.cpp       **** double dl =3D sqrt(a*a+b*b+c*c);
> >   61                            .loc 1 10 0
> >   62 0004 F20F101F              movsd   (%rdi), %xmm3   # *a_1(D),
> > *a_1(D)
> >   63 0008 F20F1016              movsd   (%rsi), %xmm2   # *b_5(D),
> > tmp96
> >   64 000c 660F28C3              movapd  %xmm3, %xmm0    # *a_1(D),
> > tmp82
> >   65 0010 F20F100A              movsd   (%rdx), %xmm1   # *c_10(D),
> > tmp94
> >   66 0014 F20F59D2              mulsd   %xmm2, %xmm2    # tmp96, tmp96
> >   67 0018 F20F59C3              mulsd   %xmm3, %xmm0    # *a_1(D),
> > tmp82
> >   68 001c F20F59C9              mulsd   %xmm1, %xmm1    # tmp94, tmp94
> >   69 0020 F20F58C2              addsd   %xmm2, %xmm0    # tmp96, tmp82
> >   70 0024 F20F58C1              addsd   %xmm1, %xmm0    # tmp94, tmp82
> >   71 0028 F20F51C8              sqrtsd  %xmm0, %xmm1    # tmp82, tmp77
> >   72 002c 660F2EC9              ucomisd %xmm1, %xmm1    # tmp77, tmp77
> >   73 0030 7A25                  jp      .L6     #,
> >   74                    .LVL1:
> >   75                    .L2:
> >   11:bla.cpp       **** a/=3Ddl;
> >   76                            .loc 1 11 0
> >   77 0032 F20F5ED9              divsd   %xmm1, %xmm3    # tmp77, tmp88
> >   78 0036 F20F111F              movsd   %xmm3, (%rdi)   # tmp88,
> > *a_1(D)
> >   12:bla.cpp       **** b/=3Ddl;
> >   79                            .loc 1 12 0
> >   80 003a F20F1006              movsd   (%rsi), %xmm0   # *b_5(D),
> > tmp90
> >   81 003e F20F5EC1              divsd   %xmm1, %xmm0    # tmp77, tmp90
> >   82 0042 F20F1106              movsd   %xmm0, (%rsi)   # tmp90,
> > *b_5(D)
> >   13:bla.cpp       **** c/=3Ddl;
> >   83                            .loc 1 13 0
> >   84 0046 F20F1002              movsd   (%rdx), %xmm0   # *c_10(D),
> > tmp92
> >   85 004a F20F5EC1              divsd   %xmm1, %xmm0    # tmp77, tmp92
> >   86 004e F20F1102              movsd   %xmm0, (%rdx)   # tmp92,
> > *c_10(D)
> >   87                    .LBE2:
> >   14:bla.cpp       ****
> >   15:bla.cpp       **** }
>
> > Na oko wr=EAcz szybciej:)
>
> > > =A0chcialbym to poprawic, czy ktos zna jakies zasady
> > > 'polepszania' takich funkcji ? i moglby zaproponowac
> > > poprawki?
>
> > 1. gcc/visual studio.
> > 2. Jaka=B6 wyspecjalizowana biblioteka, je=B6li tych oblicze=F1 wi=EAcej.
>
> > 3. Je=B6li nie musisz mie=E6 dok=B3adno=B6ci, to spr=F3buj to,
> >http://en.wikipedia.org/wiki/Fast_inverse_square_ro
ot#Overview_of_the...
> > 100 lat temu zastosowanie kilku iteracji Newtona by=B3o szybsze ni=BF
> > sqrt z koprocesora, ale dzi=B6 nie musi to by=E6 prawd=B1.
>
> w danym momencie zalezy mi na treningu asma a nie wynikach
> kompilacji, do sse jeszcze nie dojechalem
>  - bardzo zle napisana procedura, nie ma sprawdzenia czy nie
> ma dzielenie przez 0 (co prawda takie podejscie jest
> wydajniejsze bo np w moim raytracerku zerowe wektory sie

Dzielenie przez zero oznacza, że wektor jest zerowy.
Normalizacja takiego jest zadaniem nieokreślonym
a wynikiem mojego programu jest trójka "nan",
jak najbardziej poprawny wynik:)


> akurat nie trafiały) i nie pisz4e sie trzech dzielen tylko
> cos w stylu
>
>  double inv_d = 1.0/sqrt(a*a+b*b+c*c);
>  a*=inv_d;
>  b*=inv_d;
>  c*=inv_d;

A to święta prawda. Zapomniałem o --fast-math
(normalnie siedzę w VS).

Po tej zmienie divsd zamienie się na mulsd.

> gcc jak widac tego zreszta nie zoptymalizowal i wstawil
> te trzy dzielenia, w sumie fajnie popatrzec na

Bez --fast-math mu nie wolno, bo zmienia to wynik.


pzdr
bartekltg

do góry

> >
> > w danym momencie zalezy mi na treningu asma a nie wynikach
> > kompilacji, do sse jeszcze nie dojechalem
> > =A0- bardzo zle napisana procedura, nie ma sprawdzenia czy nie
> > ma dzielenie przez 0 (co prawda takie podejscie jest
> > wydajniejsze bo np w moim raytracerku zerowe wektory sie
>
> Dzielenie przez zero oznacza, =BFe wektor jest zerowy.
> Normalizacja takiego jest zadaniem nieokre=B6lonym
> a wynikiem mojego programu jest tr=F3jka "nan",
> jak najbardziej poprawny wynik:)
>

to fajnie tylko,

1) raz ze nie wiem jak jest z tymi wyjatkami
fpu i czy nawet jak to nie leci (a u mnie w kompilatorze
jak podziele przez zero to leci po prostu blad aplikacji)
czy nie powoduje to jakichs opoznien w stosunku do
operacji na nie NANach (a o ile pamietam to costam czytalem
ze jest wtedy wolniej)

2) nawet jakby bylo ok (no byloby fajnie) to chyba w c nie
ma mozliwosci sprawdzenia

(f(f==NAN) costam ...

tak ze z takim wynikiem nie wiadomo co zrobic :O
(faktycznie bład c trzebaby to wbudować)







>
> > akurat nie trafia=B3y) i nie pisz4e sie trzech dzielen tylko
> > cos w stylu
> >
> > =A0double inv_d =3D 1.0/sqrt(a*a+b*b+c*c);
> > =A0a*=3Dinv_d;
> > =A0b*=3Dinv_d;
> > =A0c*=3Dinv_d;
>
> A to =B6wi=EAta prawda. Zapomnia=B3em o --fast-math
> (normalnie siedz=EA w VS).
>
> Po tej zmienie divsd zamienie si=EA na mulsd.
>
> > gcc jak widac tego zreszta nie zoptymalizowal i wstawil
> > te trzy dzielenia, w sumie fajnie popatrzec na
>
> Bez --fast-math mu nie wolno, bo zmienia to wynik.
>
>
> pzdr
> bartekltg
>


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On 13 Sie, 19:01, " kenobi" <f...@W...gazeta.pl> wrote:
>
> to fajnie tylko,
>
> 1) raz ze nie wiem jak jest z tymi wyjatkami
> fpu i czy nawet jak to nie leci (a u mnie w kompilatorze
>  jak podziele przez zero to leci po prostu blad aplikacji)
>  czy nie powoduje to jakichs opoznien w stosunku do
> operacji na nie NANach (a o ile pamietam to costam czytalem
> ze jest wtedy wolniej)

Czy po podzieleniu przez zero ma krzyczeć, czy
jechać dalej, zależy od flag kompilacji.

> 2) nawet jakby bylo ok (no byloby fajnie) to chyba w c nie
> ma mozliwosci sprawdzenia
>
> (f(f==NAN)  costam ...

To nie zadziała, bo... nan nanowi nierówny;)

>
> tak ze z takim wynikiem nie wiadomo co zrobic :O
> (faktycznie b ad c trzebaby to wbudowa )

W gcc jest isnan, ale mi nie działa.
W VS jest _isnan i działa.
Oficjalnie w nowym c++ ma być isnan.

Więcej:
http://stackoverflow.com/questions/570669/checking-i
f-a-double-or-float-is-nan-in-c

pzdr
bartekltg

do góry

On 13.08.2012 15:31, bartekltg wrote:
> On 12 Sie, 11:48, " kenobi"<f...@g...pl> wrote:
>
>> 90 cykli - i tak szybciej niz to co wyprodukowal moj
>> kompiletor (150) [dokladnie nie wiem nawet czemu
>> moze przez to ze ta funkcja jest okrojona tj nie
>> sprawdza czy nie ma dzielenia przez 0 ;-)
>
> Sprzed której wojny to kompilator?
[...]
> Na oko wręcz szybciej:)
A jakby tak użyć SSE? - przecież nie robi się normalizacji na jednym
wektorze tylko zazwyczaj na całej paczce, więc warto zadbać o potokowość:

- zapakować wektor (a,b,c,0)
- MULPS
- 3 MOV* + ADD, żeby dostać sumę
- SQRTSS
- 3 MOV* żeby powielić 3 razy
- DIVPS


--
Pozdrawiam
Michoo

do góry

Michoo <m...@v...pl> napisał(a):

> On 13.08.2012 15:31, bartekltg wrote:
> > On 12 Sie, 11:48, " kenobi"<f...@g...pl> wrote:
> >
> >> 90 cykli - i tak szybciej niz to co wyprodukowal moj
> >> kompiletor (150) [dokladnie nie wiem nawet czemu
> >> moze przez to ze ta funkcja jest okrojona tj nie
> >> sprawdza czy nie ma dzielenia przez 0 ;-)
> >
> > Sprzed której wojny to kompilator?
> [...]
> > Na oko wręcz szybciej:)
> A jakby tak użyć SSE? - przecież nie robi się normalizacji na jednym
> wektorze tylko zazwyczaj na całej paczce, więc warto zadbać o potokowość:
>
> - zapakować wektor (a,b,c,0)
> - MULPS
> - 3 MOV* + ADD, żeby dostać sumę
> - SQRTSS
> - 3 MOV* żeby powielić 3 razy
> - DIVPS
>
>
wiadomo,
moge przetwarzac w raytracerze 8 pixeli na raz i pod avx powinno
to byc mw kosztem jednego,
acz nie wiem czy nie pojawialyby sie pewne trudnosci
zwiazane z tym ze w tej paczce 8 pixeli np
piec moze jako odbite od kulki isc jedna sciezka liczenia
a 3 pozostale jako przechodzace obok kulki zupelnie inną
(np odbic sie od plaszczyzny w tle)
nie mam pojecia jak koduje sie takie 'rozszczepione'
obliczenia -- Tymczasowo chce sobie tylko przypomniec kodowanie
pod fpu









--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry