eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programming[asm] normalize na fpu
Ilość wypowiedzi w tym wątku: 12

  • 1. Data: 2012-08-12 11:48:31
    Temat: [asm] normalize na fpu
    Od: " kenobi" <f...@g...pl>

    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/


  • 2. Data: 2012-08-12 21:28:37
    Temat: Re: [asm] normalize na fpu
    Od: Roman W <b...@g...pl>

    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


  • 3. Data: 2012-08-13 00:29:11
    Temat: Re: [asm] normalize na fpu
    Od: " " <f...@g...SKASUJ-TO.pl>

    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/


  • 4. Data: 2012-08-13 15:31:26
    Temat: Re: normalize na fpu
    Od: bartekltg <b...@g...com>

    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




  • 5. Data: 2012-08-13 18:08:31
    Temat: Re: normalize na fpu
    Od: " kenobi" <f...@W...gazeta.pl>

    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/


  • 6. Data: 2012-08-13 18:46:36
    Temat: Re: normalize na fpu
    Od: bartekltg <b...@g...com>

    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


  • 7. Data: 2012-08-13 19:01:52
    Temat: Re: normalize na fpu
    Od: " kenobi" <f...@W...gazeta.pl>

    > >
    > > 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/


  • 8. Data: 2012-08-13 19:30:49
    Temat: Re: normalize na fpu
    Od: bartekltg <b...@g...com>

    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



  • 9. Data: 2012-08-13 20:07:20
    Temat: Re: normalize na fpu
    Od: Michoo <m...@v...pl>

    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


  • 10. Data: 2012-08-13 20:24:03
    Temat: Re: normalize na fpu
    Od: " kenobi" <f...@W...gazeta.pl>

    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/

strony : [ 1 ] . 2


Szukaj w grupach

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: