04.04.2023 14:24
[#1]
Prędkość FPU
Przyznam, że do teraz nie mam pojęcia z jaką prędkością działa FPU i czy operacje na float'ach są szybsze niż gdybym to robił na fixed pointach, ale od początku...
Sorry jeśli pytania są ... głupie, ale mam chyba podstawowe braki wiedzy jak działa FPU.
1. Jeśli w programie w asm mam rozkazy dla FPU to procesor w tym momencie czeka na ich wykonanie czy to się dzieje równolegle? Pytanie jak to jest w FPU oddzielnym np 68882 a jak we wbudowanym w 040 albo 060?
2. ile cykli zegara (którego zegara CPU czy FPU?) zajmują instrukcje FPU? niby znalazłem jakie dokumentacje od nxp.com ale nie rozumiem po przeczytaniu ile cykli zajmie np dodanie dwóch liczb float.
3. czy np dzielenie w FPU dwóch liczb float będzie szybsze niż dzielenie w CPU dwóch integerów?
4. jak zmierzyć prędkość, albo porównać takie działania.
5. widziałem źródła do jakichś dem (chyba) Ephidreny i tam w sumie cała "wektorówka" jest na floatach więc to chyba sugeruje że tylko na floatach da się zrobić "Zaawansowane" i współczesne 3D w demach na Amidze.
moje pytania dotyczą 040 i 060. Z góry dzięki za pomoc w zrozumieniu FPU.
Sorry jeśli pytania są ... głupie, ale mam chyba podstawowe braki wiedzy jak działa FPU.
1. Jeśli w programie w asm mam rozkazy dla FPU to procesor w tym momencie czeka na ich wykonanie czy to się dzieje równolegle? Pytanie jak to jest w FPU oddzielnym np 68882 a jak we wbudowanym w 040 albo 060?
2. ile cykli zegara (którego zegara CPU czy FPU?) zajmują instrukcje FPU? niby znalazłem jakie dokumentacje od nxp.com ale nie rozumiem po przeczytaniu ile cykli zajmie np dodanie dwóch liczb float.
3. czy np dzielenie w FPU dwóch liczb float będzie szybsze niż dzielenie w CPU dwóch integerów?
4. jak zmierzyć prędkość, albo porównać takie działania.
5. widziałem źródła do jakichś dem (chyba) Ephidreny i tam w sumie cała "wektorówka" jest na floatach więc to chyba sugeruje że tylko na floatach da się zrobić "Zaawansowane" i współczesne 3D w demach na Amidze.
moje pytania dotyczą 040 i 060. Z góry dzięki za pomoc w zrozumieniu FPU.
04.04.2023 15:31
[#3]
Re: Prędkość FPU
@c64portal, post #1
68881 blokuje procesor, od 68882 nie blokuje (o ile pamięć mnie nie myli). Więc w teorii możesz równolegle wysłać komendę do FPU i liczyć na procku, ale wiadomo procesor i tak wysyła i odbiera dane z FPU. Więc (w teorii) można wysłać skomplikowane działanie do FPU i robić coś na CPU w międzyczasie.
Ostatnia aktualizacja: 04.04.2023 15:41:41 przez flops
Ostatnia aktualizacja: 04.04.2023 15:41:41 przez flops
04.04.2023 16:14
[#4]
Re: Prędkość FPU
@c64portal, post #1
Dla 68040/68060, procesor dziala rownolegle do FPU. Dla 68020/68030 czeka. Dla 68080 instrukcje FPU dzialaja tez rownolegle do instrukcji FPU. Instrukcje FPU uzywaja zegara FPU, tyle ze dla 68040/68060/68080 to on ma taka sama szybkosc co CPU. Jedynie dla 68020/68030 FPU moze dzialac asynchronicznie. W przypadku dzielenia to dla 68080 dzielenie floatow bedzie duzo szybsze niz dwoch integerow. W przypadku 68040/68060 to nie pamietam, ale chyba sa podobne szybkosci. Ogolnie wszystko zalezy pod jaki procesor chcesz pisac. Bo sa np. roznice w szybkosci dzialania instrukcji FPU dla 68060 i 68080. Dla 68080 oplaca sie unrollowac, to wtedy bedzie szybciej niz na 68060. A dla 68060 juz nie.
04.04.2023 19:49
[#5]
Re: Prędkość FPU
@c64portal, post #1
Nie wierz na słowo, benczmarkuj.
Ubij system. Zrób sobie jakąś pętlę z operacjami, ustaw przed nią color[0] na f00, po niej na 000 i czekaj na vblank. Wycyrkluj z długością pętli tak żeby nie zajmowała całego ekranu. Porównaj sobie osobno dwa konkurencyjne kody i zmierz wysokość czerwonego paska. ;)
Ubij system. Zrób sobie jakąś pętlę z operacjami, ustaw przed nią color[0] na f00, po niej na 000 i czekaj na vblank. Wycyrkluj z długością pętli tak żeby nie zajmowała całego ekranu. Porównaj sobie osobno dwa konkurencyjne kody i zmierz wysokość czerwonego paska. ;)
05.04.2023 07:30
[#6]
Re: Prędkość FPU
@teh_KaiN, post #5
Niby tak i pewnie na tym się skończy ale chciałbym znać też podstawy teoretyczne.
Inna sprawa, że takie "badanie kolorem" na emulatorze z jit'em i na full speed mało miarodajne będzie, bo jak na razie wszystkie moje procedurki to ledwo co tym czerwonym kolorem od góry okna wychodzą ;)
Don_Adan:
Raczej nie zakładam pisania pod 080, ale dzięki za odpowiedź. Kilka rzeczy mi się zaczyna rozjaśniać.
Dopytam tylko odnośnie unroll'a.
Masz na myśli że w ogóle nie opłaca się robić unroll na 060 czy tylko z FPU? a jeśli ogólnie to chętnie zrozumiem dla czego. sporo kodu mam teraz unroll'owanego. (nawyki z 6502)
Ostatnia aktualizacja: 05.04.2023 07:32:54 przez c64portal
Inna sprawa, że takie "badanie kolorem" na emulatorze z jit'em i na full speed mało miarodajne będzie, bo jak na razie wszystkie moje procedurki to ledwo co tym czerwonym kolorem od góry okna wychodzą ;)
Don_Adan:
Raczej nie zakładam pisania pod 080, ale dzięki za odpowiedź. Kilka rzeczy mi się zaczyna rozjaśniać.
Dopytam tylko odnośnie unroll'a.
Masz na myśli że w ogóle nie opłaca się robić unroll na 060 czy tylko z FPU? a jeśli ogólnie to chętnie zrozumiem dla czego. sporo kodu mam teraz unroll'owanego. (nawyki z 6502)
Ostatnia aktualizacja: 05.04.2023 07:32:54 przez c64portal
05.04.2023 11:30
[#7]
Re: Prędkość FPU
@c64portal, post #1
Będę pisał o 060 bo tylko to znam. Co do czytania dokumentacji to interesuje cię ogólnie cały rozdział 10 z User Manual. Przynajmniej koncept pOEP/sOEP bo to przekłada się już na ilość instrukcji na cykl. Przy sprawdzaniu ilości cykli (ten sam rozdział) masz zawsze kilka wartości w zależności od trybu adresowania itp, ale ogólnie żeby ocenić koszt instrukcji (np int vs float) interesuje cię wartość przed nawiasem.
Równolegle o ile nie ma w programie zależności pomiędzy rejestrami. Jeżeli użyjesz rejestru FPx razem z Dx to CPU czeka na FPU, ale to chyba oczywiste.
Nie, nie będzie szybsze. Ale czytaj 5.
Zegarem:) Jeżeli funkcja jest za krótka to po prostu wrzuć w pętlę.
Pewnie można ale najczęściej robi się równolegle na tym i na tym. Po prostu kwestia zbalansowania ilości instrukcji CPU i FPU. Niestety przez to że ogólnie FPU jest jakieś 2-8x wolniejsze niż FPU (2 dla mnożenia, 8 dla prawidłowo poukładanych prostych operacji które kosztują 0.5 cykla) nie jest to takie proste. Najczęściej potokuje się więc bardzo długie instrukcje. Przez to że masz dwa równoległe potoki możesz np zrobić patent który stosuje się np przy teksturowaniu z korekcją perspektywy albo transformacji przez macierz + skrót perspektywiczny (1/z). Odpalasz długą instrukcję na FPU której wyniku nie potrzebujesz jeszcze przez kilkadziesiąt cykli i jedziesz tylko na CPU. Chodzi o budowanie pętli w taki sposób (w uproszczeniu, tutaj musisz niestety raczej jechac asmem bo nie wiadomo co zrobi ci kompilator):
struct vtx_in;
float inv_v = 1.0f / vtx_in[0].z;
int inv_v_int = inv_v * 65536.0f; // przerzucenie na cpu, np poprzez zamianę na fixedpoint
float inv_v_next = 1.0f / vtx_in[1].z; // start długiej instrukcji, dzielenie to długa instrukcja
for(int i = 0; i < cnt; i++)
{
[cokolwiek używające <inv_v_int> i jedynie instrukcji cpu, np transformacja przez macierz albo teksturowanie kilku pikseli. wszystko poza dzieleniem bo po to robimy je na fpu żeby nie robić na cpu;)]
inv_v_int = inv_v_next * 65536.0f; // przerzucenie na cpu, np poprzez zamianę na fixedpoint. po tym mnożeniu na fpu jeszcze masz czas na kilka instrukcji CPU zanim odpalisz to dzielenie.
inv_v_next = 1.0f / vtx_in[i + 1].z;
}
1. Jeśli w programie w asm mam rozkazy dla FPU to procesor w tym momencie czeka na ich wykonanie czy to się dzieje równolegle? Pytanie jak to jest w FPU oddzielnym np 68882 a jak we wbudowanym w 040 albo 060?
Równolegle o ile nie ma w programie zależności pomiędzy rejestrami. Jeżeli użyjesz rejestru FPx razem z Dx to CPU czeka na FPU, ale to chyba oczywiste.
3. czy np dzielenie w FPU dwóch liczb float będzie szybsze niż dzielenie w CPU dwóch integerów?
Nie, nie będzie szybsze. Ale czytaj 5.
4. jak zmierzyć prędkość, albo porównać takie działania.
Zegarem:) Jeżeli funkcja jest za krótka to po prostu wrzuć w pętlę.
5. widziałem źródła do jakichś dem (chyba) Ephidreny i tam w sumie cała "wektorówka" jest na floatach więc to chyba sugeruje że tylko na floatach da się zrobić "Zaawansowane" i współczesne 3D w demach na Amidze.
Pewnie można ale najczęściej robi się równolegle na tym i na tym. Po prostu kwestia zbalansowania ilości instrukcji CPU i FPU. Niestety przez to że ogólnie FPU jest jakieś 2-8x wolniejsze niż FPU (2 dla mnożenia, 8 dla prawidłowo poukładanych prostych operacji które kosztują 0.5 cykla) nie jest to takie proste. Najczęściej potokuje się więc bardzo długie instrukcje. Przez to że masz dwa równoległe potoki możesz np zrobić patent który stosuje się np przy teksturowaniu z korekcją perspektywy albo transformacji przez macierz + skrót perspektywiczny (1/z). Odpalasz długą instrukcję na FPU której wyniku nie potrzebujesz jeszcze przez kilkadziesiąt cykli i jedziesz tylko na CPU. Chodzi o budowanie pętli w taki sposób (w uproszczeniu, tutaj musisz niestety raczej jechac asmem bo nie wiadomo co zrobi ci kompilator):
struct vtx_in;
float inv_v = 1.0f / vtx_in[0].z;
int inv_v_int = inv_v * 65536.0f; // przerzucenie na cpu, np poprzez zamianę na fixedpoint
float inv_v_next = 1.0f / vtx_in[1].z; // start długiej instrukcji, dzielenie to długa instrukcja
for(int i = 0; i < cnt; i++)
{
[cokolwiek używające <inv_v_int> i jedynie instrukcji cpu, np transformacja przez macierz albo teksturowanie kilku pikseli. wszystko poza dzieleniem bo po to robimy je na fpu żeby nie robić na cpu;)]
inv_v_int = inv_v_next * 65536.0f; // przerzucenie na cpu, np poprzez zamianę na fixedpoint. po tym mnożeniu na fpu jeszcze masz czas na kilka instrukcji CPU zanim odpalisz to dzielenie.
inv_v_next = 1.0f / vtx_in[i + 1].z;
}
05.04.2023 13:32
[#8]
Re: Prędkość FPU
@c64portal, post #6
To pewnie zalezy od kodu na 68060, zwykle krotszy kod jest lepszy, szczegolnie na 68020/68030, bo te procesory maja maly cache, bodaj 256 bajtow. Wiec dla 68020/68030 oplaca sie wieksza (ponad 240 bajty) petle podzielic na 2 mniejsze, bo i tak wtedy bedzie duzo szybciej. np. szybka procedura c2p dla 68020/68030 powinna miec 2 petle a nie 1. Unrolling kodu CPU na 68040/68060 raczej bedzie wolniejszy niz kodu w petli. Ale akurat to dotyczylo FPU w 68080, bo Gunnar sie chwalil, ze 68080 wykonuje podstawowe instrukcje FPU w 1 cykl, ale tylko jak sa niezalezne od siebie, bo tak to sa wolniejsze od FPU w 68060, ktory bodaj 3 cykle potrzebuje na podstawowe instrukcje FPU. A 68080 moze parenascie instrukcji FPU na raz wykonywac, ale to dlatego, ze 68080 ma jeszcze dodatkowe rejestry. Jesli targetem jest 68040/68060 to raczej nie ma sensu unrolling kodu, ale najlepiej zawsze jest przetestowac, obie wersje kodu. Jak chcesz procedure wyswietlajaca czas poszczegolnych procedur, to w watku na EAB o najszybszym c2p, taka kiedys pare razy wrzucilem, modyfikujac oryginalny kod Jim Drew. Po prostu podmieniasz procedure c2p na swoja wlasna, z dokladnoscia do 1 cykla bodaj wylicza, tylko odpowiednia ilosc razy trzeba procedure wywolac.
05.04.2023 13:54
[#9]
Re: Prędkość FPU
@Don_Adan, post #8
Na nowszych procesorach (w tym 060) unrolling pomaga w ten sposób że pozwala na eliminację zależności pomiędzy instrukcjami. To nie to samo co na 020/030 gdzie po prostu obsługa pętli była mniej kosztowna. Na 060 nie będzie wolniejszy o ile nie zapchasz kompletnie cache, ale naiwny unrolling bez przestawiania instrukcji nie ma sensu.
05.04.2023 16:28
[#10]
Re: Prędkość FPU
@c64portal, post #6
Hej, dodam do dyskusji, że naprawdę złą praktyką jest pisanie programu pod konkretny procesor, czy też koprocesor matematyczny.
Dlatego, że później będziesz miał problemy z uruchomieniem swojej gry/dema na różnych konfiguracjach Amig. Wyłapywanie błędów będzie utrudnione.
Szybkości procesorów w Amidze znacząco się od siebie różnią. Dobrą praktyką jest synchronizacja poprzez timer.device i/lub przerwania - z VBlank (1/50s) dla małej ziarnistości (np. rysowanie i animacja grafiki) oraz z MicroHz dla dużej ziarnistości.
W przypadku FPU jeżeli zależy nam na kompatybilności można też skorzystać z bibliotek matematycznych. Akceleracja zostanie automatycznie włączona i program zadziała wszędzie gdzie jest biblioteka (również bez FPU).
Optymalizować oczywiście można, ale należy wówczas wprowadzić dodatkową kontrolę i wykrywanie osprzętu (np. 68060 czy FPU).
Pozdrawiam.
Ostatnia aktualizacja: 05.04.2023 16:28:58 przez Hexmage960
Dlatego, że później będziesz miał problemy z uruchomieniem swojej gry/dema na różnych konfiguracjach Amig. Wyłapywanie błędów będzie utrudnione.
Szybkości procesorów w Amidze znacząco się od siebie różnią. Dobrą praktyką jest synchronizacja poprzez timer.device i/lub przerwania - z VBlank (1/50s) dla małej ziarnistości (np. rysowanie i animacja grafiki) oraz z MicroHz dla dużej ziarnistości.
W przypadku FPU jeżeli zależy nam na kompatybilności można też skorzystać z bibliotek matematycznych. Akceleracja zostanie automatycznie włączona i program zadziała wszędzie gdzie jest biblioteka (również bez FPU).
Optymalizować oczywiście można, ale należy wówczas wprowadzić dodatkową kontrolę i wykrywanie osprzętu (np. 68060 czy FPU).
Pozdrawiam.
Ostatnia aktualizacja: 05.04.2023 16:28:58 przez Hexmage960
05.04.2023 16:40
[#12]
Re: Prędkość FPU
@kiero, post #11
Wyjaśnię zatem, że musimy wybierać między wydajnością a kompatybilnością w tym przypadku. Oczywiście że emulacja FPU będzie wolna na komputerach bez FPU, ale program zadziała prawidłowo.
Implementacja funkcji matematycznych w tych bibliotekach jest dosyć dobra na maszynach z FPU. Własna optymalizacja to raczej tylko w rzadkich sytuacjach i dla osób które znają biegle ten temat.
Implementacja funkcji matematycznych w tych bibliotekach jest dosyć dobra na maszynach z FPU. Własna optymalizacja to raczej tylko w rzadkich sytuacjach i dla osób które znają biegle ten temat.
05.04.2023 17:27
[#14]
Re: Prędkość FPU
@kiero, post #7
Wow! Dzięki Kiero. Muszę to przetrawić choć i tak wiele już pomogłeś.
Dzięki także Don_Adan za dyskusję.
Zdradzę, że zacząłem pisać demo (kiedy wyjdzie to się okaże) i tym razem będzie na AGA i 060 bo w końcu zrozumiałem i obcykałem pare rzeczy w tym cały toolchain'ie opartym na GCC + VASM (od Bartmana). A jak zobaczyłem, że w zasadzie od ręki mam float'y to pojawiła się pokusa aby ich użyć, ale czuję że to w jeszcze kolejnej produkcji. To co teraz piszę skończę już raczej beż użycia floatów. Aha - i nie będą to jakieś super wyrafinowane efekty - takie troche lepszy Alien Apparat (czyli moje poprzednie demko ;) )
Szybkość 060 się przyda do c2p i może kilku drobnych efektów które sobie na razie wymyśliłem. No i w demach na AGA to chyba 060 to w sumie standard.
@Hexmage
Piszę konkretnie pod AGA i 060 bez wykorzystania systemu bo chcę na maksa mieć pewność że nie mam narzutów a jedyne wąskie gardła to moje słabe procedury/algorytmy. I tak, Synchro mam na przerwaniach.
Wrócę tu na pewno jeszcze z pytaniami.
Dzięki także Don_Adan za dyskusję.
Zdradzę, że zacząłem pisać demo (kiedy wyjdzie to się okaże) i tym razem będzie na AGA i 060 bo w końcu zrozumiałem i obcykałem pare rzeczy w tym cały toolchain'ie opartym na GCC + VASM (od Bartmana). A jak zobaczyłem, że w zasadzie od ręki mam float'y to pojawiła się pokusa aby ich użyć, ale czuję że to w jeszcze kolejnej produkcji. To co teraz piszę skończę już raczej beż użycia floatów. Aha - i nie będą to jakieś super wyrafinowane efekty - takie troche lepszy Alien Apparat (czyli moje poprzednie demko ;) )
Szybkość 060 się przyda do c2p i może kilku drobnych efektów które sobie na razie wymyśliłem. No i w demach na AGA to chyba 060 to w sumie standard.
@Hexmage
Piszę konkretnie pod AGA i 060 bez wykorzystania systemu bo chcę na maksa mieć pewność że nie mam narzutów a jedyne wąskie gardła to moje słabe procedury/algorytmy. I tak, Synchro mam na przerwaniach.
Wrócę tu na pewno jeszcze z pytaniami.
05.04.2023 17:47
[#16]
Re: Prędkość FPU
@kiero, post #13
@Kiero
OK. Ja nie piszę tego bez wcześniejszego zaznajomienia.
Widziałem zdeasemblowane funkcje z mathffp.library i z tego co pamiętam, każda funkcja składa się z kilku instrukcji FPU.
Wydaje mi się, że narzut wynika głównie z tego, że są skoki do podprocedur a nie kod in-line.
Chiałbym dodać, że istnieje pakiet "High Speed Math Libs" przeznaczony dla 68040+, który zawiera zoptymalizowane biblioteki matematyczne.
Ja po prostu lubię takie rozwiązania - bo mają pewne zalety.
Ale spoko, nie chcę nalegać. Zgadzam się, że kod FPU in-line jest szybszy.
@C64_Portal
Dobrze, że masz synchronizację na przerwaniach, ja też tak robię.
Życzę Ci powodzenia w kodowaniu dema.
Ostatnia aktualizacja: 05.04.2023 17:53:16 przez Hexmage960
OK. Ja nie piszę tego bez wcześniejszego zaznajomienia.
Widziałem zdeasemblowane funkcje z mathffp.library i z tego co pamiętam, każda funkcja składa się z kilku instrukcji FPU.Wydaje mi się, że narzut wynika głównie z tego, że są skoki do podprocedur a nie kod in-line.
Chiałbym dodać, że istnieje pakiet "High Speed Math Libs" przeznaczony dla 68040+, który zawiera zoptymalizowane biblioteki matematyczne.
Ja po prostu lubię takie rozwiązania - bo mają pewne zalety.
Ale spoko, nie chcę nalegać. Zgadzam się, że kod FPU in-line jest szybszy.
@C64_Portal
Dobrze, że masz synchronizację na przerwaniach, ja też tak robię.
Życzę Ci powodzenia w kodowaniu dema.
Ostatnia aktualizacja: 05.04.2023 17:53:16 przez Hexmage960