11.10.2020 18:58
[#1]
[C] Optymalizacja za pomocą fixed point zamiast floating point
Czesc,
Czy w procach 040/060 ktore maja wbudowane fpu
jest sens optymalizować kod za pomocą zmiennych
Typu fixed point zamiast używać floating point.
Macie takie doświadczenia, gdzie po takiej zamianie odczuliście
Przyspieszenie?
Druga sprawa, jak korzysta się z FPU pod C? Korzystamy po prostu
Z tych bibliotek math ieee ? Czy trzeba to pod asemblerem robic?
Czy może kompilator jest na tyle mądry ze sam to ogarnia?
Czy w procach 040/060 ktore maja wbudowane fpu
jest sens optymalizować kod za pomocą zmiennych
Typu fixed point zamiast używać floating point.
Macie takie doświadczenia, gdzie po takiej zamianie odczuliście
Przyspieszenie?
Druga sprawa, jak korzysta się z FPU pod C? Korzystamy po prostu
Z tych bibliotek math ieee ? Czy trzeba to pod asemblerem robic?
Czy może kompilator jest na tyle mądry ze sam to ogarnia?
11.10.2020 20:25
[wyróżniony]
[#2]
Re: [C] Optymalizacja za pomocą fixed point zamiast floating point
@mateusz_s, post #1
Z FPU można korzystać na wiele sposobów. Najprościej jest ustawić odpowiednią flagę kompilatora (o ile kompilator umie generować kod dla FPU oczywiście) wtedy rozkazy FPU będą bezpośrednio wplecione w kod. Tak skompilowany kod będzie najszybszy, ale będzie wymagał FPU. Warto więc dodać na początku sprawdzanie obecności FPU i wyjście z komunikatem, jeżeli go brak. Inaczej program na maszynie bez FPU się wywali.
Wywoływanie bibliotek MathIEEE jest sposobem uniwersalnym (będzie działać na wszystkim), ale dość nieefektywnym dla maszyn z FPU, bo narzut wywołania funkcji wobec np. jednego rozkazu FPU (proste działania arytmetyczne typu IEEESPAdd()) jest spory. Zazwyczaj kompilator też ma odpowiednią do tego flagę i sam generuje odpowiednie wywołania. Chyba, że nasz ulubiony kompilator nie ma, wtedy można też radzić sobie z jawnym wywołaniem. Co prawda czytelności kodu to specjalnie nie służy, ale też działa.
Biblioteki MathIEEE są dobre, jeżeli mamy do wykonania stosunkowo niewiele obliczeń i nie jest to krytyczne czasowo, a nie chce się nam generować dwóch oddzielnych binarek (dla maszyn z FPU i bez).
Co do szybkości i optymalizowania wypowiedzieć się nie mogę, bo nigdy nie testowałem tego na 040/060.
Wywoływanie bibliotek MathIEEE jest sposobem uniwersalnym (będzie działać na wszystkim), ale dość nieefektywnym dla maszyn z FPU, bo narzut wywołania funkcji wobec np. jednego rozkazu FPU (proste działania arytmetyczne typu IEEESPAdd()) jest spory. Zazwyczaj kompilator też ma odpowiednią do tego flagę i sam generuje odpowiednie wywołania. Chyba, że nasz ulubiony kompilator nie ma, wtedy można też radzić sobie z jawnym wywołaniem. Co prawda czytelności kodu to specjalnie nie służy, ale też działa.
Biblioteki MathIEEE są dobre, jeżeli mamy do wykonania stosunkowo niewiele obliczeń i nie jest to krytyczne czasowo, a nie chce się nam generować dwóch oddzielnych binarek (dla maszyn z FPU i bez).
Co do szybkości i optymalizowania wypowiedzieć się nie mogę, bo nigdy nie testowałem tego na 040/060.
11.10.2020 22:26
[wyróżniony]
[#3]
Re: [C] Optymalizacja za pomocą fixed point zamiast floating point
@mateusz_s, post #1
Sporo dem używa fixed point, z czego wynika "trzęsawka" na teksturach czy nawet trajektoriach wierzchołków. Trzeba brać poprawkę na to że nie każde turbo 040/060 ma zamontowany procesor z fpu.
Używam fixed point z użyciem libfixmath z githuba i jest grubo szybciej niż soft floaty, na które skazani byliby użytkownicy "kastratów". Na niedopalonych sprzętach to wręcz jedyna droga. Co do wydajności ze sprzętowym fpu nie podam Ci żadnego benchmarka ale nie bez powodu tę technikę stosuje się często dzisiaj w systemach wbudowanych - poszukaj tabeli ile cykli zajmuje sprzętowy rozkaz na floatach a ile na liczbach całkowitych - powinna być różnica.
Dużym minusem fixed pointów jest czytelność kodu - ciut bardziej skomplikowane obliczenia to masa zagnieżdżonych wywołań funkcji - pomaga tu cpp i jego możliwość przeładowania operatorów.
Co do użycia bibliotek ieee - kompilator od bebbo sam generuje kod je inicjujący i używa ich funkcji do obliczeń fp jaka linkujesz z -lm. Masz też chyba flagi -softfloat i -hardfloat do określenia pod co ma generować kod.
Używam fixed point z użyciem libfixmath z githuba i jest grubo szybciej niż soft floaty, na które skazani byliby użytkownicy "kastratów". Na niedopalonych sprzętach to wręcz jedyna droga. Co do wydajności ze sprzętowym fpu nie podam Ci żadnego benchmarka ale nie bez powodu tę technikę stosuje się często dzisiaj w systemach wbudowanych - poszukaj tabeli ile cykli zajmuje sprzętowy rozkaz na floatach a ile na liczbach całkowitych - powinna być różnica.
Dużym minusem fixed pointów jest czytelność kodu - ciut bardziej skomplikowane obliczenia to masa zagnieżdżonych wywołań funkcji - pomaga tu cpp i jego możliwość przeładowania operatorów.
Co do użycia bibliotek ieee - kompilator od bebbo sam generuje kod je inicjujący i używa ich funkcji do obliczeń fp jaka linkujesz z -lm. Masz też chyba flagi -softfloat i -hardfloat do określenia pod co ma generować kod.
11.10.2020 22:33
[wyróżniony]
[#4]
Re: [C] Optymalizacja za pomocą fixed point zamiast floating point
25.07.2021 21:30
[#6]
Re: [C] Optymalizacja za pomocą fixed point zamiast floating point
@mateusz_s, post #1
Czołem,
minęło parę miesięcy odkąd zadałem to pytanie i z racji tego,
że dużo pracowałem i testowałem podczas pracy przy Raycasterze,
to chcę uzupełnić temat o swoje doświadczenia..
- korzystam z tych flag przy kompilacji w C (Bebbo 6.5.0) żeby m.in. włączyć FPU
-O3 -m68060 -mtune=68060 -mhard-float
- w przypadku wewnętrzej pętli która jest wykonywana np. dla każdego pixela w kolumnie czy w wierszu
(czyli generalnie bardzo często) zamiana z floating point na fixedpoint (czyli po prostu int)
BARDZO PRZYŚPIESZYŁA CAŁOŚĆ. I tu ciekawostka w tej pętli operacjami na tych floating point było tylko jedno dodawanie. Bardzo się zdziwiłem - i tu omówię jeszcze dwa przypadki:
1. W pierwszym przypadku, w zewnętrzej pętli zamieniałem potrzebne wartości z floating point na fixed point zaraz przed wejściem w kolejną petlę - tu jak powiedziałem było tylko dodawanie - i już samo to bardzo przyśpieszło proces texturowania ścian lub sufitów. Dodam, że wszsytkie pozostałe obliczenia były nadal wykonywane floating pointach - w zewnętrznej pętli - i jeszcze "wyżej"
2. Natomiast w poźniejszych testach cały algorytm przerobiłem od poczatku już na fixed pointy, tak że nieużywałem wcale floatów - i było jeszcze szybciej..
Podsumowując:
Polecam zamianę na fixed pointy przynajmniej w przypadkach kiedy bardzo często robimy na nich operację nawet proste,
jak dodawanie - czyli w jakiś wewnętrzach pętlach. W przypadku rzadszego korzystania nie wpływa to już tak bardzo na wydajność.
minęło parę miesięcy odkąd zadałem to pytanie i z racji tego,
że dużo pracowałem i testowałem podczas pracy przy Raycasterze,
to chcę uzupełnić temat o swoje doświadczenia..
- korzystam z tych flag przy kompilacji w C (Bebbo 6.5.0) żeby m.in. włączyć FPU
-O3 -m68060 -mtune=68060 -mhard-float
- w przypadku wewnętrzej pętli która jest wykonywana np. dla każdego pixela w kolumnie czy w wierszu
(czyli generalnie bardzo często) zamiana z floating point na fixedpoint (czyli po prostu int)
BARDZO PRZYŚPIESZYŁA CAŁOŚĆ. I tu ciekawostka w tej pętli operacjami na tych floating point było tylko jedno dodawanie. Bardzo się zdziwiłem - i tu omówię jeszcze dwa przypadki:
1. W pierwszym przypadku, w zewnętrzej pętli zamieniałem potrzebne wartości z floating point na fixed point zaraz przed wejściem w kolejną petlę - tu jak powiedziałem było tylko dodawanie - i już samo to bardzo przyśpieszło proces texturowania ścian lub sufitów. Dodam, że wszsytkie pozostałe obliczenia były nadal wykonywane floating pointach - w zewnętrznej pętli - i jeszcze "wyżej"
2. Natomiast w poźniejszych testach cały algorytm przerobiłem od poczatku już na fixed pointy, tak że nieużywałem wcale floatów - i było jeszcze szybciej..
Podsumowując:
Polecam zamianę na fixed pointy przynajmniej w przypadkach kiedy bardzo często robimy na nich operację nawet proste,
jak dodawanie - czyli w jakiś wewnętrzach pętlach. W przypadku rzadszego korzystania nie wpływa to już tak bardzo na wydajność.