Tak sobie pomyślałem, że przydałby się tekst opisujący wszystkie "zady i walety" aktualnie dostępnego pod MorphOS sprzętu (ot, taki tutorial dla początkujących, zastanawiających się nad zakupem). Do takiego tekstu przydałyby się jednak moim zdaniem dodatkowe dane odnośnie prędkości (choćby pochodzące z moich benchmarków). Do kolekcji brakuje mi jeszcze eMaca. Zgłaszajcie się, chłopaki – to w zbożnym celu .
Komentarze:
Jak tylko znajdę chwilę obiecuję, że dodamy tam jeszcze MDD 1.42 a może ciut więcej jak uda mi się bydlę podkręcić.
EDIT: testy chyba trzeba robić na czystym systemie i z ramu np w przypadku 1wszego testu z mplayerem bo z włączonym owb, ircem, amigg mam gorszy wynik niż MDD 1.25…
W sumie to pisałeś do mnie o tym na gadaczu ppa, chętnie zrobię taki test, tylko podpowiedz jak to ugryźć
No to tak: Testów jest kilka. Zaczynamy od pierwszego (czyli test MPlayera):
Materiały i metody:
1. Teaser Harrego Pottera (dostępny na stronie, do której linkowałem) w formacie .mov 720p.
2. MPlayer, wersja podana na stronie (testy wykonywaliśmy na dwóch, jeśli chcesz mogę Ci podesłać konkretną, mam kilka do porównań).
3. Komputer z MorphOSem
Wykonanie:
1. Odpalamy "czysty" system (dobrze by było, gdyby był świeżo zainstalowany, ale może być świeżo zresetowany).
2. Przerzucamy film do Ram Disku
3. Otwieramy konsolę i (w miejscu gdzie siedzi nasz MPlayer) dajemy co następuje:
mplayer -quiet -nosound -benchmark RAM:HP6_Large.mov
Teraz MPlayer odegra film i wypluje wynik. Interesują nas wartości: VC, VO, Sys i Total Time (liczbowe, nie procentowe). Test możemy powtórzyć z 10 razy i spisać najlepszy wynik. Następnie można jeszcze zrobić test na fullscreenie, dodając do podanego wyżej stringa parametr -fs.
Na razie tyle, ale już wkrótce kolejne odcinki "złotej epoki balonowej".
A widzisz, mnie zmylił ten Work: i myślałem że testy robimy z twardego a nie ramu.
Tak po prawdzie to już nie pamiętam, czy część z tych testów nie była robiona z twardego (hence work:). Musiałbym powtórzyć benchmarki na Efice, ale ta jest aktualnie na wojażach
. Kto wie, może byłoby ciut szybciej?
W każdym razie na pewno testy DigiRollera i Lame szły z RAM:
Koszer – ja chętnie przetestuje eMaca G4 1.25GHz ale w późniejszym terminie, za dwa dni mam ślub.
Ulala, to gratulacje. Mnie ta wątpliwa przyjemność czeka w sierpniu ;D
Swój czyżby niechcący?
Ok, mplayer_new testniety, jak mozesz to tego old podeslij. Jutro zrobie jak wroce z nocki 🙂
eMac 1,25 Ghz
window:
BENCHMARKs: VC: 12.492s VO: 2.971s A: 0.000s Sys: 0.387s = 15.850s
fs:
BENCHMARKs: VC: 12.492s VO: 2.970s A: 0.000s Sys: 0.389s = 15.851s
Swoją drogą przydało by się zrobić zbiorczy zwięzły artykuł z testów z Twojej strony i umieścić na morphos.pl od czasu do czasu go uzupełniając o nowy sprzęt.
@kjb: Starą wersję znajdziesz tutaj.
Skoro tak dobrze idzie, to jedziemy dalej. Test Blendera.
Materiały i metody:
1. MorphOSowy Blender w wersji 2.46
2. Testowa scena (albo obydwie, tu akurat "NEW" i "OLD" odnoszą się do wersji sceny, a nie programu). Ponieważ scena "OLD" jest bardzo prosta, można wykonać tylko test "NEW" (czyli plik test.blend). Nie obrażę się jednak jeśli zrobicie też starą wersję testu. Na korzyść scenki "NEW" przemawia również to, że łatwo ją porównać z osiągami innych komputerów (w tym tych z OS4, ale nie tylko) – jest specjalna strona temu poświęcona.
Wykonanie:
1. Odpalamy "czysty" system (dobrze by było, gdyby był świeżo zainstalowany, ale może być świeżo zresetowany).
2. Włączamy Blendera (w miarę możliwości prosiłbym o 24 bit 1024×768, w ten sposób wszystkie sprzęty będzie można porównać na tych samych ustawieniach. Nie polecam zabawy w 16 bit, czy wyłączania zaawansowanego wyświetlania (chyba, że komuś inaczej nie pójdzie) – i tak niewiele to daje, a tylko zaciemni ewentualne porównania).
3. Wczytujemy wybraną scenę do Blendera (wciskamy F1, wybieramy ścieżkę do sceny i dajemy "Open File")
4. Wciskamy F12 i po przeliczeniu sceny spisujemy wynik w przeliczeniu na sekundy (uwaga, Blender podaje wynik w postaci minuty:sekundy.setne!). Operację możemy powtórzyć, odnotowując najlepszy czas z kilku prób.
Mój config to czysty eMac 1,25 Ghz 512 MB Ram.
Chyba ślepy jestem, że nie zobaczyłem twojego pierwszego wpisu.
Dziękuję
No, chłopaki, nie pozwólcie mi się powstrzymywać. Dawajta te wyniki z Blendera i jedziemy dalej.
P.S. Pozdrawiamy wszystkich przyszłych mężusiów. Wcale nie jest tak źle jak wieszczą Wam malkontenci, ALE! Po żeniaczce możecie mieć trochę mniej czasu, więc benchmarki wykonajcie już dziś
Hehe, mój eMac jest zamknięty w szafie, pokój w którym stał został "przerobiony" do błogosławieństwa. 🙂
Dziz…jeszcze 5 godzin…
Cóż, skoro waldiamiga bawi się w najlepsze (a w związku z tym jutro może być niekoniecznie w dobrej formie), to może kto inny podgoniłby w temacie Blendera? Sventevith? kjb?
A przy okazji: Posiada ktoś może tego "półoficjalnie" wspieranego eMaca 1.42?
Przepraszam, że tak długo ale nie mogłem wcześniej.
Blender NEW – 7:39:71 = 459.71
W artykule na wykresach przydały by się (tam gdzie to możliwe) wyniki OS4 i amigi klasycznej. Swoją drogą jakiś test pokazujący wydajność JIT 68k w MOS też by się przydał.
Wielkie dzięki za wynik.
Wyniki porównawcze oczywiście będą (tam gdzie takie porównanie ma sens i będę miał jakieś dane). Testem wydajności JIT są np. testy DigiRollera i LAME, wykonywane zarówno na binarkach pod 68k, jak i PPC, a także próby powównywania wydajności Trance z WinUAE JIT pod dość szybkim PC.
A skoro już przy tym jesteśmy, to jedziemy dalej:
Benoit:
Jest to test programu Benoit, jednego z przykładowych "demonstracji PowerUP" dokładanych do kart Blizzard i Cyberstorm. Dostępny na Aminecie.
Wykonanie:
1. Ustawiamy wielkość ekranu na 1024×768, 24 bit
2. Odpalamy program
3. Powiększamy okno wynikowe maksymalnie
4. Klikamy w "Calculate" i notujemy wynik. Tę operację możemy powtórzyć kilka razy i zanotować najlepszy wynik.
5. Zmieniamy "CPU" w ustawieniach na "68k" i powtarzamy krok 4. Zalecam zrobić wiecej powtórzeń obliczeń, dla pewności – czasem Trance "załapuje" dopiero za którymś razem. P.S. Priorytet Trance zostawiamy na domyślnym.
Wielkość ekranu na 1024×768, 24 bit
PPC: 0.27 sec
M68k: 1.58 sec
Dziękuję ponownie.
I zapraszam do wykonania kolejnego testu
Hmm… Kolejnym testem jest przekształcenie przykładowego pliku za pomocą ImageFX. Plik znajdziesz na stronie "Efika vs reszta świata", albo tutaj. Natomiast ImageFX? Hmm… A nie masz?
W każdym razie trzeba użyć efektu Distort/Sparkle i Distort/Spherize. Na domyślnych ustawieniach. Czas mierzymy (niestety) za pomocą stopera.
Nie mam ImageFX łamie się jaki program kupić ArtEffect, Photogenics czy ImageFX. Dlatego przydała by się baza z softem 68k i krótkimi recenzjami jak to działa z czym jest problem i jak to rozwiązać.
Daj następny test na oprogramowaniu ogólnie dostępnym.
Na szczęście ten problem łatwo jest obejść. Na OS4Depot dostępny jest bowiem ImageFX w wersji "Lite" (czyli "trójka" właśnie). Instalujesz go u siebie (tylko uważaj, żeby nie używać domyślnego installera od Geita – nie uda się. Użyj klasycznego installera pod 68k), a następnie wrzucasz w Modules/Loaders ten oto loader do JPEG (w wersji 68k, dołączone do tej wersji Lite loadery w wersji pod PPC coś nie chcą działać) i voila!
Ten instaler co tam jest prosi o klucz OS4 jak nie podam to wali błędem w następnym kroku. Jak odpaliłem bez instalacji to odpalił się ekran część okien i później freez.
Ale którym installerem instalujesz? Bo ten wbudowany w MorphOSa nie bangla.
No dobra, jak masz problemy z tym ImageFX to jedziemy dalej.
Personal Paint:
PPainta pobierasz z Aminetu, a także prefsy dostosowane do MorphOSa – chwilowo dostępne tutaj:
http://www.speedyshare.com/files/28552775/download/Startup%201.set
1. Odpalasz Personala
2. Próbujesz wczytać obrazek z poprzedniego testu
3. Notujesz ile zajmuje to Personalowi (tzn. ile zajmie wczytanie i konwersja 24 bitowego JPG na 8 bit).
Zastanawiam się, czy nie rzucić jeszcze jakiegoś "personalnego" testu na pełnoekranowy filtr na ten przykład, ale to może później.
Też masz kaszanke w obszarze rysowania oraz na toolbarze po odpaleniu ?
Nie (tzn. tylko na toolbarze). Na pewno użyłeś moich prefsów? Spróbuj wyłączyć PPainta i włączyć jeszcze raz – kaszanka na toolbarze powinna zniknąć.
Po załadowaniu prefsów od Ciebie zmienia się rozdzielczość oraz pojawia się kounikat, że ustawienia zadziałają po następnym uruchomieniu. Przy następnym uruchomieniu rozdziałkę mam nadal starą i kaszana nie znika do tego po kilku uruchomieniach PP potrafi zrobic freza systemu. Ale będę walczył dalej w wolnym czasie i powrócimy jeszcze do tego ImageFX jak uda się ogarnąć PP.
Daj następny test na oprogramowaniu ogólnie dostępnym.
mam oryginalny imagefx 4.5 studio z pluginami do morphosa/powerup, kupiony i sprowadzony ze stanów (wersja oryginalna bez pudelka, instrukcji). Kupilem dwie sztuki i jedna na razie w szufladzie lezy. Zainteresowany ?
A, to już wiem w czym rzecz. Nie wczytuj prefsów z poziomu programu (czyli z menu, albo przez F7), tylko podmień plik Startup_1.set w katalogu PPaint/Prefs (P.S. Po tym wszystkim będziesz musiał ręcznie wyedytować ścieżki do skryptów ARexxa – o ile będziesz chciał używać skryptów w PPaincie – do benchmarków akurat nie jest to potrzebne).
Zadziałało, tylko jak ja mam to zmierzyć nie mając stopera 😉
Zawsze można użyć telefonu komórkowego i stopera weń wbudowanego.
Nie wiem czy taki test jest miarodajny.
Testy dla PP:
Czasy które uzyskałem to 1.56, 1.66, 1.75, 2.0.2, 2.22.
Na pewno jest obarczony dużo większym błędem pomiaru (m.in. zależnym od Twojego refleksu), ale jakieś pojęcie daje.
Żeby nie tracić czasu jedziemy dalej z DigiRollerem.
1. Pobieramy program (w wersji MorphOS – z morphos-files.net, a w wersji 68k – ze strony APC&TCP)
2. Pobieramy przykładowy plik .DBM ze strony z benchmarkami
3. Otwieramy moduł w DigiRollerze
4. Przestawiamy gadżet "Wyjście dźwięku" na "test szybkości" i klikamy w "Start". Notujemy wynik (w postaci x, czyli podanej w ramce "Szybkość"). Test można wykonać kilka/naście razy i zanotować najlepszy wynik
5. Przestawiamy gadżet "Wyjście dźwięku" na "plik WAVE", a ścieżkę "Plik dźwiękowy" ustawiamy na RAM:AKsack.wav . Następnie ponownie klikamy w "Start" i notujemy uzyskany wynik w ten sam sposób co w punkcie 4.
6. Kroki od 3 do 5 wykonujemy również na wersji 68k programu. W tym przypadku im więcej powtórzeń tym lepiej (na Efice Trance zaczynał działać dopiero po kilku próbach).
P.S. Wynikowy plik. WAV przyda nam się do testu LAME, ale to już temat na innego posta
.
68k 87.03 WAV 80.30
ppc 150.45 WAV 126.46
Następnym razem daj więcej do testowania chciał bym zamknąć ten temat i czekać na artykuł 😛
Nasz klient – nasz pan
Lame:
Używamy wersji z Aminetu: MorphOS i M68k. Konwertujemy plik AKsack.wav z poprzedniego testu (lepiej zostawić go w RAM:), do .mp3 na domyślnych ustawieniach LAME – czyli nasza komenda będzie wyglądać tak:
Spisujemy CPU time (!). Test możemy powtórzyć kilkukrotnie, biorąc najlepszy wynik z kilku prób. Uwaga! W teście LAME 68k używamy wersji lame060fpu.
Kopiowanie w konsoli:
Kopiujemy plik wynikowy (czyli czterdziestosześciomegabajtowy AKsack.wav) z testu DigiRollera. Używamy konsoli i polecenia:
, oraz
. Spisujemy wyniki.
Monolith:
Benchmark pobieramy z Aminetu.
Wykonanie: Uruchamiamy program i czekamy na koniec obliczeń. Wynik skrzętnie notujemy.
AFinch:
Benchmark pobieramy z Aminetu. Uruchamiamy zarówno wersję 68k (a konkretnie – AFinchM68.40), jak i WarpOS. Notujemy otrzymany wynik.
AFlops:
Benchmark pobieramy z niezawodnego Aminetu. Uruchamiamy zarówno wersję 68k (AFlopsM68.40), jak i WOS. Wynik notujemy na karteczce.
UltimatePPC:
Benchmark pobieramy z MorphOS.files… żartuję, z Aminetu. Uruchamiamy plik wykonywalny i notujemy w kajecie otrzymany wynik.
FFTDemo:
Dla odmiany pobieramy benchmark z skądinąd i… uruchamiamy plik wykonywalny. Wynik (też dla odmiany) zapamiętujemy.
SDL-Bench
Kolejny benchmark pobieramy znów z Aminetu. Wymaga obecności w systemie bibliotek PowerSDL w wersji 12. Uruchamiamy program "Bench", czekamy na zakończenie testu, po czym kopiujemy kilka ostatnich linijek z okna wynikowego.
Quake I
Używamy portu GLQuake autorstwa kiero. Dokładny opis testu znajduje się tutaj.
Uff… Na razie wystarczy.
LAME
CPU Time PPC 0:30
CPU TIME M68K 2:24
time copy ścieżkazdysku:AKsack.wav RAM:
1.1728S
time copy ścieżkazdysku:AKsack.wav drugapartycja:
5.7656
Monolith:
395 at 25 fps
AFinch:
M68K 12.140
WOS 4.180
AFlops:
WarpOS zwraca same NaN a M68k sie zawiesza.
UltimatePPC:
50M Add : 30 ticks
50M Multiply : 32 ticks
20M Sqrt() : 156 ticks
20M Rnd() : 163 ticks
20M Sin() : 134 ticks
20M Log() : 128 ticks
50M Bounds : 26 ticks
10M Pow() : 93 ticks
FFTDemo:
Speed test for FFT + iFFT: (float)
time needed 2368ms for 413696 samples, => 1.9807561635971x speed @44100Hz/stereo
Speed test for FFT + iFFT: (integer)
time needed 1265ms for 413696 samples, => 3.70785045623779x speed @44100Hz/stereo
Speed test for FFT + iFFT: (integer handoptimized 68K ASM)
time needed 489ms for 413696 samples, => 9.59188270568847x speed @44100Hz/stereo
SDL Bench:
320×240 320×240 640×480 640×480
software hardware software hardware
Slow points (frames/sec): 11.782 170.213 1.52091 43.0108
Fast points (frames/sec): 744.186 85.7334 189.63 21.4711
Rect fill (rects/sec): 20898 204800 6714.75 68266.7
32×32 blits (blits/sec): 56888.9 409600 56109.6 409600
Quake I przetestuje jutro ( w sumie to już dziś) nie mam teraz pod ręką danych do gry.
Jeśli jeszcze coś zostało wrzuć i zamknijmy testy.
Quake II
Port pobieramy stąd, a dane z wersji PC – skądinąd.
– w ustawieniach Quake w "Video" ustawiamy driver na tinygl.
– screen size zostawiamy jak jest
– texture quality max
– 8 bit textures – yes
– procedura wyłączania synchronizacji pionowej taka sama jak w przypadku Quake I
– z wyłączaniem konsoli w trakcie dema – podobnie. Niech sobie wisi
– wykonujemy pomiary dla trybu okienkowego i fullscreen, w rozdzielczościach 640×480, 800×600 i 1024×768.
W konsolę wpisujemy:
dla timedemo:
dla timerefresh:
I to już ostatni test, chyba że chcesz wykonać jeszcze AmigaMARK, ale – szczerze mówiąc – niewiele mi mówią te suche liczby. Wolę "real life benchmarking".
Wyniku podeślę jutro, widzę że w Quake 2 wszstkie rozdziałki układają się pod 50 fpsów, czyli tak jak na mini i g4 500 Mhz co oznacza, że to nie kwestia procka ale GFX.
Quakee 1:
Dla:
timedemo demo1.dem
640×480 – 126.1 fps
800×600 – 98.9 fps
1024×768 – 73.0 fps
timerefresh
640×480 – 526.06 fps
800×600 – 367.33 fps
1024×768 – 271.22 fps
Quake 2:
Dla:
timedemo 1
demomap demo1.dm2
640×480 – 50.0 fps
800×600 – 50.0 fps
1024×768 – 49.9 fps
Dla timerefresh gdy wpisuje map q2dm1 dostaje błąd cant fnd maps/q2dm1.bsp Czy to jest jakas podstawowa mapa ?
Jak idzie pisanie artykuło o sprzęcia pod MOSA ?
Jak idzie pisanie artykuło o sprzęcia pod MOSA ?
Zdziwniej i zdziwniej – to superpodstawowa mapa, "The Edge". Jest na tyle podstawowa, że nie ma jej w /maps, tylko jest w pliku .pak. Może uszkodzony?
Artka spodziewaj się nie wcześniej niż nowej wersji PPA, więc (oby) w przeciągu kilku najbliższych tygodni.
Jutro poalczę, też mi sie wydaje że to podstawowa mapa z filmow z YT dobrze ją pamiętam w DM.
Co z artykułem ? :
Uprzedził mnie trochę Krashan, który napisał ten artek o dostępnych dla MorphOSa sprzętach komputerowych. Odpadła tym samym połowa tekstu, a "sucha" analiza benchmarków trochę mija się z celem (przynajmniej moim zdaniem). Ktoś jest innego zdania i chętnie przeczytałby artykuł, w którym autor będzie wyliczał ile razy szybciej enkoduje się mp3 na Miniaczu niż na PowerMacu Gigabit Ethernet?
Uprzedził mnie trochę Krashan, który napisał ten artek o dostępnych dla MorphOSa sprzętach komputerowych. Odpadła tym samym połowa tekstu, a "sucha" analiza benchmarków trochę mija się z celem (przynajmniej moim zdaniem). Ktoś jest innego zdania i chętnie przeczytałby artykuł, w którym autor będzie wyliczał ile razy szybciej enkoduje się mp3 na Miniaczu niż na PowerMacu Gigabit Ethernet?
Znam ten artykuł. Jednak jego świetnym uzpupełnieniem, a raczej drugą cześcia był by artykuł pokazujący wydajność dostępnego sprzętu. Nie ma co ukrywać moc także determinuje wybór. To bardzo interesująca rzecz o ile minimac jest szybszy od takiego emaca czy PM 500 Mhz. To powinien być staly artykuł, sły czas aktualizowany. Obecnie mnogośc konfuguracji, może zawrócic w głowie.
Dyskutowaliśmy nad tym trochę z Krashanem i stanęło na tym, że nie będzie wykorzystywał "moich" benchmarków, bo myśli nad czymś lepszym (benchmarkujący na kilka sposobów program, który sam by przesyłał wyniki do jakiejś centralnej bazy). Fakt faktem, że pewnie w kilku miejscach testy są niedorobione – co wyszło ostatnio podczas porównań z X1000 (tzn. że na przykład używaliśmy w testach wersji LAME bez obsługi AltiVeca – z tym, że i tak była to ta sama wersja dla wszystkich, ale komputery z G4 powinny jeszcze bardziej zdeklasować G3 i starsze). To było gdzieś na forum, tylko nie mogę wątku znaleźć.
Tym się za bardzo nie przejmuj. Często myślę o różnych rzeczach, a potem na 90% z nich nie starcza mi czasu. Testy z „Efika vs reszta świata” są niezłe, tylko – moim zdaniem – jest ich po prostu za dużo i stąd trochę trudno je syntetycznie ogarnąć. Skoncentrowałbym się na kilku, dobierając je tak, żeby:
Przykładowo LAME z ramdysku jest dobrym testem dla samego procesora i jego pamięci cache, oraz ukazuje co daje AltiVec. Do tego przydałby się test przede wszystkim kładący nacisk na sprawdzenie efektywności dostępu do głównej pamięci RAM systemu, bo w przypadku LAME jednak większość operacji dzieje się w pamięci podręcznej L2. Następny krok to testowanie podzespołów „wymiennych” czyli pamięci masowych i grafiki. Tu jednak mnogość konfiguracji może utrudnić interpretację, bo prawdopodobnie przykładowy Radeon 9000 zupełnie inaczej zachowa się w PowerMacu z zegarkiem 500 MHz niż w sprzęcie 1,42 GHz. Podobnie testowanie jakiegoś kopiowania plików to jednoczesny test procesora, pamięci, kontrolera dysku, samego dysku i systemu plików…
Podsumowując, syntetyczna uwaga do aktualnych testów na stronie „Efika vs reszta świata”: mniej testów, więcej konfiguracji. Można się też pokusić o prostą syntezę testów, normalizując wyniki każdego testu do maszyny wybranej za "wzorcową" (nieistotne, która to będzie) i robiąc zestawienie licząc średnią.
Jest jeszcze zapotrzebowanie na artykuł opisujący czym jest MOS wraz z aspektem historycznym. Podlinkowało by się go na stronie głównej jak ten o sprzęcie. W sumie można było by go rozbić na 2 artykuły do brakujących linków ze strony głównej:
1) godny spadkobierca amigowej tradycji – opisujący cała historię powstania, tłumaczący czym jest mos i jakie ma związki z Amigą, jak jest zbudowany co zwiera jako system operacyjny (kompatybilność z m68k, JIT, MUI, 3d, sieć, itp).
2) trojanów i złośliwego oprogramowania – opisujący jakie możliwości daje mos pod względem dostępnego oprogramowania ? (m68k jak i PPC).
Taka moja luźna propozycja rozbicia tematu na 2 artykuły.