W dniu środa, 27 marca 2013 14:32:06 UTC+1 użytkownik AK napisał:

> Programujac w C++ powinienes olac "cieplym moczem" IEEE itp
Właściwie to zawsze byłem bliski olania, znam tylko podstawy.
Więc wygląda na to, że nie spieramy się o nic :)
Pozdrawiam

do góry

Użytkownik "Michoo" <m...@v...pl> napisał:

> Spróbuj:
> std::cout<<std::numeric_limits<long double>::is_iec559<<std::endl;

A co mi to da ?
Ja chce _ustawic_ IEEE, a nie sie dowiedziec ze false czy true bo mi to do niczego
niepotrzebne.
PS: Poza tym wciaz prawie wszytsko mi pisze ze objecta niet.

AK

do góry

On Wednesday, 27 March 2013 08:54:12 UTC+1, AK wrote:
> Użytkownik "Adam Klobukowski" <a...@g...com> napisał:
>
> > http://en.wikipedia.org/wiki/IEEE_floating_point
>
> W standardzie IEEE piszesz programy ?

Nie, ale standard ten definiuje najczesciej używane typy danych zmiennoprzecinkowych,

AdamK

do góry

Dnia Mon, 25 Mar 2013 16:30:27 +0100, wloochacz wyszeptal:

> W dniu 2013-03-25 16:03, Edek Pienkowski pisze:
>> Dnia Mon, 25 Mar 2013 14:17:01 +0100, wloochacz wyszeptal:

>> To *nie* jest odpowiedź na pytanie. Od dawna wiadomo, że kompilatory
>> w brzegowych przypadkach dają wolniejszy kod - dotyczy to *bardzo małych*
>> procedur operujących na *dużych danych*, czyli video, raid, szyfrowanie.
>> Takie opłaca się pisać ręcznie.
> Tak wiem - ale ręcznie, tzn. optymalnie (a przynajmniej lepiej niż
> kompilator ogólnego przeznaczenia), prawda?
> I tak, IMO, jest to podpowiedź na to pytanie - poniekąd.
> Mamy tu porównanie kodu generowanego przez kompilator z kodem
> zoptymalizowanym ręcznie.

To nie jest kod zoptymalizowany ręcznie, porównujesz jabłka do
czereśni. To jest kod pisany wiele razy, testowany, mierzony i
poprawiany wiele razy ręcznie. Znajdź kod pisany ręcznie raz,
tak jak kompilator kompiluje raz, i wtedy porównaj to co wyjdzie.

> A poniekąd dlatego, że nie wiemy dokładnie jak zrealizowano to zadanie
> przez "zeranoe", także ciężko cokolwiek porównywać w "twardych" śiśle
> mierzalnych testach...
> Ja sobie gdybam, że mocno zoptymalizowany kod pod konkretne zadanie (tu
> - kodowanie x264) jest tylko 3x szybszy od kompilatora ogólnego
> przeznaczania.
> I teraz jest pytanie - jest to *tylko* czy *aż* 3x szybszy kod?

Robi się *aż* takie rzeczy, jak wiele implementacji i przy starcie
mierzona jest wydajność wszystkich na sprzęcie i wybiera
najlepszą. BTW, to mi podsuwa pewien pomysł..

>> Gdyby kompilator miał je optymalizować porządnie, co najmniej trzeba
>> by przekazać kompilatorowi informację "poświęć na te 100 linijek 30%
>> czasu kompilacji poświęcanego na milion linii reszty kodu". Nie
>> ma czegoś takiego w językach programowania, więc kompilatory optymalizują
>> cały program i tu już są w granicach 10%. Niby jest PGO, ale jest
>> mało używane więc mało rozwijane, dodatkowo dochodzi detekcja sprzętu,
>> więc poważne PGO powinno mieć farmę testową różnych maszyn dla
>> sprawdzenia - nie widziałem nigdy takiej implementacji.
> Co nie znaczy, że nie istnieje...

Ale oznacza, że kompilator przetwarzając program nie wie ile i jakich
będzie danych, a piszący ręcznie wie. Dlatego jest inny rezultat.

--
Edek

do góry

Dnia Mon, 25 Mar 2013 16:22:23 +0100, Michoo wyszeptal:

> On 25.03.2013 16:10, Edek Pienkowski wrote:
>> Dnia Mon, 25 Mar 2013 07:35:16 -0700, M.M. wyszeptal:
>>
>>> Chcę powiedzie tylko to, że jeśli zarówno argumenty funkcji
>>> jak i zwracane wartości są sumą (całkowitych) potęg dwójki i
>>> mieszczą się w zakresie liczby zmiennoprzecinkowej, to nie
>>> ma żądnych ważnych powodów, aby procesor podał wartość
>>> przybliżoną - wtedy może podać dokładną.
>>
>> Żadnych oprócz standartu liczb zmiennoprzecinkowych. Swoją
>> szosą na potęgach dwójki można uzyskać precyzyjne ~30 cyfr
>> dokładności - swoisty trick.
>
> Na szybko wychodzi mi 100 bitów.

Owszem. Trick opiera się na wyświetlaniu liczb zmiennoprzecinkowych,
sprawdź jak się wyświetla 2.0 do n-tej. Precyzji w sensie obliczeniowym
większej niż jest się nie uzyska.

