Użytkownik "M.M." <m...@g...com> napisał:

> Np. dlatego ze porownujesz liczby zmiennoprzecinkowe
> "na ostro" a tego nie wolno robic (prawie) nigdy !

> Nie chciałem powiedzieć ani że wolno, ani że nie wolno.

> Chcę powiedzie tylko to, że jeśli zarówno argumenty funkcji
> jak i zwracane wartości są sumą (całkowitych) potęg dwójki

Kto Ci powiedzial ze fp C/C++ jest zapisane w postaci poteg dwojki ?
A moze sa pamietane decymalnie ? Albo siodemkowo ?

AK

do góry

Dnia Mon, 25 Mar 2013 14:17:01 +0100, wloochacz wyszeptal:

> W dniu 2013-03-25 14:08, M.M. pisze:
>> Pozostaje otwartym pytanie, jak dobry kod generowałby kompilator, np.
>> taki kompilator intela, jakby włożono w niego 10-30 razy więcej pracy:)
> Odpowiedź na to pytanie (po części) można znaleźć na stronie podanej
> przez firr kenobiego przy okazji testowania wydajności kodowania x264
> H.264/MPEG-4
> http://www.willus.com/ccomp_benchmark2.shtml?p17+s16

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.

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.

Pokazywanie znanych warunków brzegowych niczego nie dowodzi.

> Takie zdanie można tam znaleźć:
> "[...] For comparison, the latest version of 64-bit ffmpeg from zeranoe
> with hardware detection and in-line assembly enabled in the x264 module
> does the same conversion in 19 seconds--over 3X faster than the best
> result below!"

Mój GPU na płycie z Atomem robi to ze 20x szybciej, tylko co z tego?

--
Edek

do góry

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.

> Jeśli w powyższych warunkach jedna para: kompilator, procesor
> daje dokładną wartość, a druga nie daje, to chcę powiedzieć
> tylko to, że ta pierwsza działa trochę dokładniej.

Standard mówi precyzyjnie jak, dokładność wbrew pozorom nie
jest najważniejsza, jest druga po przewidywalności.

> Niby można to wytłumaczyć tym, że na typie zmiennoprzecinkowym mamy
> obliczenia przybliżone. Ale jeśli procesor/kompilator akurat dla jakiś
> argumentów może dać dokładny wynik a nie daje... to ja jakoś wolę nazywać
> gorszą jakością procesora czy kompilatora.

Bug kompilatora lub bilblioteki albo niepotrzebne opcje typu -ffast-math.

--
Edek

do góry

Użytkownik "Edek Pienkowski" <e...@g...com> napisał:

> Bug kompilatora lub bilblioteki

Nie siej bzdur, jeno sie doucz uzywania fp !

AK

do góry

Dnia Wed, 20 Mar 2013 16:10:44 -0700, M.M. wyszeptal:

> Prosty algorytm zwyczajnie nie może optymalizować. Musiałby dla wszystkich
> możliwych danych, sprawdzić wszystkie programy, wybrać te które dają poprawne
> wyniki, a z tych wybrać ten, który działa najszybciej. Dlatego im więcej
> konkretnych przykładów oprogramują twórcy kompilatorów, tym kompilator
> lepiej optymalizuje. Oprogramowanie "im więcej" zajmuje dużo czasu, dlatego
> dobry kompilator na dany procesor może wyjść jedynie z dużym opóźnieniem.
> Duże opóźnienie oznacza że na rynku będzie już inny procesor i nie warto
> pisać wyśrubowanego kompilatora, bo się przedawni zanim zostanie ukończony.

Kompilatory są śrubowane nie za pomocą generowania nowych rozszerzonych
instrukcji, przede wszystkim są to ogólnie używane metody działające
podobnie na wszystkich cpu i do tego część z nich dostosowuje generowany
kod do jakiegoś modelu konkretnego cpu. Zawsze model jest mega uproszczony.
Tak naprawdę żeby kompilator mógł wygenerować optymalny kod w takim
sensie jak mówisz musiałby to robić na docelowym sprzęcie, który informuje
odpowiedni kompilator o swoich cechach albo najlepiej daje kompilatorowi
cały projekt elektroniki w jakimś formacie... ciężko to sobie wyobrazić.

