Komentowana treść: Apollo A6000 "Unicorn"
24.09 11:32
[#121]
Re: Apollo A6000 "Unicorn"
@abcdef, post #120
[generic] 1955611 4939296 39.6% -lh5- 8cdb Sep 22 13:14 AmigaGPT/AmigaGPT/AmigaGPTD_MorphOS [generic] 1993704 5029372 39.6% -lh5- 2a32 Sep 22 13:14 AmigaGPT/AmigaGPT/AmigaGPT_MorphOS [generic] 60035 129292 46.4% -lh5- 79bc Sep 22 13:13 AmigaGPT/AmigaGPT/AmigaGPTD_OS3 [generic] 79019 175972 44.9% -lh5- 16fa Sep 22 13:13 AmigaGPT/AmigaGPT/AmigaGPT_OS3 [generic] 104182 276645 37.7% -lh5- d9b7 Sep 22 13:14 AmigaGPT/AmigaGPT/AmigaGPTD_OS4 [generic] 145986 378924 38.5% -lh5- 2554 Sep 22 13:14 AmigaGPT/AmigaGPT/AmigaGPT_OS4
To sobie zobacz, ten sam program, ten sam autor.
Porownaj wersje OS4 z OS3, oba exeki sa ponad 2 razy wieksze w wersji PPC.
A MorphOS to juz ma takie narzuty w exeku, ze przegrywa z OS4 przy tym samym procesorze.
24.09 15:07
[#123]
Re: Apollo A6000 "Unicorn"
@BULI, post #122
Nie do konca, bo po prostu im wiekszy jest exek tym wiecej zasobow systemu jest uzywanych, i dany system bedzie dzialal wolniej na tym samym procesorze.
Dla mnie to jest po prostu albo zle napisany program.
Albo cos (ekstra) jest specjalnie dodane do exeka.
Nie znam sie na MorphOS-ie, ale az tak duza roznica w wielkosci execa (w porownaniu z OS 4) jest bardzo dziwna.
Gdzies tam kiedys cos bylo o hackowaniu MorphOS-a.
A to jest program laczacy sie z siecia.
Dla mnie to jest po prostu albo zle napisany program.
Albo cos (ekstra) jest specjalnie dodane do exeka.
Nie znam sie na MorphOS-ie, ale az tak duza roznica w wielkosci execa (w porownaniu z OS 4) jest bardzo dziwna.
Gdzies tam kiedys cos bylo o hackowaniu MorphOS-a.
A to jest program laczacy sie z siecia.
24.09 15:24
[#124]
Re: Apollo A6000 "Unicorn"
@Don_Adan, post #118
Roznica jest taka, ze 2 razy wiekszy exek potrzebuje 2 razy wiekszy cache, zeby dorownac w szybkosci dzialania innym procesorom (zakladajac, ze maja podobne taktowanie i podobne MIPSy).
Masz jakieś liczby na to stwierdzenie? Bo to jest kompletna bzdura. Cierpieć zaczynasz dopiero kiedy pętle przestają mieścić się w cache. Piszesz tak jakby cały program był jednym ciągiem instrukcji i jedną wielką pętlą.
Do tego dochodzi założenie że wszystkie dane mieszczą się w $D i $I nie ma kiedy się przeładować.
Co do wielkości binarek w wersji dla MorphOS, to po prostu mają niektóre biblioteki linkowane statycznie. Proste.
Ostatnia aktualizacja: 24.09.2025 15:29:40 przez kiero
24.09 16:09
[#125]
Re: Apollo A6000 "Unicorn"
@kiero, post #124
No to chyba logiczne, ze petle PPC sa 2 razy wieksze niz petle 68k.
I rzeczywiscie cierpienie jest wtedy, jak sie procedura w cache nie zmiesci.
Dobry programista stara, sie zmiescic petle programu w cache, bo jak sie nie miesci to sa straty w szybkosci dzialania.
Dobrym przykladem jesli chodzi o Amige jest 68030 50MHz (256 bajty cache) vs 68040 25MHz (4KB cache).
Przy krotkich petlach oba procesory sa porownywalne szybkosciowo.
Ale przy dluzszycb petlach 68040 ogrywa 68030 bez problemu.
I dlatego prawie wszystkie porty gier sa robione na 68040+, a nie na 68030+.
Ze wzgledu na cache, i brak umiejetnosci pisania pod 68030.
Tak samo bedzie z PPC, dopoki program (glowne petle) miesci sie w cache jest OK.
A jak sie nie miesci to sa straty w szybkosci dzialania.
I rzeczywiscie cierpienie jest wtedy, jak sie procedura w cache nie zmiesci.
Dobry programista stara, sie zmiescic petle programu w cache, bo jak sie nie miesci to sa straty w szybkosci dzialania.
Dobrym przykladem jesli chodzi o Amige jest 68030 50MHz (256 bajty cache) vs 68040 25MHz (4KB cache).
Przy krotkich petlach oba procesory sa porownywalne szybkosciowo.
Ale przy dluzszycb petlach 68040 ogrywa 68030 bez problemu.
I dlatego prawie wszystkie porty gier sa robione na 68040+, a nie na 68030+.
Ze wzgledu na cache, i brak umiejetnosci pisania pod 68030.
Tak samo bedzie z PPC, dopoki program (glowne petle) miesci sie w cache jest OK.
A jak sie nie miesci to sa straty w szybkosci dzialania.
24.09 17:22
[#126]
Re: Apollo A6000 "Unicorn"
@Don_Adan, post #125
Nie mówimy chyba tutaj o absurdalnie małych cache gdzie ta różnica faktycznie ma jakiś wpływ. Jeszcze raz, masz jakieś liczby dla normalnych aplikacji?
Przy normalnych wielkościach cache (nie jak te 256 bajtów) dużo bardziej starać się trzeba aby dane były w cache, a nie program. Tutaj masz więcej nieprzewidywalnych dostępów, gdzie w przypadku programu nawet jeżeli musisz coś doładować z pamięci to masz praktycznie idealny wróz dostępów (liniowy, zero opuszczonych bajtów w linii cache, itp).
Dobrym? W kontekście tego wątku? Nie mam zielonego pojęcia jak doszedłeś do tego stwierdzenia. Nawet nie wiem jak zacząć.
Jeszcze dla kontekstu. Nawet dzisiejsze procesory, po kilkunastu/kilkudziesięciu latach nie mają dużo większych $I. Najnowsze rdzenie od AMD np mają dalej jedynie 32kB. Po prostu od pewnego momentu to przestaje mieć większe znaczenie.
Ostatnia aktualizacja: 24.09.2025 17:39:50 przez kiero
Dobry programista stara, sie zmiescic petle programu w cache, bo jak sie nie miesci to sa straty w szybkosci dzialania.
Przy normalnych wielkościach cache (nie jak te 256 bajtów) dużo bardziej starać się trzeba aby dane były w cache, a nie program. Tutaj masz więcej nieprzewidywalnych dostępów, gdzie w przypadku programu nawet jeżeli musisz coś doładować z pamięci to masz praktycznie idealny wróz dostępów (liniowy, zero opuszczonych bajtów w linii cache, itp).
Dobrym przykladem jesli chodzi o Amige jest 68030 50MHz (256 bajty cache) vs 68040 25MHz (4KB cache). Przy krotkich petlach oba procesory sa porownywalne szybkosciowo.
Dobrym? W kontekście tego wątku? Nie mam zielonego pojęcia jak doszedłeś do tego stwierdzenia. Nawet nie wiem jak zacząć.
Jeszcze dla kontekstu. Nawet dzisiejsze procesory, po kilkunastu/kilkudziesięciu latach nie mają dużo większych $I. Najnowsze rdzenie od AMD np mają dalej jedynie 32kB. Po prostu od pewnego momentu to przestaje mieć większe znaczenie.
Ostatnia aktualizacja: 24.09.2025 17:39:50 przez kiero
24.09 20:11
[#127]
Re: Apollo A6000 "Unicorn"
@Don_Adan, post #121
A MorphOS to juz ma takie narzuty w exeku, ze przegrywa z OS4 przy tym samym procesorze.To już było wałkowane i to przy tym samym programie. Lata lecą, a popychasz wciąż te same p******ety...
24.09 20:22
[#128]
Re: Apollo A6000 "Unicorn"
@kiero, post #126
Nie. Nie przestaje mieć znaczenie. Zobacz co się zmieniło... uops cache na 6K instrukcji. Tam wsadzisz nietrywialną pętlę w całości w już zdekodowanym cache gdzie pobierać rozkazów i dekodować nie trzeba wcale, tylko doładowywać dane... To robi robotę. Jeszcze parę generacji temu to było kilkaset instrukcji co najwyżej. A jeszcze wcześniej AMD zrobiło psik***** bez s i dało 64KiB I$ (w K7) I to też w tamtych czasach robiło robotę. To pytanie jak to się stało, że w międzyczasie AMD przeszło na instrukcje 64 bitowe, a L1I nie dość, że nie wzrosło to w nowszych generacjach ZMALAŁO, a wydajność... wręcz przeciwnie. Magia :) Szukałem lame, ale znalazłem tylko binarkę dla x86_64 (native) 1.6MB i uniwersalną ARM/PPC/x86 dla MacOS 3.1MB
Wydaje mi się, że te wszystkie informacje jakie to PPC jest tłuste wynikają głównie z innych wersji bibliotek standardowych, podlinkowanych dodatkowych libsów etc. Można by poszukać np. libssl w wersji dla x86, arma, 68k i ppc i porównać, ale mnie się szczerze nie chce. Co zresztą by to miało ostatecznie zmienić?
Wydaje mi się, że te wszystkie informacje jakie to PPC jest tłuste wynikają głównie z innych wersji bibliotek standardowych, podlinkowanych dodatkowych libsów etc. Można by poszukać np. libssl w wersji dla x86, arma, 68k i ppc i porównać, ale mnie się szczerze nie chce. Co zresztą by to miało ostatecznie zmienić?
24.09 20:49
[#131]
Re: Apollo A6000 "Unicorn"
@kiero, post #126
Nie, nie mam, bo do takich testow trzeba miec sprzet z roznymi procesorami i potrafic go obslugiwac.
Byc moze 32KB jest optymalna wartoscia jesli chodzi o cache dla instrukcji.
Bo raczej ciezko jest napisac wieksza petle.
68030 jest dobrym przykladem, bo jak sie dobrze pisze pod ten procesor to jest on porownywalny z 68040.
A jak sie zle pisze to roznica w szybkosci dzialania obu procesorow jest duza.
np. c2p dla 68030 to powinny byc 2 petle, ktore sie mieszcza w cache.
a dla 68040 wystarczy jedna petla.
Byc moze 32KB jest optymalna wartoscia jesli chodzi o cache dla instrukcji.
Bo raczej ciezko jest napisac wieksza petle.
68030 jest dobrym przykladem, bo jak sie dobrze pisze pod ten procesor to jest on porownywalny z 68040.
A jak sie zle pisze to roznica w szybkosci dzialania obu procesorow jest duza.
np. c2p dla 68030 to powinny byc 2 petle, ktore sie mieszcza w cache.
a dla 68040 wystarczy jedna petla.
24.09 21:17
[#132]
Re: Apollo A6000 "Unicorn"
@Don_Adan, post #129
Na szczescie Kiero mnie uswiadomil, ze MorphOS linkuje biblioteki wewnetrznie.W AmigaOS (i zdecydowanej większości innych systemów operacyjnych) też możesz mieć biblioteki statyczne i często się tego używa. Więc to nie jest jakaś cecha szczególna MorpOS-a. W tym programie tak się złożyło (pisałem dlaczego, we wspomnianym wątku), że OpenSSL jest statycznie linkowany pod MorphOS-em, a dynamicznie pod AmigaOS 3 i 4.
25.09 10:02
[#134]
Re: Apollo A6000 "Unicorn"
@Don_Adan, post #133
Poczytaj sobie o różnych rodzajach i poziomach cache. $I jest tu "unusually large" i ma 192kB.
Duże cache w dzisiejszych czasach są na dane, nie na kod. Ilość danych mielonych przez procesor jest nieporównywalnie większa niż wielkość kodu który jest wykonywany. L2 i wyżej oczywiście może służyć jako źródło dla L1, ale nie po to jest robiony.
Ostatnia aktualizacja: 25.09.2025 10:21:52 przez kiero
Duże cache w dzisiejszych czasach są na dane, nie na kod. Ilość danych mielonych przez procesor jest nieporównywalnie większa niż wielkość kodu który jest wykonywany. L2 i wyżej oczywiście może służyć jako źródło dla L1, ale nie po to jest robiony.
Ostatnia aktualizacja: 25.09.2025 10:21:52 przez kiero
25.09 10:46
[#135]
Re: Apollo A6000 "Unicorn"
@kiero, post #134
Nieco rozwinę. Te 32kB o których pisałem wcześniej też siedzą jako L1 w AMD (podobna wielkość w Intelach). Potem masz L2 i L3 (SLC w przypadku Apple, różnie się to nazywa). Dlaczego tylko L1 są osobno na dane i kod? Bo tu ważna jest gwarancja że dane nie wygryzą kodu z cache. I tylko taka mała ilość spokojnie wystarcza. Przy normalnych aplikacjach dane (dane-dane, nie dane-kod) po prostu żyją w cache bardzo krótko (losowość dostępu, niepełne wykorzystanie danych w linii cache itp).