--
Edek

do góry

W dniu czwartek, 28 marca 2013 12:11:48 UTC+1 użytkownik Edek Pienkowski napisał:

> To nie jest kod zoptymalizowany ręcznie, porównujesz jabłka do
> czereśni. To jest kod pisany wiele razy, testowany, mierzony i
> poprawiany wiele razy ręcznie. Znajdź kod pisany ręcznie raz,
> tak jak kompilator kompiluje raz, i wtedy porównaj to co wyjdzie.

Czy w praktyce jest mozliwe napisanie wlasnie takiego kompilatora?
Takiego zeby wygenerowal N wariantow procedury, uruchomil kazdy wariant
na przykladowych danych i wybral wariant najszybszy?

Pozdrawiam

do góry

Dnia Wed, 27 Mar 2013 09:46:53 -0700 (PDT), M.M. napisał(a):

> W dniu środa, 27 marca 2013 14:32:06 UTC+1 użytkownik AK napisał:
>
>> Programujac w C++ powinienes olac "cieplym moczem" IEEE itp
> Właściwie to zawsze byłem bliski olania, znam tylko podstawy.
> Więc wygląda na to, że nie spieramy się o nic :)
> Pozdrawiam

Klotnia jest bez sensu, Kalkulator Windows ma tzw. "tryb programisty" i idac
za jego helpem:

"W trybie programisty są obsługiwane tylko liczby całkowite. Części ułamkowe
są odrzucane."

Zatem programistow nie powinny obchodzic takie detale jak wartosci
rzeczywiste ani tym bardziej ich reprezentacja czyli trza "olac cieplym
moczem"! :P


--
pozdro
R.e.m.e.K

do góry

W dniu niedziela, 24 marca 2013 17:54:34 UTC+1 użytkownik M.M. napisał:
> W dniu niedziela, 24 marca 2013 00:06:09 UTC+1 użytkownik firr kenobi napisał:
>
> > bylo juz o tym na grupie (plc, w styczniu 2012
>
> > w watku pt "typy proste i operatory dla sse")
>
> Zdaje się, że nieraz wracałeś do tego tematu :)
>
> Teraz temat wrócił :)
>

co ciekawe rzaden z tutejszych
pseudospecjalistów od gcc nie wspomnieł
ze w gcc jest juz cos takiego (o czym
dowiedzialem sie wczoraj czy dzisiaj)

typedef double v2df __attribute__ ((vector_size(16)));

const v2df five = { 5.0, 5.0 };
const v2df four = { 4.0, 4.0 };
v2df result = (four * four - five)/five;


u mnie pod mingw kompiluje sie i działa
raczej bez problemu, typedef jest
niewygodny i lepiej by bylo zrobic
wbudowany typ ale rozwiazanie dosyc
podobne i z tego co mi wiadomo kody
przepisane na tym działaja szybciej

do góry

W dniu niedziela, 7 kwietnia 2013 14:53:17 UTC+2 użytkownik firr kenobi napisał:
> ze w gcc jest juz cos takiego (o czym
> dowiedzialem sie wczoraj czy dzisiaj)
> typedef double v2df __attribute__ ((vector_size(16)));
> const v2df five = { 5.0, 5.0 };
> const v2df four = { 4.0, 4.0 };
> v2df result = (four * four - five)/five;
Tam:
http://benchmarksgame.alioth.debian.org/u32/program.
php?test=nbody&lang=gpp&id=5
jest:
__m128d dx,dy,dz;

I to właśnie ta wersja jest na topie:
http://benchmarksgame.alioth.debian.org/u32/benchmar
k.php?test=nbody&lang=all

Pozdrawiam




>
>
>
>
>
> u mnie pod mingw kompiluje sie i działa
>
> raczej bez problemu, typedef jest
>
> niewygodny i lepiej by bylo zrobic
>
> wbudowany typ ale rozwiazanie dosyc
>
> podobne i z tego co mi wiadomo kody
>
> przepisane na tym działaja szybciej

do góry

W dniu niedziela, 7 kwietnia 2013 23:52:23 UTC+2 użytkownik M.M. napisał:
> W dniu niedziela, 7 kwietnia 2013 14:53:17 UTC+2 użytkownik firr kenobi napisał:
>
> > ze w gcc jest juz cos takiego (o czym
>
> > dowiedzialem sie wczoraj czy dzisiaj)
>
> > typedef double v2df __attribute__ ((vector_size(16)));
>
> > const v2df five = { 5.0, 5.0 };
>
> > const v2df four = { 4.0, 4.0 };
>
> > v2df result = (four * four - five)/five;
>
> Tam:
>
> http://benchmarksgame.alioth.debian.org/u32/program.
php?test=nbody&lang=gpp&id=5
>
> jest:
>
> __m128d dx,dy,dz;
>

wnioski sa pewnie takie ze zapewne
mozne tego po prostu zaczac z marszu
uzywac (jako ze jest to zapewne
wygodniejsze niz asm)

moze sie nawet własnie przesiade na
mingw za jakis czas razem ze zmianą
kompa (choć ten stary trzydziestodwubitowy
sprzet był fajny :C )

do góry