Niemniej procesory informujące kompilator (jit) o własnej strukturze
istnieją jako prototypy, zdecydowanie nie jest to dzisiejszy rynek PC.

> Podejrzewam, że jakby rozwój procesorów nagle zamarł i na każdym komputerze
> byłby ten sam procesor przez następne 10 lat, to za 2-3 lata ktoś by napisał
> kompilator generujący 2-3 razy szybszy kod. W czasach gdy się interesowałem
> tą tematyką sprawy właśnie tak się miały. Gdy wyszedł dobry kompilator na
> procesory pentium, to zwykle generował kod 3 razy szybszy niż poprzednie
> kompilatory. Podejrzewam że dziś jest podobnie, jakby wyszedł dobry kompilator
> na dany procesor, to by też była taka różnica.

Kiedys być może tak było, dzisiaj gdybyś się chciał udzielać w rozwijaniu
kompilatora miałbyś do czynienia z czymś co przypomina mistrzowską partię
szachów - choćbyś się uparł bardzo trudno jest znaleźć słabość o którą
można się zahaczyć żeby w krótkim czasie coś poprawić.

I wciąż twierdzę, że nigdy na Pentium tak nie było - to jest twierdzenie
oparte o skrajne przykłady małych fragmentów kodu.

--
Edek

do góry

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.

>
> Bug kompilatora lub bilblioteki albo niepotrzebne opcje typu -ffast-math.
>

To akurat różnie bywa.

--
Pozdrawiam
Michoo

do góry

W dniu 2013-03-25 16:03, Edek Pienkowski pisze:
> Dnia Mon, 25 Mar 2013 14:17:01 +0100, wloochacz wyszeptal:
>
>> W dniu 2013-03-25 14:08, M.M. pisze:
>>> Pozostaje otwartym pytanie, jak dobry kod generowałby kompilator, np.
>>> taki kompilator intela, jakby włożono w niego 10-30 razy więcej pracy:)
>> Odpowiedź na to pytanie (po części) można znaleźć na stronie podanej
>> przez firr kenobiego przy okazji testowania wydajności kodowania x264
>> H.264/MPEG-4
>> http://www.willus.com/ccomp_benchmark2.shtml?p17+s16
>
> 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.
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?

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

> Pokazywanie znanych warunków brzegowych niczego nie dowodzi.
>
>> Takie zdanie można tam znaleźć:
>> "[...] For comparison, the latest version of 64-bit ffmpeg from zeranoe
>> with hardware detection and in-line assembly enabled in the x264 module
>> does the same conversion in 19 seconds--over 3X faster than the best
>> result below!"
>
> Mój GPU na płycie z Atomem robi to ze 20x szybciej, tylko co z tego?
Ano to, że nie do końca zrozumiałeś intencji.
Ale, nieważne.

--
wloochacz

do góry

W dniu poniedziałek, 25 marca 2013 15:53:54 UTC+1 użytkownik AK napisał:

> Kto Ci powiedzial ze fp C/C++ jest zapisane w postaci poteg dwojki ?
> A moze sa pamietane decymalnie ? Albo siodemkowo ?

Nikt mi nic takiego nie mówił, ani ja nic takiego nie mówię.

Mówię tylko to, że jeśli jeden raz pow(3.0,2.0) równa się 9.0 na ostro, a
drugi raz nie równa się, to ten pierwszy raz jest dokładniej. Być
może taka dokładność jest okupiona wolniejszym wykonaniem.

Pozdrawiam

do góry

Użytkownik "M.M." <m...@g...com> napisał:

