>
> Wymuszenie użycia koprocesora przez -mfpmath=387 nic nie daje,
>

ztcw nalezy uzywac "-mfpmath=both" to daje optymizatorowi do dyspozycji oba sety
rejestrów tym samym pozwala zmniejszyc odwolania do L1

mozesz przy okazji powiedziec moze jakiej opcji uzywasz do disasemblowania kodu?
uzywalem kilku ale te wyniki w disasembly jakos mi sie nie podobają i jeszcze sie
niezdecydowalem co daje 'najlepszą postac'

do góry

W dniu wtorek, 22 lipca 2014 18:07:36 UTC+2 użytkownik firr napisał:
> >
>
> > Wymuszenie użycia koprocesora przez -mfpmath=387 nic nie daje,
>
> >
>
>
>
> ztcw nalezy uzywac "-mfpmath=both" to daje optymizatorowi do dyspozycji oba sety
rejestrów tym samym pozwala zmniejszyc odwolania do L1
>
tak wiec both wydaje sie najsensowniejsza opcja,
podobno tez autowektoryzer dla sse startuje dopiero przy -O3 tak ze mozna probowac -
ale
na ten autowektoryzer tak po prawdzie to bym za bardzo nie liczył (chyba ze ktos poda
przyklad ze to choc 'czasem' ;/ dziala)

do góry

On 22.07.2014 18:07, firr wrote:
>>
>> Wymuszenie użycia koprocesora przez -mfpmath=387 nic nie daje,
>>
>
> ztcw nalezy uzywac "-mfpmath=both" to daje optymizatorowi do

Nic nie zmieniło.

> dyspozycji oba sety rejestrów tym samym pozwala zmniejszyc odwolania
> do L1

Wątpię z tym cache. Może w bardzo specyficznym przypadku, gdy akurat
kilka rejestrów więcej ratuje sytuację.


> mozesz przy okazji powiedziec moze jakiej opcji uzywasz do
> disasemblowania kodu? uzywalem kilku ale te wyniki w disasembly jakos
> mi sie nie podobają i jeszcze sie niezdecydowalem co daje 'najlepszą
> postac'

objdump -d

Żeby mieszało z kodem jeszcze -S, wychodzi tak sobie.
Kompilować pewnie trzeba z -g.

pzdr
bartekltg

do góry

W dniu wtorek, 22 lipca 2014 18:39:09 UTC+2 użytkownik bartekltg napisał:
> On 22.07.2014 18:07, firr wrote:
>
> >>
>
> >> Wymuszenie użycia koprocesora przez -mfpmath=387 nic nie daje,
>
> >>
>
> >
>
> > ztcw nalezy uzywac "-mfpmath=both" to daje optymizatorowi do
>
>
>
> Nic nie zmieniło.
>
>
>
> > dyspozycji oba sety rejestrów tym samym pozwala zmniejszyc odwolania
>
> > do L1
>
>
>
> Wątpię z tym cache. Może w bardzo specyficznym przypadku, gdy akurat
>
> kilka rejestrów więcej ratuje sytuację.
>
>
>
>
>
> > mozesz przy okazji powiedziec moze jakiej opcji uzywasz do
>
> > disasemblowania kodu? uzywalem kilku ale te wyniki w disasembly jakos
>
> > mi sie nie podobają i jeszcze sie niezdecydowalem co daje 'najlepszą
>
> > postac'
>
>
>
> objdump -d
>
>
>
> Żeby mieszało z kodem jeszcze -S, wychodzi tak sobie.
>
> Kompilować pewnie trzeba z -g.
>
no niewazne, ja uzywam -both ;/

a mozesz moze przy okazji sprawdzic czy dla exp() tez generuje cos na sse ze
skokami?

do góry

W dniu 2014-07-22 15:58, bartekltg pisze:
> Zerknąłem do tego, co robi oryginalny log. Też głownie
> mnoży i dodaje, ma jednak nieco więcej skoków.

Czy logarytm nie jest liczony przez koprocesor znacznie szybciej?

do góry

trochę zboczyliśmy z tematu...

pytanie jest takie, jak uzyskać równomierny rozkład punktów na osi x,
gdy skala jest logarytmiczna...

nie wiem czy Ktoś mnie zrozumie, ale może...

do góry

a jeśli chodzi o prędkość, to musi się wyrabiać w jakichś 20ms...

do góry

On 22.07.2014 21:25, Borneq wrote:
> W dniu 2014-07-22 15:58, bartekltg pisze:
>> Zerknąłem do tego, co robi oryginalny log. Też głownie
>> mnoży i dodaje, ma jednak nieco więcej skoków.
>
> Czy logarytm nie jest liczony przez koprocesor znacznie szybciej?

Sporo w bibliotece używają sse to chyba nie. Sprawdzenie
nie jest takie łatwe, np mimo -mfpmath=387 w funkcji uzywa
sse. Udało się dopiero dla aplikacji 32 bitowej.
Pętla kręci się nieco, ale wyraźnie wolniej, ale czy to oznacza,
że koprocesor jest dokłądnie o tyle wolniejszy ciężko powiedzieć.

pzdr
bartekltg

do góry

On 22.07.2014 21:40, feldmarszałek tusk wrote:
> trochę zboczyliśmy z tematu...
>
> pytanie jest takie, jak uzyskać równomierny rozkład punktów na osi x,
> gdy skala jest logarytmiczna...

Ciąg geometryczny.


pzdr
bartekltg

do góry

8-|

do góry