30.10.2016 00:27
[#153]
Re: Apollo CPU - dyskusja
@grxmrx, post #152
Ekspertem nie jestem. Udało mi się jednak odpalić AROSa na Apollo 040/40 MHz + AGA . W związku z tym że nie działa FBlit, to z braku pamięci graficznej nie odpaliłem Wanderera tylko gorszy zamiennik w 4 kolorach - link
W drugiej Ami mam BVision, ale sterowników do niej też nie ma. Zorro i Radeona nie kupie.
Czyli zostaje wrócić do zabawy z WinUAE.
Wersja x86 mnie nie interesuje.
W drugiej Ami mam BVision, ale sterowników do niej też nie ma. Zorro i Radeona nie kupie.
Czyli zostaje wrócić do zabawy z WinUAE.
Wersja x86 mnie nie interesuje.
30.10.2016 02:45
[#154]
Re: Apollo CPU - dyskusja
@grxmrx, post #152
Tu mozna sie klocic o szczegoly. Natomiast sytuacja jest taka ze aros, a w tym wersja 68k, jest mniej wiecej na tym samym poziomie jesli chodzi o tzw "nowoczesnosc" jak os4 czy morhos. Na pewnych polach aros moze byc albo wydawac sie niedopracowany, ale jako ze kod jest otwarty kazdy moze to poprawic, zamiast narzekac, takiej opcji nie ma w pozostalych przypadkach. Natomiast sa obszary gdzie aros juz teraz jest bardziej zaawansowany. Wezmy na przyklad gallium/mesa ktore chc w praktyce zbyr wolne na amiga dzialaja jednak teoretycznie pod winuae na sterowniku softwareowym. Inna sprawa to stosunkowo niskie zapotrzebowanie na pamiec porownywalne z oryginalnym systemem amigi. Uzytkownicy os4 moga o tym tylko pomarzyc. Jest oczywiscie wiele innych aspektow, ale trudno je tu rozwijac.
30.10.2016 09:44
[#156]
Re: Apollo CPU - dyskusja
@wawrzon, post #154
Informacja ze strony aros.org:
Póki co nie chcę tego widzieć w mojej Amidze. Na stronie ze statusem piszą, że ledwie 82% API AmigaOS 3.x zostało zaimplementowane. A ja mam OS 3.9... Dalsze powody:
Chyba wiem, dlaczego - kiedyś odpaliłem AROSa pod UAE, działało to niesamowicie wolno, wyglądało jakby (co najmniej) podsystem grafiki był totalnie niezoptymalizowany. A nie stać mnie na powerful Amiga, dopiero Vampire ma potencjał żeby to zmienić (jak wyjdzie wersja na A1200).
Ostatnia aktualizacja: 30.10.2016 09:51:53 przez Cedrat
Warning
AROS is alpha quality software. This means that it is currently mostly fun to play with and cool to develop for. If you came here because you thought AROS was a finished, complete and fully usable operating system, you will most likely be disappointed. AROS isn't there yet, but we're slowly moving in the right direction.
Póki co nie chcę tego widzieć w mojej Amidze. Na stronie ze statusem piszą, że ledwie 82% API AmigaOS 3.x zostało zaimplementowane. A ja mam OS 3.9... Dalsze powody:
Note
If you are a user wanting to try AROS, please use the links in the Distributions section to download a fully-featured AROS distribution. The nightly builds you will find at the bottom of the page are only meant for developers and testers. The nightly builds are not configured to be easily used, are not always stable, and they are missing most of the applications essential to a regular user experience.
(...)
AROS Vision is a distribution for M68k Amigas. To run well, it requires a powerful Amiga or an emulator such as WinUAE.
Chyba wiem, dlaczego - kiedyś odpaliłem AROSa pod UAE, działało to niesamowicie wolno, wyglądało jakby (co najmniej) podsystem grafiki był totalnie niezoptymalizowany. A nie stać mnie na powerful Amiga, dopiero Vampire ma potencjał żeby to zmienić (jak wyjdzie wersja na A1200).
Ostatnia aktualizacja: 30.10.2016 09:51:53 przez Cedrat
30.10.2016 11:03
[#160]
Re: Apollo CPU - dyskusja
@Krashan, post #157
Będzie jak na PC, większość zysku z szybszego procesora zjada niezoptymalizowany „lepszy” system...
Dlatego zamierzam dalej używać OS 3.9 - w nieco wyższej rozdzielczości (ale na pewno nie jakimś FullHD), z większą liczbą kolorów. Co do oprogramowania - pewnie włączę kilka upiększaczy (np. CaBoom) i przestanę bać się odtwarzaczy MP3. Tyle...
30.10.2016 15:14
[#163]
Re: Apollo CPU - dyskusja
@Cedrat, post #156
@cedrat
Mysle ze status na stronie arosa nie jest calkiem aktualny, np mui bedzie na poziomie pozwalajacym odpalic odyssey, gdyby skompilowac to na 68k. Natomiast braowac bedzie wekszosci klas reaction, dostepnych jednak w formie class act.
Co do predkosci to prawda, nie jest zachwycajaca, zwlaszcza grafika, tak zune, jak listowanie folderow. Natomiast trudno mi uwierzyc by bylo to odczuwalne pod uae i jitem.
Wiec oczywiscie w obecnym stanie trudno pewnie sprzedac arosa zwyklemu uzytkownikowi. Natomiast jesli chodzi o jakistam rozwoj systemu to mamy dwie opcje, albo czekac na godota albo samemu starac sie pomoc i troche zaznajomic z zagadnieniem. Osobiscie wole to drugie choc nie musi to byc preferencja dla kazdego.
Mysle ze status na stronie arosa nie jest calkiem aktualny, np mui bedzie na poziomie pozwalajacym odpalic odyssey, gdyby skompilowac to na 68k. Natomiast braowac bedzie wekszosci klas reaction, dostepnych jednak w formie class act.
Co do predkosci to prawda, nie jest zachwycajaca, zwlaszcza grafika, tak zune, jak listowanie folderow. Natomiast trudno mi uwierzyc by bylo to odczuwalne pod uae i jitem.
Wiec oczywiscie w obecnym stanie trudno pewnie sprzedac arosa zwyklemu uzytkownikowi. Natomiast jesli chodzi o jakistam rozwoj systemu to mamy dwie opcje, albo czekac na godota albo samemu starac sie pomoc i troche zaznajomic z zagadnieniem. Osobiscie wole to drugie choc nie musi to byc preferencja dla kazdego.
30.10.2016 15:21
[#164]
Re: Apollo CPU - dyskusja
@Krashan, post #157
Będzie jak na PC, większość zysku z szybszego procesora zjada niezoptymalizowany „lepszy” system...
Calkem tego nie da sie wyeliminowac. Ficzery nie sa w koncu za darmo. Natomiast optymalizacja powinna miec miejsce, tyle za jest na to jeszcze niestety za wczesnie. Glupia sprawa, ale jak wszedzie u nas brakuje kwalifikowanych rak i tak bedzie dalej poki kazdy pichci najwyzej swoja zupe.
04.11.2016 13:59
[#167]
Re: Apollo CPU - dyskusja
@jimiche, post #166
Skip jedno pytanie. Czy oxypatcher albo cyberpacher miałeś na Amidze z Aga włączony?
Ja wiem że podobno on daje kopa bardziej dla fpu ale zawsze myślałem że killer z fpu korzysta .
Siema! Tak, zawsze mam OxyPatcher włączony na 68060. Co do Vampire, tam nie ma takiej potrzeby, tym bardziej, że FPU na razie tylko w planach (a nawet jak już będzie, to patchowanie nie będzie koniecznie, ponieważ będzie zgodny z 881/882, przynajmniej w postaci widocznej dla użytkownika) ;)
Aczkolwiek - ja też zawsze myślałem, że "Killer" wymaga FPU. A jednak - chodzi na maszynie bez niego, co dla mnie również jest zaskoczeniem.
04.11.2016 14:04
[#168]
Re: Apollo CPU - dyskusja
@pisklak, post #1
Nie było w tym wątku akurat nic o nadchodzącym AMMX, więc odświeżam (mimo, że było to poruszane w innym, ale mniej relewantnym wątku):
Gunnar wyjaśnił przewagę AMMX nad "normalnym" kodem w dość prosty i zrozumiały sposób na poniższym przykładzie: https://goo.gl/jGG6zT
W największym skrócie - dla tego konkretnego przykładu (miksowanie kanałów audio) - zamiast 48 instrukcji, za pomocą instrukcji AMMX w 68080 mamy ich tylko 3 (i ten sam rezultat). Co więcej, gdy 48 instrukcji na 68060 zajmie w najlepszym wypadku 24 cykle procesora, w Apollo Core 68080 będą to tylko 3 cykle.
To tak w temacie "a po co to komu, a dlaczego" ;) Miłego piąteczku!
Gunnar wyjaśnił przewagę AMMX nad "normalnym" kodem w dość prosty i zrozumiały sposób na poniższym przykładzie: https://goo.gl/jGG6zT
W największym skrócie - dla tego konkretnego przykładu (miksowanie kanałów audio) - zamiast 48 instrukcji, za pomocą instrukcji AMMX w 68080 mamy ich tylko 3 (i ten sam rezultat). Co więcej, gdy 48 instrukcji na 68060 zajmie w najlepszym wypadku 24 cykle procesora, w Apollo Core 68080 będą to tylko 3 cykle.
To tak w temacie "a po co to komu, a dlaczego" ;) Miłego piąteczku!
04.11.2016 15:32
[#169]
Re: Apollo CPU - dyskusja
@skipp, post #168
Eh, nie ma to jak naginanie rzeczywistosci...To jest straszny kod dla 68k i mozna to napisac duzo szybciej... Nie twierdze, ze w 3 cyklach ale twierdzenie, ze w najlepszym przypadku beda to 24 cykle na 060 to po prostu umyslne wprowadzanie czytajacego w blad albo niewiedza...
dla 4 sampli 8bit (z pamieci, nie mam jak zbytnio sprawdzic) :
move.l (a0)+, d0
move.l (a1)+, d1
move.l d0, d2
move.l d1, d3
and.l #$ff00ff, d0
and.l #$ff00ff, d1
add.l d0, d1
add.l #$010001, d1
lsr.l #1, d1
and.l #$00ff00ff, d1 ; 2 probki
lsr.l #8, d2
lsr.l #8, d3
and.l #$ff00ff, d2
and.l #$ff00ff, d3
add.l d2, d3
lsl.l #7, d1
and.l #$ff00ffff, d1 ; 2 probki
poparowane, zeby urwac nieco:
move.l (a0)+, d0
move.l (a1)+, d1
move.l d0, d2
move.l d1, d3
and.l #$ff00ff, d0
and.l #$ff00ff, d1
lsr.l #8, d2
lsr.l #8, d3
add.l d0, d1
and.l #$ff00ff, d2
and.l #$ff00ff, d3
add.l #$010001, d1
add.l d2, d3
lsr.l #1, d1
lsl.l #7, d3
and.l #$00ff00ff, d1 ; 2 probki
and.l #$ff00ff00, d3 ; 2 probki
or.l d3, d1
move.l d1, (a2)+ ; 4 probki, 9.5 cykli
Tak wiec tentego...
Ostatnia aktualizacja: 04.11.2016 15:41:47 przez kiero
dla 4 sampli 8bit (z pamieci, nie mam jak zbytnio sprawdzic) :
move.l (a0)+, d0
move.l (a1)+, d1
move.l d0, d2
move.l d1, d3
and.l #$ff00ff, d0
and.l #$ff00ff, d1
add.l d0, d1
add.l #$010001, d1
lsr.l #1, d1
and.l #$00ff00ff, d1 ; 2 probki
lsr.l #8, d2
lsr.l #8, d3
and.l #$ff00ff, d2
and.l #$ff00ff, d3
add.l d2, d3
lsl.l #7, d1
and.l #$ff00ffff, d1 ; 2 probki
poparowane, zeby urwac nieco:
move.l (a0)+, d0
move.l (a1)+, d1
move.l d0, d2
move.l d1, d3
and.l #$ff00ff, d0
and.l #$ff00ff, d1
lsr.l #8, d2
lsr.l #8, d3
add.l d0, d1
and.l #$ff00ff, d2
and.l #$ff00ff, d3
add.l #$010001, d1
add.l d2, d3
lsr.l #1, d1
lsl.l #7, d3
and.l #$00ff00ff, d1 ; 2 probki
and.l #$ff00ff00, d3 ; 2 probki
or.l d3, d1
move.l d1, (a2)+ ; 4 probki, 9.5 cykli
Tak wiec tentego...
Ostatnia aktualizacja: 04.11.2016 15:41:47 przez kiero
05.11.2016 21:00
[#174]
Re: Apollo CPU - dyskusja
pisklak
autor wątku
autor wątku
@kiero, post #169
Hmm..... nie jestem pewien czy dobrze podliczyłeś cykle i czy przypadkiem nie zapomniałeś o zaokrągleniu (roundingu czy 'cuś'). Tak przynajmniej twierdzi Gunnar bo ja nie mam zielonego pojęcia 
. Tak czy inaczej rozkazy typu SIMD są użyteczne, inaczej nikt by ich nie stosował. Może i nie są żadnym cudownym wynalazkiem ale w całkiem wielu przypadkach ich wykorzystanie daje wyraźne korzyści.
. Tak czy inaczej rozkazy typu SIMD są użyteczne, inaczej nikt by ich nie stosował. Może i nie są żadnym cudownym wynalazkiem ale w całkiem wielu przypadkach ich wykorzystanie daje wyraźne korzyści. 14.11.2016 13:38
[#175]
Re: Apollo CPU - dyskusja
pisklak
autor wątku
autor wątku
@pisklak, post #174
Panie i Panowie... czas trochę odświeżyć wątek.
A więc gdzieś po drodze do GOLD2 trochę się w Apollo CPU pozmieniało na lepsze i coś tam się udało polepszyć. Prosiłbym więc ciekawych/chętnych o zajrzenie tutaj i skomentowanie tych wyników. A także w miarę możliwości zapuszczenie sortbencha na swoich maszynach i podzieleniem się wynikami Mile widziane wyniki z np. BlizzPPC,Effiki itp
Ostatnia aktualizacja: 14.11.2016 13:57:44 przez pisklak
A więc gdzieś po drodze do GOLD2 trochę się w Apollo CPU pozmieniało na lepsze i coś tam się udało polepszyć. Prosiłbym więc ciekawych/chętnych o zajrzenie tutaj i skomentowanie tych wyników. A także w miarę możliwości zapuszczenie sortbencha na swoich maszynach i podzieleniem się wynikami
Mile widziane wyniki z np. BlizzPPC,Effiki itpOstatnia aktualizacja: 14.11.2016 13:57:44 przez pisklak
14.11.2016 15:46
[#177]
Re: Apollo CPU - dyskusja
@pisklak, post #176
Kiedy po raz kolejny wkłada się ten sam kij w to samo mrowisko to za którymś razem mrówki po prostu ziewają z nudów 
Teraz lepiej niech Gunnar zrobi tabelkę, w której Apollo robi kółka dookoła jakiegoś i7 Extreme Edition
Ostatnia aktualizacja: 14.11.2016 15:47:50 przez recedent
Teraz lepiej niech Gunnar zrobi tabelkę, w której Apollo robi kółka dookoła jakiegoś i7 Extreme Edition
Ostatnia aktualizacja: 14.11.2016 15:47:50 przez recedent
17.11.2016 14:43
[#180]
Re: Apollo CPU - dyskusja
@pisklak, post #179
Jest jeszcze taki fajny chart powstały na podstawie wątku EAB.
gcc-6 pod x86_64 generuje jeszcze fajniejszy kod. na 3.5 GHz core i5 wyszlo 18080.73 MB/s albo 5165 MB/s/GHz.
Kod Gunnara jest brzydki na tyle (2 razy goto!), ze clang sobie z nim rady nie daje i na tej samej maszynie daje marne 5964 MB/s albo 1704 MB/s/GHz :)