>> Kto Ci powiedzial ze fp C/C++ jest zapisane w postaci poteg dwojki ?
>> A moze sa pamietane decymalnie ? Albo siodemkowo ?
>
>Nikt mi nic takiego nie mówił, ani ja nic takiego nie mówię.
>
> Mówię tylko to, że jeśli jeden raz pow(3.0,2.0) równa się 9.0 na ostro, a
> drugi raz nie równa się, to ten pierwszy raz jest dokładniej.

Otoz nie.
Moze sie okazac, ze ten koproc/kompilator ktory akurat daje dokladnie
w tym przypadku pow(3.0,2.0), w wiekszosci innych przypadkow
sie "myli", natomiast ten gdy ten gorszy liczy "dobrze".

> Być może taka dokładność jest okupiona wolniejszym wykonaniem.

Byc moze, a byc moze nie (np inna reprezentacja wewnetrzna,
inna dlugoscia akumulatora itp).

Naprawde dyskusje o fp sa toczone na usenecie od zawsze (rowniez przeze
mnie wiec na stare lata sobie dam spokoj z nawracaniem kolejnego pokolenia
"mlodych gniewnych wiedzacych lepiej" bo mi szkoda resztek zycia.
Zalosc tylko bierze, ze na studiach tak podstawowej rzeczy nie ucza jak
traktowanie liczb fp w jezykach programowania jako ZAWSZE
obarczonych pewnym bledem.
Ta "niedokladnosc" nalezy traktowac nie jako neidoskonalosc
kompilatora/procesora ale jako NATURE tych liczb.
Owszem, ciagle w kompilatorach dazy sie do uleopszen w celu
molziwie najwiekszej dokladnosci/mozliwie najwiekszemu zneutralizowaniu
tej CECHY fp, ale absolutnie nie nalezy tego uwazac za
"zalatwienie" problemu. (Przyklad ostatnich ulepszen dla Pythona
na koncu).

Hint: szukaj chocby mych postow tyczacych fp
(Google: Adam Karpierz, liczby zmiennoprzecinkowe), a jak mi
nie wierzysz to spojrz do pierwszej ksiazki jaka przeczytalem po
postanowieniu nauczenia sie programowania:
prof Maciej Syslo "Algorytmy optymalizacji w jezyku Algol60"
a tam w pierwszym algorytmie - simplex - jak byk stoi cos w rodzaju
if abs(x - y) <= EPS then // czyli odpowiednik x == y
begin
comment Solution found;
...
end;

Pozdrawiam

AK

------------------
.
Conversions between floating-point numbers and strings are now correctly rounded on
most platforms.
These conversions occur in many different places: str() on floats and complex
numbers; the float and
complex constructors; numeric formatting; serializing and deserializing floats and
complex numbers
using the marshal, pickle and json modules; parsing of float and imaginary literals
in Python code;
and Decimal-to-float conversion.

Related to this, the repr() of a floating-point number x now returns a result based
on the shortest
decimal string that's guaranteed to round back to x under correct rounding (with
round-half-to-even
rounding mode). Previously it gave a string based on rounding x to 17 decimal digits.

The rounding library responsible for this improvement works on Windows and on Unix
platforms using
the gcc, icc, or suncc compilers. There may be a small number of platforms where
correct operation
of this code cannot be guaranteed, so the code is not used on such systems. You can
find out which
code is being used by checking sys.float_repr_style, which will be short if the new
code is in use
and legacy if it isn't.

Implemented by Eric Smith and Mark Dickinson, using David Gay's dtoa.c library; issue
7117.

.
Conversions from long integers and regular integers to floating point now round
differently,
returning the floating-point number closest to the number. This doesn't matter for
small integers
that can be converted exactly, but for large numbers that will unavoidably lose
precision, Python
2.7 now approximates more closely. For example, Python 2.6 computed the following:


>>>>>> n = 295147905179352891391
>>> float(n)
2.9514790517935283e+20
>>> n - long(float(n))
65535L

Python 2.7's floating-point result is larger, but much closer to the true value:

