20.09.2016 18:57
[#68]
Re: Vampie 500/2000
pisklak
autor wątku
autor wątku
@Ocelot, post #67
Widzę ze zazwyczaj test core Apollo x13 165 MIPS trzyma się całkiem nieźle w porównaniu nawet do UAE-NoJIT 
. Czy jest to dobry wynik każdy musi odpowiedzieć sobie sam.
W każdym razie to pokazuje jak czasami "drobna" zmiana w CPU potrafi przyśpieszyć pewne rzeczy całkiem dobrze.
. Czy jest to dobry wynik każdy musi odpowiedzieć sobie sam.W każdym razie to pokazuje jak czasami "drobna" zmiana w CPU potrafi przyśpieszyć pewne rzeczy całkiem dobrze.
22.09.2016 09:44
[#75]
Re: Apollo CPU - dyskusja
pisklak
autor wątku
autor wątku
@recedent, post #70
OK jakoś zrobiłem ten test LAME. Użyłem tej wersji LAME,a ixemul zassałem z tąd.
Testowy plik to ten.. Domyślne parametry kodowania ("LAME020 plik"). Nie mam co prawda najnowszego wsadu, mam coś pomiędzy S9 a GOLD1, ale nie powinno to chyba aż tak mocno rzutować na wynik. Wynik raczej rewelacyjny nie jest zresztą - real time 29min45sec, play/cpu 0.0259x.
Można powiedzieć że akurat tym razem Vampirka nie błyszczy. To jest oczywiście bez FPU.
Ostatnia aktualizacja: 22.09.2016 09:45:30 przez pisklak
Testowy plik to ten.. Domyślne parametry kodowania ("LAME020 plik"). Nie mam co prawda najnowszego wsadu, mam coś pomiędzy S9 a GOLD1, ale nie powinno to chyba aż tak mocno rzutować na wynik. Wynik raczej rewelacyjny nie jest zresztą - real time 29min45sec, play/cpu 0.0259x.
Można powiedzieć że akurat tym razem Vampirka nie błyszczy. To jest oczywiście bez FPU.
Ostatnia aktualizacja: 22.09.2016 09:45:30 przez pisklak
22.09.2016 10:40
[#77]
Re: Apollo CPU - dyskusja
pisklak
autor wątku
autor wątku
@Krashan, post #76
Pewnie tak.. tylko się obawiam że dobre porównanie z 060 może nie być wcale takie łatwe. Trzeba by wszystko FPU powyłączać - wszystkie OxyPatchery, biblioteki itp.... A i tak być może będzie wykorzystane FPU gdzieś. No ale ktoś może spróbować. Bo z FPU to przegra sromotnie, przynajmniej na dzień dzisiejszy.
22.09.2016 10:48
[#78]
Re: Apollo CPU - dyskusja
@pisklak, post #77
Pytanie, dlaczego uważasz że wyłączanie cyber/oxypatchera i nieładowanie bibliotek (domyślam się, że konkretnie chodzi ci o 68060.library) ma być uczciwsze? Czy któreś z tych softwareowych rozwiązań powoduje że przychodzi krasnoludek i zamienia 060 na karcie na 070? O ile mi wiadomo - nic takiego się nie dzieje, to cały czas fizycznie ten sam procek. Skoro przegrywa w jakimś zakresie, to albo trzeba to poprawić (jeśli jest możliwość) albo przyjąć na klatę, a nie kombinować.
22.09.2016 11:15
[#81]
Re: Apollo CPU - dyskusja
@baderman, post #80
No właśnie akurat napisałem to w jego obronie - w sensie takim, że Apollo musi sobie radzić bez żadnych dodatkowych bibliotek, podczas gdy 68060 bez swojej "software'owej" strony jest równie nieporadny po stronie FPU. Owszem, jest cholernie szybki w porównaniu do 68882 taktowanego tym samym zegarem, ale sporej części instrukcji po prostu nie ma bez emulacji (sic). Dla przypomnienia wkleję tylko ten obrazek (z oficjalnej instrukcji obsługi MC68060):
Więc rozumiem, co pisklak miał na myśli. Jestem przekonany, że LAME w ogóle nie ruszy bez obecności 68060.library, ponieważ kodowanie mp3 bazuje mocno na SIN/COS (jak mniemam). I dopiero wtedy będziemy mieli sprawiedliwe porównanie, prawda? :)
BTW. "68060 FPU is not pipelined and is therefore up to three times slower than the Pentium in floating point applications." - i tym aspekcie widzę szansę na dobrą implementację FPU w Phoenix/Apollo. A patrząc na postępy Gunnara w tej materii chyba mogę być o to spokojny :)
Więc rozumiem, co pisklak miał na myśli. Jestem przekonany, że LAME w ogóle nie ruszy bez obecności 68060.library, ponieważ kodowanie mp3 bazuje mocno na SIN/COS (jak mniemam). I dopiero wtedy będziemy mieli sprawiedliwe porównanie, prawda? :)
BTW. "68060 FPU is not pipelined and is therefore up to three times slower than the Pentium in floating point applications." - i tym aspekcie widzę szansę na dobrą implementację FPU w Phoenix/Apollo. A patrząc na postępy Gunnara w tej materii chyba mogę być o to spokojny :)
22.09.2016 11:21
[#82]
Re: Apollo CPU - dyskusja
pisklak
autor wątku
autor wątku
@baderman, post #80
Panowie - bardziej chodzi mi o porównanie wykonywania kodu nofpu. Jasne że jak zaczniecie porównywać procki i kod z FPU i nofpu to jeden będzie wyraźnie szybszy.
I spokojnie jestem w stanie zaakceptować że 060 z FPU jest dużo szybsze w tym LAME niż Vampirka, świadomym będąc z czego ta przewaga 060 wynika. Po prostu powiedzmy że chciałbym "wyłączyć FPU" w tym teście żeby zobaczyć bardziej miarodajne wyniki porównania prędkości jednostek stałoprzecinkowych.
PS. Powtórzy ktoś mój test na 060 ?
Ostatnia aktualizacja: 22.09.2016 11:24:49 przez pisklak
I spokojnie jestem w stanie zaakceptować że 060 z FPU jest dużo szybsze w tym LAME niż Vampirka, świadomym będąc z czego ta przewaga 060 wynika. Po prostu powiedzmy że chciałbym "wyłączyć FPU" w tym teście żeby zobaczyć bardziej miarodajne wyniki porównania prędkości jednostek stałoprzecinkowych.
PS. Powtórzy ktoś mój test na 060 ?
Ostatnia aktualizacja: 22.09.2016 11:24:49 przez pisklak
22.09.2016 11:49
[#84]
Re: Apollo CPU - dyskusja
@pisklak, post #82
@Skipp: wiem to o czym piszesz. Natomiast mnie chodziło o to, że jak porównujemy - to wszystko w maksymalnej sprawności. Jeśliby apollo potrzebowało jakiegoś dodatkowego softu do pełnej wydajności, to w takim porównaniu też powinno być wzięte pod uwagę - to był cel mojego posta. Przy czym chyba się nie zrozumieliśmy (czy raczej ja nie zrozumiałem na początku), bo jak @Pisklak sprecyzował - chodziło mu o porównanie ALU vs ALU a nie cały klocek vs cały klocek :).
22.09.2016 12:40
[#85]
Re: Apollo CPU - dyskusja
@baderman, post #84
Tu nawet nie chodzi o porównanie ALU vs ALU, bo jak pisklak pisał chodzi i przyspieszenie wykonywania krótkich pętli. Tak - nie dość że pętli, to jeszcze krótkich... zapewne długie pętle nie skorzystają na tym nowym ficzerze. Podejrzewam, że to jakiś rodzaj małego bufora (coś jak w 68010). A test napisano tak, aby tego rodzaju pętla tam występowała. LAME to zupełnie inna liga - złożony algorytm sporo korzystający z FPU. Ja byłbym bardziej ciekaw wyników ze stałoprzecinkowych testów w AIBB.
Nowy ficzer zapewne da zauważalne przyspieszenie w pewnych programach, dla innych żadnego.
Ja przez cały czas uważam, że w Motoroli nie pracowali kretyni, i 68060, składający się z 2.500 000 tranzystorów, stanowi ówczesne State of the Art techniki procesorowej. I że trudno będzie prześcignąć 68060 w wydajności na takt zegara, stąd główny efekt będzie wynikał z możliwości zastosowania szybszego zegara, czy możliwości zastosowania większej ilości cache. Szybka pamięć zapewne też da efekt.
A na 68060 potestuję wieczorem, być może nawet ten test skłoni mnie (wreszcie) do wypróbowania karty 68060 GBA przy 100 MHz.
Nowy ficzer zapewne da zauważalne przyspieszenie w pewnych programach, dla innych żadnego.
Ja przez cały czas uważam, że w Motoroli nie pracowali kretyni, i 68060, składający się z 2.500 000 tranzystorów, stanowi ówczesne State of the Art techniki procesorowej. I że trudno będzie prześcignąć 68060 w wydajności na takt zegara, stąd główny efekt będzie wynikał z możliwości zastosowania szybszego zegara, czy możliwości zastosowania większej ilości cache. Szybka pamięć zapewne też da efekt.
A na 68060 potestuję wieczorem, być może nawet ten test skłoni mnie (wreszcie) do wypróbowania karty 68060 GBA przy 100 MHz.
22.09.2016 13:12
[#86]
Re: Apollo CPU - dyskusja
@pisklak, post #75
Zrobilem taki test. Uzylem dokladnie tej samej wersji LAME020 co ty. Konfig Blizzard1260/66MHz.
LAME020
Dla porownania LAME060fpu
Ostatnia aktualizacja: 22.09.2016 13:15:20 przez Phibrizzo
LAME020
LAME 3.98.2 32bits (http://www.mp3dev.org/)
Using polyphase lowpass filter, transition band: 3903 Hz - 4000 Hz
Encoding plik.wav to plik.wav.mp3
Encoding as 8 kHz j-stereo MPEG-2.5 Layer III (10.7x) 24 kbps qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
758/758 (100%)| 15:26/ 15:26| 13:08/ 13:07| 0.0589x| 0:00Dla porownania LAME060fpu
LAME 3.98.2 32bits (http://www.mp3dev.org/)
Using polyphase lowpass filter, transition band: 3903 Hz - 4000 Hz
Encoding plik.wav to plik.wav.mp3
Encoding as 8 kHz j-stereo MPEG-2.5 Layer III (10.7x) 24 kbps qval=3
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
758/758 (100%)| 1:18/ 1:18| 1:06/ 1:06| 0.6986x| 0:00Ostatnia aktualizacja: 22.09.2016 13:15:20 przez Phibrizzo
22.09.2016 18:43
[#88]
Re: Apollo CPU - dyskusja
@pisklak, post #87
Wracajac do testow to ja proponuje test programem RiVa. Jest dostepny na aminecie z darmo tutaj:
link
Jedyny film o sensownej dlugosci w formacie MPEG1 jaki udalo mi sie znalezc:
link
Uruchamiamy program z parametrami: NOSOUND NORENDER VERBOSE
W przypadku 060 wynik jest nastepujacy:
Ostatnia aktualizacja: 22.09.2016 18:44:20 przez Phibrizzo
link
Jedyny film o sensownej dlugosci w formacie MPEG1 jaki udalo mi sie znalezc:
link
Uruchamiamy program z parametrami: NOSOUND NORENDER VERBOSE
W przypadku 060 wynik jest nastepujacy:
6.Workbench:> riva nosound norender verbose Video: 384x288, 23.976 fps Audio: <NONE> Number of frames played: 2014 Number of frames skipped: 783 Total number of frames: 2797 Total playback time: 116.6138 seconds. Average framerate: 23.9851 fps Displayed framerate: 17.2706 fps
Ostatnia aktualizacja: 22.09.2016 18:44:20 przez Phibrizzo
22.09.2016 21:01
[#89]
Re: Apollo CPU - dyskusja
@Phibrizzo, post #86
Ja z kolei wlasnie pogonilem taki test porownawczy miedzy A600 + Vampire 600 V2 a A1200 + Blizzard 1260/50. Obie karty ze 128MB FAST na pokladzie. Wyniki ponizej:
Vampire 600 V2 Black
Blizzard 1260/50
http://aminet.net/package/util/moni/bustest
Ot, ciekawostka :)
Vampire 600 V2 Black
c:bustest fast chip rom BusSpeedTest 0.19 (mlelstv) Buffer: 262144 Bytes, Alignment: 32768 ======================================================================== memtype addr op cycle calib bandwidth fast $08150000 readw 14.1 ns normal 142.2 * 10^6 byte/s fast $08150000 readl 20.3 ns normal 197.3 * 10^6 byte/s fast $08150000 readm 20.5 ns normal 195.4 * 10^6 byte/s fast $08150000 writew 14.9 ns normal 134.7 * 10^6 byte/s fast $08150000 writel 14.9 ns normal 269.0 * 10^6 byte/s fast $08150000 writem 15.6 ns normal 255.9 * 10^6 byte/s chip $00020000 readw 799.6 ns normal 2.5 * 10^6 byte/s chip $00020000 readl 1596.2 ns normal 2.5 * 10^6 byte/s chip $00020000 readm 1590.8 ns normal 2.5 * 10^6 byte/s chip $00020000 writew 793.3 ns normal 2.5 * 10^6 byte/s chip $00020000 writel 1581.1 ns normal 2.5 * 10^6 byte/s chip $00020000 writem 1580.8 ns normal 2.5 * 10^6 byte/s rom $00F80000 readw 14.1 ns normal 142.1 * 10^6 byte/s rom $00F80000 readl 20.3 ns normal 197.4 * 10^6 byte/s rom $00F80000 readm 20.4 ns normal 195.8 * 10^6 byte/s
Blizzard 1260/50
c:bustest fast chip rom BusSpeedTest 0.19 (mlelstv) Buffer: 262144 Bytes, Alignment: 32768 ======================================================================== memtype addr op cycle calib bandwidth fast $78660000 readw 66.5 ns normal 30.1 * 10^6 byte/s fast $78660000 readl 113.5 ns normal 35.2 * 10^6 byte/s fast $78660000 readm 111.7 ns normal 35.8 * 10^6 byte/s fast $78660000 writew 83.1 ns normal 24.1 * 10^6 byte/s fast $78660000 writel 164.0 ns normal 24.4 * 10^6 byte/s fast $78660000 writem 165.9 ns normal 24.1 * 10^6 byte/s chip $00028000 readw 1012.7 ns normal 2.0 * 10^6 byte/s chip $00028000 readl 1011.1 ns normal 4.0 * 10^6 byte/s chip $00028000 readm 1012.5 ns normal 4.0 * 10^6 byte/s chip $00028000 writew 908.3 ns normal 2.2 * 10^6 byte/s chip $00028000 writel 908.5 ns normal 4.4 * 10^6 byte/s chip $00028000 writem 908.8 ns normal 4.4 * 10^6 byte/s rom $00F80000 readw 67.3 ns normal 29.7 * 10^6 byte/s rom $00F80000 readl 112.3 ns normal 35.6 * 10^6 byte/s rom $00F80000 readm 110.1 ns normal 36.3 * 10^6 byte/s
http://aminet.net/package/util/moni/bustest
Ot, ciekawostka :)
22.09.2016 21:07
[#90]
Re: Apollo CPU - dyskusja
@skipp, post #89
Może ja to porostu tu zostawię: http://www.amigapodcast.com/2016/09/vampire-ii-amiga-600-gold-core-speed.html.