07.09.2017 15:57
[#632]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@radzik, post #631
LW 5 jest sporo szybszy od 3.5.
Sprawdź to, bo ja ostatnio na WinUAE miałem odwrotnie:
https://www.ppa.pl/forum/amiga/36972/nadchodzi-vampire-core-gold3-integracja-paula-ecs-aga-z-hdmi/18#m584106
07.09.2017 16:09
[#633]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@kwaku85, post #624
Chyba nie ma co się bulwersować po obu stronach dyskusji.
(Prawie) nikt chyba tu nie mówił (chyba, że coś przeoczyłem), że Wampir jest do cna zły, a cały projekt to pic na wodę. Nie. Trzeba przyznać, że potrafi zasuwać nieziemsko - zarówno z WHD, jak i z Doomem, Gloomem, Ambermoonem (przy mapach 3D), czy Frontierem. Photogenics też chodzi na tym cudnie.
Fakt, może sam jestem trochę zawiedziony, ale swoje posty (mówię tu w swoim imieniu) traktuję w ramach zwykłego feedbacku, czyli informacji zwrotnej dla Twórców, że w niektórych wypadkach jest jednak coś nie tak. Mam po prostu nadzieję, że będą w stanie to poprawić i trzymam za to kciuki. Jeżeli nikt im o takich niedociągnięciach nie powie, to nigdy nie zwrócą na to uwagi, bo będą przekonani, że wszystko gra.
Bo kwestii tego, że nie będzie im się chciało tego poprawiać (i skupią się nad czymś innym) nie biorę w ogóle pod uwagę. Gdyby nie mieli chęci zrobienia tego jak najlepiej, to Vampire w ogóle by nie powstał. Osobiście bardzo szanuję osoby, które chcą w ogóle zrobić cokolwiek dla rozwoju (w tę czy inną stronę) "systemu".
Tak, karta nie jest czymś ukończonym, więc dlatego sam czekam na nowy, lepszy wsad. Dlatego też użyłem zwrotu, że "w chwili obecnej" Vampire nie nadaje się do renderów z FPU. Może kiedyś będzie inaczej?
(Prawie) nikt chyba tu nie mówił (chyba, że coś przeoczyłem), że Wampir jest do cna zły, a cały projekt to pic na wodę. Nie. Trzeba przyznać, że potrafi zasuwać nieziemsko - zarówno z WHD, jak i z Doomem, Gloomem, Ambermoonem (przy mapach 3D), czy Frontierem. Photogenics też chodzi na tym cudnie.
Fakt, może sam jestem trochę zawiedziony, ale swoje posty (mówię tu w swoim imieniu) traktuję w ramach zwykłego feedbacku, czyli informacji zwrotnej dla Twórców, że w niektórych wypadkach jest jednak coś nie tak. Mam po prostu nadzieję, że będą w stanie to poprawić i trzymam za to kciuki. Jeżeli nikt im o takich niedociągnięciach nie powie, to nigdy nie zwrócą na to uwagi, bo będą przekonani, że wszystko gra.
Bo kwestii tego, że nie będzie im się chciało tego poprawiać (i skupią się nad czymś innym) nie biorę w ogóle pod uwagę. Gdyby nie mieli chęci zrobienia tego jak najlepiej, to Vampire w ogóle by nie powstał. Osobiście bardzo szanuję osoby, które chcą w ogóle zrobić cokolwiek dla rozwoju (w tę czy inną stronę) "systemu".
Tak, karta nie jest czymś ukończonym, więc dlatego sam czekam na nowy, lepszy wsad. Dlatego też użyłem zwrotu, że "w chwili obecnej" Vampire nie nadaje się do renderów z FPU. Może kiedyś będzie inaczej?
07.09.2017 19:54
[#634]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@jubi, post #632
Co do wynikow testow to ktos powinien sprawdzic czy filesystem robi roznice w tescie na tym samym sprzecie. Czyli ffs, pfs, sfs, bo przy dlugich plikach filesystem robi roznice. Potem czy Oxypatcher robi roznice (czyli bez i z). Potem jeszcze wersje 68040/68060 library. A na koniec biblioteki matematyczne emulujace fpu, choc to akurat nie powinno miec zadnej wiekszej roznicy, bo uzywanie tych bibliotek jest bez wiekszego sensu dla programu w wersji FPU. Minimum 3 dodatkowe i dosc wolne instrukcje sa wykonywane, move.l (ladowanie bazy biblioteki), jsr (skok do procedury w bibliotece) i rts (wyjscie z procedury). A co do emulacji przez softFPU to kazda taka emulacja to jest przelaczenie sie CPU w tryb nadzorcy, wiec nie dziwne ze sa lagi. Dlatego bardzo dobry procesor nie powinien niczego zewnetrznie emulowac, bo to jest zlo. Choc akurat w przypadku Vampire2 problemem jest brak miejsca w FPGA wiec to mozna zrozumiec, i ja to rozumiem. A co do wynikow testow w SysInfo to nawet jakby one osiagnely lub przebily szybkosc 68040FPU (w co watpie), to i tak dalej to bedzie wolniej niz na 68040 z FPU, bo w takim tescie 100% mocy Apollo CPU jest zuzywane na emulacje FPU, czyli zostaje 0% mocy na obsluge normalnego kodu, a w 68040 i 68060 CPU pracuje rownolegle z FPU. Powinien byc jakis test na uzywanie CPU i FPU rownoczesnie, wtedy wynik mozna byloby porownac.
07.09.2017 22:03
[#635]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@Don_Adan, post #634
Nie do końca FPU i CPU pracują równolegle, bo choć to dwie osobne jednostki to mają wiele "powiązań" niemniej z tego co kojarzę FPU nie pobiera danych z pamięci - to wszystko musi załatwić mu CPU (czyt. nawet przy 100% robocie FPU i tak ALU/AGU w CPU mają co robić co może mieć znaczenie jeśli jest emulacja i trzeba przełączać się między emulowanym FPU i jego rejestrami, a rzeczywistym CPU i jego rejestrami).
08.09.2017 00:32
[#636]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@abcdef, post #635
Sa zaleznosci pomiedzy CPU i FPU i czasami CPU musi czekac az komenda FPU sie wykona. Ale np. jest mnozenie z uzyciem FPU, to o ile nastepna komenda nie jest komenda FPU to procesor moze wykonac ja w tym samym czasie. Przy emulacji FPU nie ma takiej szansy, bo procesor wykonuje emulacje FPU wtedy.
08.09.2017 12:12
[#639]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@jubi, post #638
BTW, mógłbyś odpalić Jubimark na X5000 w LW 3.5? Ciekawe jak sie prezentuje sprawność emulacji 68k w porównaniu do G5.
jesli brakuje ci testerow to moze zapytaj tlosm, ma g5 i x5k, jest fanem benczmarkowania i emulacji:
http://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=42094&forum=33&start=60&viewmode=flat&order=0
08.09.2017 13:25
[#641]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@jubi, post #640
Już jest taki wątek, Gunnar już wczoraj na ten konkretny temat się wypowiedział:
http://www.apollo-core.com/knowledge.php?b=4¬e=5931&order=&x=11
http://www.apollo-core.com/knowledge.php?b=4¬e=5931&order=&x=11
08.09.2017 14:02
[#643]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@jubi, post #642
Zajrzałem tam, ale z tego co widać na pierwszy rzut oka nadal zaklina rzeczywistość. Poczekamy z rok, zobaczymy.
Faktycznie, Gunnar wypowiada sie dosc dziwnie. Jego argumenty tez do mnie nie trafiaja bo:
1. Uzytkownicy testuja najnowsza wersje jaka jest dla nich dostepna
2. Rownie dobrze mozna by zarzucic Gunnarowi ze swoje obrazki robi za pomoca jakiegos "SysInfo Screenshot Generator" w ktorym tylko wpisuje nowe liczby.
Albo wypuszcza sie wersje softu chocby i w fazie wczesnej (z bugami, powolna, wiechliwa) i liczy z tym ze uzytkownicy przetestuja i wydadza jakas tam opinie, albo trzyma sie wszystko w szufladzie i co tydzien szumnie zapowiada ze juz za miesiac albo dwa (no najpozniej na gwiazdke, mooooze na wielkanoc) bedzie cudnie i szybko, a na razie macie screenshota i zamknijcie geby.
08.09.2017 14:20
[#645]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@skipp, post #628
PS. Z tym wierszem #16 coś mi tu nie gra. HSMathLibs patchuje funkcje bibliotek matematycznych i wykorzystuje FPU. Nie ma wersji HSMathLibs, która działa BEZ FPU. Tym samym nawet przy odpaleniu wersji bez ".fp" LightWave, FPU będzie wykorzystany. Czy można prosić o wynik LC060? :)
Jest na forum ktoś z LC060? A jeśli nie, to może da się ustawić jakiś bit w pamięci i oszukać biblioteki matematyczne, że FPU jest nieobecne? W jaki sposób Amiga melduje obecność FPU w systemie?
08.09.2017 14:21
[#646]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@mschulz, post #643
OK....
To po kolei.
Screenshotów akurat Gunnar nie wykonuje. Robią to testerzy i deweloperzy zaangażowani w Apollo Core.
femu 0.10 (SoftFPU) został wypuszczony przez Jari Eskelinen'a, a nie Gunnara. Napisał dosłownie, cyt. "Do not expect performance and good compatibility though...", a w readme napisane jest, co następuje:
"Femu is a software based fpu emulator for Amiga's without a real FPU. Please be aware that software emulation is always much slower than real deal nor is compatibility perfect. YMMV, no guarantees, be happy if
something actually works."
I właśnie w tym celu był wypuszczony - do testów. Ilu z userów napisało jakikolwiek feedback do autora? Wieszanie psów na Gunnarze za jego styl wypowiedzi to nie jest feedback (i nie ten adres zwrotny).
I pomóż mi proszę zrozumieć w czym jest problem - Apollo Team codziennie daje jakiś raport z postępów prac. Tylko malkontenci zawsze będą się doszukiwać dziury w całym. Gdyby była totalna cisza pomiędzy kolejnymi rdzeniami - byłoby źle. Gdy codziennie pojawia się jakiegoś rodzaju raport ze źródła - też źle. Odechciewa się robić czegokolwiek :/
To po kolei.
Faktycznie, Gunnar wypowiada sie dosc dziwnie. Jego argumenty tez do mnie nie trafiaja bo:
1. Uzytkownicy testuja najnowsza wersje jaka jest dla nich dostepna
2. Rownie dobrze mozna by zarzucic Gunnarowi ze swoje obrazki robi za pomoca jakiegos "SysInfo Screenshot Generator" w ktorym tylko wpisuje nowe liczby.
Screenshotów akurat Gunnar nie wykonuje. Robią to testerzy i deweloperzy zaangażowani w Apollo Core.
Albo wypuszcza sie wersje softu chocby i w fazie wczesnej (z bugami, powolna, wiechliwa) i liczy z tym ze uzytkownicy przetestuja i wydadza jakas tam opinie, albo trzyma sie wszystko w szufladzie i co tydzien szumnie zapowiada ze juz za miesiac albo dwa (no najpozniej na gwiazdke, mooooze na wielkanoc) bedzie cudnie i szybko, a na razie macie screenshota i zamknijcie geby.
femu 0.10 (SoftFPU) został wypuszczony przez Jari Eskelinen'a, a nie Gunnara. Napisał dosłownie, cyt. "Do not expect performance and good compatibility though...", a w readme napisane jest, co następuje:
"Femu is a software based fpu emulator for Amiga's without a real FPU. Please be aware that software emulation is always much slower than real deal nor is compatibility perfect. YMMV, no guarantees, be happy if
something actually works."
I właśnie w tym celu był wypuszczony - do testów. Ilu z userów napisało jakikolwiek feedback do autora? Wieszanie psów na Gunnarze za jego styl wypowiedzi to nie jest feedback (i nie ten adres zwrotny).
I pomóż mi proszę zrozumieć w czym jest problem - Apollo Team codziennie daje jakiś raport z postępów prac. Tylko malkontenci zawsze będą się doszukiwać dziury w całym. Gdyby była totalna cisza pomiędzy kolejnymi rdzeniami - byłoby źle. Gdy codziennie pojawia się jakiegoś rodzaju raport ze źródła - też źle. Odechciewa się robić czegokolwiek :/
08.09.2017 14:39
[#647]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@jubi, post #645
Jest na forum ktoś z LC060? A jeśli nie, to może da się ustawić jakiś bit w pamięci i oszukać biblioteki matematyczne, że FPU jest nieobecne? W jaki sposób Amiga melduje obecność FPU w systemie?
Wystarczy nawet na pełnym 060:
a) użyć wersji integer Lightwave bez ".fp"
b) użyć oryginalnych bibliotek 37/38/39.x math#?.library
c) nie patchować mathffp (np. narzędziem ffppatch, które też wykorzystuje FPU)
Moje wyniki integer z 060@50 niebawem.
08.09.2017 14:54
[#648]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@skipp, post #647
b) użyć oryginalnych bibliotek 37/38/39.x math#?.library
Jesteś pewien, że one nie korzystają z FPU, gdy jest dostępne? W sumie ktoś, kto ma 68030 z 68882 mógłby zrobić eksperyment - wyjąć FPU fizycznie i sprawdzić, czy jest różnica.
Ostatnia aktualizacja: 08.09.2017 14:55:43 przez jubi
08.09.2017 15:14
[#649]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@Don_Adan, post #634
Dlatego bardzo dobry procesor nie powinien niczego zewnetrznie emulowac, bo to jest zlo. Choc akurat w przypadku Vampire2 problemem jest brak miejsca w FPGA wiec to mozna zrozumiec, i ja to rozumiem.
Ja nie do końca rozumiem
. Ale było to już tutaj wałowane, Gunnar podejmuje decyzje i nic nam do tego... moje zdanie jest takie, że skoro miał być najlepszy i najszybszy na świecie procesor 68K, to trzeba wpierw było się skupić na zrobieniu tego procesora, wraz z FPU. Zamiast tego jest AMMX oraz OCS i AGA... a na FPU miejsca brak .
Dlatego ja mam nadzieję, że Vampir się ustabilizuje w dobrym kierunku, na razie czekam i nie kupuję... Niby V4 ma mieć większe FPGA w którym zmieści się FPU - ale według zapowiedzi, FPU miało być już w V2...
Vampire V2 niemalże zamówiłem, teraz cieszę się, że tego nie zrobiłem, bo zostałbym na tzw. lodzie - z wykastrowanym Vampirem bez szans na pełnoprawne FPU, a z wbudowanym ECS i AGA, na którym mi nie zależało.
Dlatego też poczekam z Vampire 4 na rozwój wypadków. Znów jest obietnica najszybszego 68K z FPU... a może po drodze Gunnarowi się odwidzi i zamiast FPU wstawi tym razem nie SAGA tylko Hyper-AGA i co wtedy zrobimy ? Nic.
Ostatnia aktualizacja: 08.09.2017 15:16:49 przez APair
Ja nie do końca rozumiem
. Ale było to już tutaj wałowane, Gunnar podejmuje decyzje i nic nam do tego... moje zdanie jest takie, że skoro miał być najlepszy i najszybszy na świecie procesor 68K, to trzeba wpierw było się skupić na zrobieniu tego procesora, wraz z FPU. Zamiast tego jest AMMX oraz OCS i AGA... a na FPU miejsca brak .Dlatego ja mam nadzieję, że Vampir się ustabilizuje w dobrym kierunku, na razie czekam i nie kupuję... Niby V4 ma mieć większe FPGA w którym zmieści się FPU - ale według zapowiedzi, FPU miało być już w V2...
Vampire V2 niemalże zamówiłem, teraz cieszę się, że tego nie zrobiłem, bo zostałbym na tzw. lodzie - z wykastrowanym Vampirem bez szans na pełnoprawne FPU, a z wbudowanym ECS i AGA, na którym mi nie zależało.
Dlatego też poczekam z Vampire 4 na rozwój wypadków. Znów jest obietnica najszybszego 68K z FPU... a może po drodze Gunnarowi się odwidzi i zamiast FPU wstawi tym razem nie SAGA tylko Hyper-AGA i co wtedy zrobimy
? Nic.Ostatnia aktualizacja: 08.09.2017 15:16:49 przez APair
08.09.2017 15:18
[#650]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@skipp, post #646
Screenshotów akurat Gunnar nie wykonuje. Robią to testerzy i deweloperzy zaangażowani w Apollo Core.
Domyslam sie, pozwolilem sobie na niskich lotow zarcik za ktory przepraszam :)
femu 0.10 (SoftFPU) został wypuszczony przez Jari Eskelinen'a, a nie Gunnara.
...
I właśnie w tym celu był wypuszczony - do testów. Ilu z userów napisało jakikolwiek feedback do autora?
Krzysztof Wojteczek wrzucil feedback na forum (watek ktory sam wskazales). Moze nie bezposrednio do autora, moze zrobil to nie dosc profesjonalnie. Pomijajac wydajnosc (tej nie mozna oczekiwac, zgadzam sie z tym w zupelnosci) zwrocil uwage na "dylatacje czasu" w swojej amidze ktora koreluje z intensywnoscia uzycia FEMU. Gdybym byl Jarim to raczej taka uwage bym sobie odnotowal. Ale to nie Jari na wypowiedz Krzysztofa zareagowal a Gunnar i do tego sie odnosze.
A Gunnar zaczal od zapytania po co w ogole testowal i dlaczego przedstawia wersje alpha FEMU w zlym swietle: "So what intention do you have bashing an early pre-alpha release?"
Nastepnie postawil hipoteze odnosnie niewlasciwego przygotowania testu i zalozyl ze Krzystof faktycznie popelnil te bledy. Ma tez za zle Krzystofowi ze w ogole zrobil jakis test: "And first thing you do (because you can) is doing benchmarks on the known pre-alpha slow version to show in charts that its not fast an you run around and post these results."
To jak, Apollo Team czy tez Jari oczekuja jakiegokolwiek feedbacku czy tez trzeba do nich podchodzic ostroznie jak do jajka?
A na koniec odniose sie jeszcze do tego co Jubi nazwal zaklinaniem rzeczywistosci. Gunnar napisal do Krzysztofa optymistycznie: "You know yourself that FEMU will be magnitudes faster when fully speed tuned."
Tez lubie czasem cos zapowiedziec i tez mi sie zdarzaja obietnice bez pokrycia wiec patrze na to stwierdzenie z przymruzeniem oka. Ale jednak, "will be magnitudes faster" sugeruje ze FEMU bedzie w przyszlosci szybsze o wiecej niz jeden rzad wielkosci (liczba mnoga: magnitudes). Traktujac ta zapowiedz na serio zakladalbym ze gotowe FEMU osiagnie wydajnosc w okolicach 400 MFLOPSow (2 rzedy wielkosci w porownaniu do obecnych ~4 MFLOPsow) albo wiecej.
Tak sobie mysle ze w sumie o to Jubiemu chodzilo :)
Odechciewa się robić czegokolwiek :/
A to w amiswiatku nie nowosc przeciez, cytujac klasyka "Byl czas przywyknac przecie". Tez tak mialem; za kazdym razem jak cokolwiek na AROS-a wypuscilem dostawalem cale mnostwo porad (zaczynajacych sie od "musi" albo "powinien") na temat tego jak mam spozytkowac swoj wolny czas :)
08.09.2017 15:35
[#651]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@mschulz, post #650
A na koniec odniose sie jeszcze do tego co Jubi nazwal zaklinaniem rzeczywistosci. Gunnar napisal do Krzysztofa optymistycznie: "You know yourself that FEMU will be magnitudes faster when fully speed tuned."
(...) Ale jednak, "will be magnitudes faster" sugeruje ze FEMU bedzie w przyszlosci szybsze o wiecej niz jeden rzad wielkosci (liczba mnoga: magnitudes). Traktujac ta zapowiedz na serio zakladalbym ze gotowe FEMU osiagnie wydajnosc w okolicach 400 MFLOPSow (2 rzedy wielkosci w porownaniu do obecnych ~4 MFLOPsow) albo wiecej.
Ja akurat ten argument rozumiem inaczej - załóżmy, że femu 0.10 ma 1 MFlops. Jeśli femu "final edition" będzie miał co najmniej 2 MFlops (a jestem pewien, że będzie to o wiele wyższa liczba), to już będzie 2x więcej, a więc "2 magnitudes"? Myślę, że to kwestia tłumaczenia / interpretacji.
08.09.2017 16:48
[#652]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@mschulz, post #650
Ja również się tam wcisnąłem w wątek i zaproponowałem, żeby spróbowali wstawić pełny FPU i zrezygnować z jakiejś innej rzeczy. To FPGA, jeśli komuś zależy na FPU, to dlaczego nie zmienić konfiguracji i wywalić część rzeczy z SAGA i wstawić FPU? Pożyjemy, zobaczymy.
Co do Gunnara to problemem nie jest feedback, tylko sposób w jaki ludzie to piszą: "eeeee, gó#$%, wiesza się, nie działa, nie tak miało być, to działać nie może, nie da się" i to wszystko z takimi pretensjami. FPU i soft FPU są rozwijane, to nie wersja użytkowa a wrzucona przez Jari'ego wersja pre alfa. Tak dla picu na razie. Gunnar zresztą dał do zrozumienia, żeby nie upubliczniać femu do czasu aż nie zacznie to w miarę działać, bo zaraz fala krytyki wylewa się na nich zamiast konstruktywnej rozmowy o rezultatach.
Co do Gunnara to problemem nie jest feedback, tylko sposób w jaki ludzie to piszą: "eeeee, gó#$%, wiesza się, nie działa, nie tak miało być, to działać nie może, nie da się" i to wszystko z takimi pretensjami. FPU i soft FPU są rozwijane, to nie wersja użytkowa a wrzucona przez Jari'ego wersja pre alfa. Tak dla picu na razie. Gunnar zresztą dał do zrozumienia, żeby nie upubliczniać femu do czasu aż nie zacznie to w miarę działać, bo zaraz fala krytyki wylewa się na nich zamiast konstruktywnej rozmowy o rezultatach.
08.09.2017 18:51
[#655]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@kwaku85, post #652
Opcjonalne wersje wsadu sa lepsze. Ale Gunnar tez przesadza. Mi sie nie chce tam pisac. Ostatnio podrasowal Apollo Core i SysInfo pokazuje 160 MIPS dla 80MHz co jest bardzo dobrym rezultatem. Ale on twierdzi, ze powinno byc 320 MIPS, a nie 160 MIPS. Co jest oczywista bzdura, bo to jest wtedy predkosc maksymalna danego CPU a nie przecietna. Wedlug metody Gunnara to takie 68060 50 MHz ma wtedy 100 MIPS, a 68000 7 MHz 1.75 MIPS. Oczywiscie da sie napisac procedure, ktora osiagnie ponad 300 MIPS dla Apollo Core 80 MHz, czy ponad 1.5 MIPS dla 68000 7 MHz tylko taka procedura raczej nic sensownego nie bedzie robic. No ale MIPSy beda fajnie wygladac wtedy.
08.09.2017 19:19
[#656]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@Don_Adan, post #655
Mr. Gunar nie myli się i ma rację. Serio. Sysinfo to b.kiepski test i nie wykorzystuje należycie superskalarności 080, to tak jakby jechać na OGL 1.1 używając GTX Titan, trochę bez sensu, nieprawdaż, nie jest to miarodajne, podobnie jest z Sysinfom który nie poda prawidłowej liczby mipsów dla 080. MIPS to ilość instrukcji wykonanych w jednej sekundzie, a dokładniej to będzie średnia z pętli kodu testowego, który w sysinfo jest nieprzystający do 060 i do 080. Twórcy 080 w fpga raczej nie mogą pozwolić sobie na rozbudowane speculative i outoforder, ale mogą superscalar.
08.09.2017 20:34
[#657]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@sigma2pi, post #656
Nie ma racji niestety, chyba zaden kompilator nie tworzy kodu dla 68060 czy 68080. Kompilowany kod na 68060 to raczej na pewno jest tylko kod bez instrukcji ktorych 68060 nie obsluguje, a nie ze instrukcje sa w odpowiedniej kolejnosci wykonywane. Do tego dochodza instrukcje ktore wykonuja sie dluzej, jak mnozenie czy dzielenie, nie znam dokladnych timingow 68080, a takich instrukcji jest wiecej. A mnozenie i dzielenie jest bardzo czesto uzywane przez kompilatory. Poogladaj sobie przyklady recznej optymalizacji kodu przez Gunnara w jego przykladach, nigdy nie bylo tam takiego kodu, ktory by wykonywal 4 instrukcje na 1 cykl, gora 2.5 przecietna chyba byla.
08.09.2017 21:12
[#658]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@Don_Adan, post #657
Do takich benchmarków nie używa się kodu z kompilatora, bo kompilatory zazwyczaj produkują kod odbity w przysłowiowym krzywym zwierciadle - z małymi wyjatkami, tylko wstawek asm. Sysinfo został napisany w asm, ale dla procesora 68000 i jest dla tego procesora najbardziej miarodajny. Jeżeli faktycznie 080 może wykonać do 4 instr/cykl to faktycznie uzyska magiczne 320mips +-10% przy 80Mhz (przy całkowitym zamrożeniu OS, IRQ), a skoro uzyskał 160mips w teście sysinfo, czyli wykonuje średnio do 2 instr./cykl bez spec. opt. (także każdy kod 68000, to dobra wiadomość) to dla spec. opt. kodu testowego dla 080 owe 300mips jest chyba jednak w zasięgu. Nie dowiemy się dopóki sam Mr. Gunar nie przedstawi nam swojego kodu do mierzenia Mipsów dla 080, zamiast posługiwać się niemiarodajnym Sysinfo dla 080 :). Kwestia statystycznie % udziału poszczególnych instr. nie będziemy rozważać, ale chyba nie sądzisz jakoby MUL lub DIV były używane częściej niż MOVE, LEA, ADD, SUB, LSR itd.itp. w kodzie przeciętnego programu, choć należałoby uwzględnić jeszcze wyjątkowo złożone tryby adresowania 68k, w końcu to pełnoprawny CISC.
Ostatnia aktualizacja: 08.09.2017 21:12:19 przez sigma2pi
Ostatnia aktualizacja: 08.09.2017 21:12:19 przez sigma2pi
08.09.2017 22:14
[#659]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@sigma2pi, post #658
Chciałem odnieść się jeszcze do tego nieszczęśnego FEMU i LW. Moim zdaniem nie jest to rozwiązanie docelowe i przeznaczone do takich testów jak LW. Bedzie FEMU rozwijane itd., bo ma swoją rację bytu, ale jak sądzę prawdziwa implementacja obliczeń FP w Vampire dopiero jest do zrobienia z myslą właśnie o profesjonalnym oprogramowaniu korzystającym intensywnie ze złożonych obliczeń FP. AmigaOS jest wyjatkowym spośród wszystkich systemów, dlaczego, od wersji 1.0 do 3.1 nie potrzebuje do działania FPU, baa, nie potrzebuje procesora lepszego niż MC 68000. Ten procesor był tak doskonałym CISC, że nic lepszego nie potrzeba, istotniejsze jest nawet MMU, niż FPU. Obliczenia FP realizowane są z użyciem bibliotek math...library. W tym tkwi cała magia wszelkich patcherów ala Oxy. Wyszukują w locie.... takie wywołania i zastępują własnym kodem, tutaj korzystającym z instr. koprocesora FPU 881/2/040-60fpu. Na Vampire też można pójść tym przetartym szlakiem i stworzyć coś ala oxypatchera właściwie vamppatchera, tylko nie z odwołaniami do ciągu instr. koprocesorów MC tylko bezpośrednio implementacji w FPGA poszczególnych wywołań funkcji math....library, same math...library też można tak patchować już na twardo, bo niewiele jest programów takich jak LW tak instensywnie korzystających z obl. FP, gdzie można zyskać te kilkanaście % patchujac bezpośrednio kod programu :). FEMU jak napisałem ma swoją rację bytu tylko dla programów mających w swoim kodzie bezpośrednio instr. FPU i bedzie z czasem coraz lepszy, ale niekoniecznie jest to rozwiązanie lepsze, dlatego nikogo nie powinny dziwić ciągle powstające wersje programów noFPU z wywłaniami math...library na AOS, to po prostu wyższy poziom abstrakcji, wyższy niż proste instr. FPU, coś jak współczesne frameworki itp.
Tak samo należy myśleć o implementowaniu innych funkcjonalności np: po co męczyć szefa 080 dekodowaniem mp3/aac,h263/4/5 itd.itd. skoro i tak z tak małym zegarem temu nie sprosta lub się zwyczajnie zarźnie, kiedy można daną funkcjonalność zaimplementować niemal na poczekaniu w FPGA, wykonywaną równolegle i asynchronicznie, mając oczywiście do tego przestrzeń w FPGA, to jedna z zalet FPGA. Zaimplementowana funkcjonalność kiedy stanie się niepotrzebna w FPGA lub przestarzała lub coś innego, wystarczy przenieść lub wrócić do wersji soft 080, powiem lepiej, można posłużyć się tutaj tak gotowymi i popularnymi bibliotekami jak ffmpeg itp.
Z góry dzieki jak komuś chciało się czytać moje uwagi, sam nie wiem po co to piszę
Ostatnia aktualizacja: 08.09.2017 22:18:03 przez sigma2pi
Tak samo należy myśleć o implementowaniu innych funkcjonalności np: po co męczyć szefa 080 dekodowaniem mp3/aac,h263/4/5 itd.itd. skoro i tak z tak małym zegarem temu nie sprosta lub się zwyczajnie zarźnie, kiedy można daną funkcjonalność zaimplementować niemal na poczekaniu w FPGA, wykonywaną równolegle i asynchronicznie, mając oczywiście do tego przestrzeń w FPGA, to jedna z zalet FPGA. Zaimplementowana funkcjonalność kiedy stanie się niepotrzebna w FPGA lub przestarzała lub coś innego, wystarczy przenieść lub wrócić do wersji soft 080, powiem lepiej, można posłużyć się tutaj tak gotowymi i popularnymi bibliotekami jak ffmpeg itp.
Z góry dzieki jak komuś chciało się czytać moje uwagi, sam nie wiem po co to piszę
Ostatnia aktualizacja: 08.09.2017 22:18:03 przez sigma2pi
09.09.2017 09:02
[#660]
Re: Nadchodzi Vampire Core GOLD3 (integracja Paula/ECS/AGA z HDMI)
@sigma2pi, post #659
dlatego nikogo nie powinny dziwić ciągle powstające wersje programów noFPU z wywłaniami math...library na AOS, to po prostu wyższy poziom abstrakcji, wyższy niż proste instr. FPU, coś jak współczesne frameworki itp.
Od takiego trendu sie odchodzi w normalnym swiecie. Popatrz na linuksowe dystrybucje dla procesorow ARM. Najpierw byly wersje softfp, bardzo podobne do amigowego podejscia. Zadnych odwolan do fpu, kompilator generowal wywolania do fukcji w bibliotece matematycznej. Ta zas mogla byc w kilku wersjach: dla procesora bez fpu jak i dla procesora z prawdziwym fpu obecnym na pokladzie.
Od wielu lat ta wersja ABI jest jednak na wymarciu, wyparla ja wersja armhf, gdzie fpu jest wykorzystywany bezposrednio. Zgadnij, dlaczego?