>>>>>> n = 295147905179352891391
>>> float(n)
2.9514790517935289e+20
>>> n - long(float(n))
-1L

(Implemented by Mark Dickinson; issue 3166.)

Integer division is also more accurate in its rounding behaviours. (Also implemented
by Mark
Dickinson; issue 1811.)

do góry

W dniu poniedziałek, 25 marca 2013 18:40:31 UTC+1 użytkownik AK napisał:
> Otoz nie.
> Moze sie okazac, ze ten koproc/kompilator ktory akurat daje dokladnie
> w tym przypadku pow(3.0,2.0), w wiekszosci innych przypadkow
> sie "myli", natomiast ten gdy ten gorszy liczy "dobrze".
No dobrze, może czegoś się dowiem, ale kompletnie nie wiem dlaczego miałby
na pozostałych liczyć dokładniej, jeśli na tym jednym przypadku nie potrafi
nadać poprawnych wartości wszystkim bitom?


> > Być może taka dokładność jest okupiona wolniejszym wykonaniem.
> Byc moze, a byc moze nie (np inna reprezentacja wewnetrzna,
> inna dlugoscia akumulatora itp).
Tego nie wiem, tak sobie gdybam tylko.


> Zalosc tylko bierze, ze na studiach tak podstawowej rzeczy nie ucza jak
> traktowanie liczb fp w jezykach programowania jako ZAWSZE
> obarczonych pewnym bledem.
No dobrze, ale dlaczego nie wziąć takiej liczby jaką podał programista, czy
takiej jaką podał użytkownik wprowadzający dane do programu? Dlaczego jeśli
programista wpisał 1.0, to kompilator ma zrobić z tego 1.00000000000101, bo
i tak i tak to jest przybliżone?


> Ta "niedokladnosc" nalezy traktowac nie jako neidoskonalosc
> kompilatora/procesora ale jako NATURE tych liczb.
Nadal nie rozumiem, dlaczego w mnożeniu przez 0.25 zwyczajnie nie
przesunąć bitów, ale przesunąć i na koniec jeszcze dokleić 2-3 losowe
bity?


> Owszem, ciagle w kompilatorach dazy sie do uleopszen w celu
> molziwie najwiekszej dokladnosci/mozliwie najwiekszemu zneutralizowaniu
> tej CECHY fp, ale absolutnie nie nalezy tego uwazac za
> "zalatwienie" problemu. (Przyklad ostatnich ulepszen dla Pythona
> na koncu).
Ogólnie jest tak jak piszesz i zgadzam się że nie można. Ale na niektórych
argumentach operacje zmiennoprzecinkowe powinny dawać dokładne wyniki.
Jeśli nie dają dokładnych wyników, to ja to nazywam po imieniu: "są
mniej dokładne" - nie popełniam tutaj żadnego błędu. Chętnie czegoś nowego
się nauczę o obliczeniach na liczbach zmiennoprzecinkowych, ale w
tym konkretnym przypadku sprawa raczej jest oczywista.

> a tam w pierwszym algorytmie - simplex - jak byk stoi cos w rodzaju
> if abs(x - y) <= EPS then // czyli odpowiednik x == y
Myślę że każdy z piszących na tę grupę wie iż w ogólności tak należy
porównywać liczby zmiennoprzecinkowe. Mnie chodziło o bardzo szczególny
podzbiór operacji na liczbach zmiennoprzecinkowych. Powiem więcej, mam
napisaną procedurę w której używam na ostro if( x == y ). Napisałem ją
będąc świadomy zagrożeń. Ale z drugiej strony wiedziałem, że nie ma żadnego
ważnego powodu, z którego procesor nie może na moich argumentach dać
dokładnego wyniku. Skompilowałem, zrobiłem test i okazało się, że na
docelowej architekturze działa poprawnie. Na innych niż docelowa nie
działa poprawnie, więc tam mogę skorygować błędy taką techniką jaką
przytoczyłeś, albo jakąś inną.

Pozdrawiam

do góry