eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programming[asm] normalize na fpu › Re: normalize na fpu
  • Data: 2012-08-13 18:46:36
    Temat: Re: normalize na fpu
    Od: bartekltg <b...@g...com> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    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

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: